Does your organization currently employ a strong password policy?  Does your organization currently enforce this strong password policy? A strong password should be 14 characters long and should utilize numeric, upper and lower case alphabetical, and symbol characters such as “!@#$%^&*()”.    Most every modern operating system or directory service (LDAP) implementation supports enforcement of strong password complexity.  Administrators should ensure they are utilizing the password history function of their directory service if available, to minimize the potential for password reuse by end users.  For Linux users not utilizing a directory, you can utilize the PAM module provided by the Openwall project, passwdqc, which provides password complexity enforcement.

If your environment allows, utilize password-less authentication using public key encryption provided by either the RSA or DSS.  Most SSH clients and servers support one or both of these methods.  Finally, Ensure that your SSH server does not allow root or Administrator logins.

If your environment already has a firewall in place to facilitate network access control, you should ensure that TCP port 22 is only available to those networks that need access.  If your environment does not have a firewall, OS level packet filtering is available in all modern operating systems.  When thinking about the SSH surface area in your environment, ensure you include devices that are manageable via SSH including routers, firewalls, switches, and other network appliances.

You should really ask yourself why your SSH service is available to the public if you aren’t explicitly providing a shell service to end users.

Organizations may not have to work hard to initially develop this trust relationship with their customer.  What an organization may not be doing is working hard to maintain this trust relationship.  If the integrity of these assets are challenged, there is a potential risk of destroying this trust relationship, which could be cause for a costly recovery attempt of this customer trust, or complete customer loss.  Ensuring the integrity of your organization’s digital assets should be considered a foundational component of any organization’s security practice.

When we speak of digital assets, we not only include the traditional media data types including images, audio, and video, but all other content produced by your company that exists in a persistent state on disk.  In a web server environment we would most likely be dealing the with following types of data:

• Html, Javascript, CSS, and embedded web objects
• PHP, Perl, .NET, and other application code
• Non-HTML Document types such as PDF or Office files
• Images, Audio, and Video

We were recently employed to review the state of a customer’s environment following a recent intrusion.  As with a portion of the environments we work in today, the services provided included web content and application delivery provided by Apache running on Linux.  While Apache does provide access logging for files requested from it, it does not maintain state regarding the integrity of the files it serves. Following an intrusion, identifying the the attack vector is extremely important in providing future security of this environment but should not be the only consideration.

The following questions need to be asked concurrently:

• What organizational or customer data was exposed?

• Was any data modified and what is the potential impact to our customers?

In high traffic environments, it can be extremely difficult to answer both of these questions quickly, which in turn can prolong the delivery of customer communication or notification for external entities that may have a stake in the exposed data.  To speed up the time to derive an answer to both of these questions, there are two methods that are available to expedite this process.

First, the majority of server operating systems in production today have kernel facilitated auditing capability bundled with the operating system.  Linux provides the Linux Audit Subsystem.  Microsoft Windows Server including 2003 and 2008 provide auditing capability.  Solaris, MacOS X, and the BSD family of operating systems also implement audit facilities.  Each of these respective implementations provide the ability to monitor file access and modification events and produce audit trail which can be used to quickly determine which critical assets were accessed or modified.  Although the deployment of auditing policy is not trivial, the benefit can easily be measured if file integrity is violated and you are able to effectively determine the targeted assets and the associated scope of exposure.

Secondly, organizations should deploy a file integrity monitoring system such as Tripwire or Samhain.  These systems utilize one way cryptographic functions (also known as message digest algorithms) such as MD5, SHA1, SHA2, or Tiger, to create a catalog of computed hashes of  files covered by the monitoring software’s defined policy.  Following the a baseline definition process, these systems monitor filesystem changes against prior hash calculations, and in some cases, against known bad hash values associated with exploit, rootkit code, and other potential malware.   When a change event is discovered, notifications can be delivered to those accountable.

The data generated by each of these tools should be streamed via encrypted transport to a centralized syslog server.   This centralized server should exist in a logically distinct network segment from all other nodes in the environment.   Because this server essentially becomes the gold copy record for file integrity in your environment as related to file assets, extreme care should be used to ensure the validity of logs captured.  This includes utilizing file integrity monitoring and limiting access to those who have a need to know.

The employment of these systems do not provide protection against intrusion but can ease the burden of cleaning up the mess and help organizations identify impact.  While this does not completely mitigate potential loss of trust with your customers, it allows you to effectively measure whether or not their trust was violated and the overall level of exposure.  In the future, we will be providing direction on how these logs can be utilized to provide real-time alerting of an attack in progress, and what you can do to decrease your time to react.

I have been asked that question many times, and I wish the reply I had to deliver was one with a better message.  Unfortunately we often find vulnerable components embedded in commercial products.  Vulnerabilities that can lead to the compromise of the system they are installed in.  We have seen this in both software products that companies are actively shipping, as well as in software and appliances other clients have purchased and installed.  When we request that the vulnerable components be upgraded, the change request very rarely makes it very far up the chain.  The reasoning (when one is actually given) is other “feature enhancements” and new functionality for customers and sales are a higher priority.

While performing security audits against organizations this is an issue that comes up frequently.  What we have seen is that unless the client represents a significant source of revenue or other opportunities for the company shipping vulnerable products, getting them to change can be a very difficult and time consuming process that may not yield major results in any workable time frame.  Baring being a significant revenue source, being a potentially good or bad publicity source could also be a way to get them to be a little more helpful.  For instance having a large scale outage caused by an exploit of one of the vulnerably pieces of software they are using.  However I do not really recommend waiting to be exploited as a viable option.

I am not suggesting that you do not open a support ticket with the company when you do find an issue; however receiving an unworried/unconcerned response is something you should expect.  Having a proof of concept attack against their software that you can show them would be one way to help get their attention, but that can be time consuming and costly.

Instead most organizations are forced to mitigate the issue themselves.  While waiting for the software companies to upgrade or fix the issues you have found, you need to mitigate and create controls around all of the known issues.  In general this can be accomplished through a six step process.

1. Segment your network into different zones based upon function, confidentiality and importance of data, etc.
2. Deploy host based and network based firewalls to restrict access to specific ports, sources, and/or destinations.  The firewalls should restrict both what connections can be made in an attempt to exploit a vulnerability, as well as to limit what damage or access a compromised computer can create.  You do not want a compromised server downloading tools or initiating more attacks if you can help it.
3. Deploy and USE an operational Alerting and Monitoring system, configured to detect outages, error conditions, and anomalies, .  This includes traffic flows, service and device uptime, and SLA measurements, as well as the gathering of syslog data and appropriate snmp-traps.
4. Deploy a network and/or host based IDS to watch for any attempts at exploiting known vulnerabilities or traffic anomalies.
5. Deployment of an event correlation system (such as Cisco’s MARS, RSA’s enVision, or Splunk) to help manage the massive amounts of server, firewall, and IDS logs.
6. Continually monitor, maintain, and manage your environment.  There are no easy “place it and forget it” solutions to security issues.

It is strongly recommended that you read bulletin KB17118, then download and install the patch, called Service Pack 6 Interim Security Software Update 2, from http://www.blackberry.com/go/serverdownloads. The security bulletin also offers a workaround that reduces the functionality of BES but protects the server from exploits of the Attachment Service vulnerabilities.

The affected versions of the server software are BlackBerry Enterprise Server software version 4.1 Service Pack 3 (4.1.3) through 4.1 Service Pack 6 (4.1.6), including the latest maintenance release.

In the past, I’ve warned Windows shops to use unique local Administrator passwords wherever possible.  I’ve even proven the dangers of using the same local Administrator password during a penetration test in 2007.   Combine this with the fact that  I rarely have anything polite to say about VBscript (it’s not a pretty language to work with), and we have the perfect karmic storm.

Yours truly, coding in VBscript, tasked with setting a unique, strong passwords on each one of a few hundred machines.   Here’s what I came up with:

' ChangeLocalAdminOnServers.vbs
' Created by Irving Popovetsky (irving@prostructure)
' 12/15/2008, ProStructure Consulting
'
' Warning:  This script will begin changing passwords as soon
' as it collects a complete list of machine names.
'
' Read and understand this code carefully before executing,
' and always remember to fill in your own variables where appropriate.
' We assume no liability for damages that may be caused by running
' this code in your production environment!!

On Error Resume Next

Dim fso, MyFile
Set fso = CreateObject("Scripting.FileSystemObject")

' ***CHANGEME*** Change the output file to a location you trust, like an
' Encrypted folder or USB stick that can be stored away
' In the future, this could be improved to output directly to PGP or equivalent.
Set MyFile = fso.CreateTextFile("c:\Temp\Changedservers.txt", True)

Const ADS_SCOPE_SUBTREE = 2

Set objConnection = CreateObject("ADODB.Connection")
Set objCommand =   CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection

objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE 

' ***CHANGEME*** Fill in your own Domain name here
objCommand.CommandText = _
    "SELECT Name FROM 'LDAP://dc=DOMAIN,dc=INTERNAL' WHERE objectCategory='computer'"
Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst

Do Until objRecordSet.EOF
    strComputer = objRecordSet.Fields("Name").Value

	' ***CHANGEME*** Skip the Domain Controllers  - fill in your own values here
	if Instr(1,strComputer, "DOMAINCONTROLLER1") Then objRecordSet.MoveNext
	if Instr(1,strComputer, "DOMAINCONTROLLER2") Then objRecordSet.MoveNext
	if Instr(1,strComputer, "DOMAINCONTROLLER3") Then objRecordSet.MoveNext

	' Irving - Random password
	Dim intUpperLimit, intLowerLimit, strPassword
	strPassword = ""
	intUpperLimit = 126
	intLowerLimit = 33

	For i = 1 to 12
	    Randomize
	    intASCIIValue = Int(((intUpperLimit - intLowerLimit + 1) * Rnd) _
	        + intLowerLimit)
	    strPassword = strPassword & Chr(intASCIIValue)
	Next

	'  Perform the Action.  Write out the computername/password then execute
	MyFile.WriteLine(strComputer & "   " & strPassword)
	Set objUser = GetObject("WinNT://" & strComputer & "/Administrator")
	objUser.SetPassword strPassword

    objRecordSet.MoveNext
Loop

MyFile.Close

Credits to The Scripting Guy’s article on scripting the change of the local administrator password. Very funny article,  I’m a big fan of the Scripting Guy.

Now, there are certainly some improvements that can be made, and WILL be made if I ever have to use this thing again.   First off, the ability to define the output location and LDAP search path.   Second, automatically determining if a server is a domain controller and skipping it.  You DEFINITELY DO NOT want this script hitting a Domain Controller, because it will change the Domain’s Administrator account, and that can be a bad thing.  Trust me, I already learned that lesson, at least I had the password in my output file.

Article link:  Psst! Whats the Password?

The new automated attacks are mostly focused on Content Management System (CMS) functionality, in order to insert an IFRAME on your website pointing to a malicious site.  5 years ago we all talked about how SQL injection attacks would focus on stealing credit card numbers and personal information directly out of databases, or skipping password checks or adding administrative users.   I demonstrated that last one myself during a security engagement.   The attacks were jaw-dropping and scary, and we thought that everyone was on the way to getting it fixed.

If you find this XKCD comic funny, you’re halfway toward understanding exactly how dangerous SQL injection is:

So why are ASP and ASP.NET still such easy pickings?   I believe it’s due to two main reasons:

1.  ASP has THE WORST string validation functionality of any modern programming language used to create web applications today.

Have you ever seen a successful, tight form validation routine written in ASP or VB?   It’s ugly, and easy to get wrong.    This is because there’s no regex (regular expression) library for performing string-fu,  a luxury that pretty much everyone else has.

5-6 years ago, smart developers realized this and quickly said “Hey, we need to filter this garbage before it ever gets to the app, by building ISAPI filters in C and C++”.   Some shops wrote their own, many adopted tools like Microsoft’s URLScan or Eye’s SecureIIS.   Problems were solved, as these ISAPI filters magically denied all sorts of nasty strings, and were totally worth the pain of implementation.

2.  Microsoft left Windows 2003/IIS 6 users out in the cold

Right around the time when Windows 2003 shipped, two things were happening.  First, people like myself were finding MAJOR functionality flaws in URLScan which Microsoft was basically refusing to fix, and telling users to wait for the next version.    Second, instead of actually shipping that next version, Microsoft proclaimed that IIS 6 had “URLScan technology” built in, and nobody needed URLscan anymore.  Too bad that whatever was actually included with IIS 6 was missing URLScan’s best functionality, including the malicious string denial functionality.  Thanks for that one, Microsoft.

So for about 5 years, the memory of URLScan faded, and everyone migrated to Windows 2003 and IIS 6.  Sure, IIS 6 is a lot more “secure by default”, but ASP shops weren’t being adequately protected from SQL injection attacks.    It wasn’t until THIS MONTH that Microsoft released URLScan 3.0 Beta which finally supported IIS 6.   URLScan 3.0 Beta also supports IIS 7, which now has basic request filtering, but not as advanced as URLScan.   It is not too late to consider this tool.

3.  Some ASP and ASP.NET shops are still running insecure code and using insecure coding practices

Microsoft and various security firms have been preaching advice about how to protect against SQL injection attacks for years now.  It is a lack of risk awareness and training that is allowing it to continue.   The argument that it is just too expensive for a business to fix these vulnerabilities doesn’t stand anymore, the attacks are too damaging.

What can be done?

The answer is simple.  You need to self-assess your applications, or find someone to perform the assessment for you.   Be careful, though, self-assessment has a huge risk, which is a golden rule of security:  The designer of a system is the least likely to see its flaws.   Fortunately, if you go this route there are plenty of free and intuitive tools to help you along the way.

HP has released a cool new tool called Scrawlr (free download) that will walk your ASP/ASP.NET/MS SQL based website and search for basic SQL Injection vulnerabilities.   Unfortunately the tool does have some serious limitations  (doesn’t handle authentication, won’t check forms or anything involving a POST, and cannot perform blind SQL injection).   But it is a nicely packaged tool for finding the simplest vulnerabilities, the ones that the bad guys are hitting as well.

Fortunately, there are plenty of other free tools that perform Blind SQL injection (check google),  as well as WebScarab and even the Firefox add-ons TamperData and Hackbar to assist you in self-assessing your own site.

• VMWare (all products, from ESX Server all the way down to VMware Player)
• Cisco PIX and ASA (versions 7.1, 7.2, 8.0 and 8.1)
• Mac OS X (Both Server and Client editions, 10.4 and 10.5 are affected)

Quite a few of these vulnerabilities are remotely exploitable and especially dangerous on the PIX and unprotected OSX and VMware installations.   VMware also looks like it may have a  local “VM breakout” bug or two, watch out for these.   We strongly recommend getting these products updated as soon as possible.

For more information and relevant links, check out the US-CERT Cyber Security Bulletin SB08-161.  Search for the product you’re running on this page.