The link takes you to a list of hosts that respond with the value “DROP TABLE” somewhere within the servers HTTP headers.

In case you aren’t already familiar with the HTTP protocol, when you make a request to a web site, lets say logrhythm.com,  something like this is going on in the background.

In this case, we place a GET request for logrhythm.com and everything after the “HTTP/1.1 200 OK”  are the HTTP header fields that the remote server server sent back to us.  As we can see above, the server claims to be IIS/6.0.  Based off of other returned header data, “X-powered-By:PleskWin, ASP.NET” for example, it’s probably a safe bet that it’s a windows server.  Back to the point though, in the case of Mikko’s example, the servers listed don’t respond with a know server type, instead the following text:

Server: ‘; DROP TABLE servertypes; –

Clearly, this is not an actual server type, instead a SQL injection command.

Why would someone configure a server to respond this way?

Well, if we read the SQL it’s pretty simple.  It’s telling the server to delete/remove the table servertypes. So who would be inserting HTTP Header response codes into a DB and would have a table named servertypes? Spiders, bots and crawlers of course! Well i’m guessing that’s the idea anyway.

So a bot hits your site, parses your header responses and tries to insert the value from “Server:” into a DB . If it happens to have a table named, servertype and SQL the statements aren’t being prepared or sanitized properly, then the table gets dropped.

Ultimately, it’s probably a joke more than anything but it’s interesting to think about. This assessment seems to be pretty accurate based on a Reddit mod’s explanation of why Reddit does it here.  At this point I will have to also admit that this is not really “reverse” SQLi because that doesn’t really add up technically.

In event that you would like to configure your servers to reply with different responses, check out the following links:

Apache: http://httpd.apache.org/docs/2.0/mod/mod_headers.html

IIS7:http://technet.microsoft.com/en-us/library/cc753133(v=ws.10).aspx

NginX:http://blog.secaserver.com/2012/03/customize-server-header-nginx/

Also, I like this site for viewing HTTP headers where standard proxy means are not ideal. http://pgl.yoyo.org/http/server-headers.php

The recently identified botnet targeting Mac OSX machines, reportedly with more than 600,000 hosts compromised (conficker-sized!), uses the bot’s MAC address as the User Agent when phoning home to C&C.  Hosts infected with the Backdoor.Flashback.39 trojan can be identified with a simple regex looking for MAC address patterns in an organization’s proxy logs (see below for example regex’s).

We’ve also gotten our hands on some IIS log data from a recent high-profile breach.  What we found was very interesting.  The attackers didn’t bother to change the User Agent for the SQLi tools that were used.  Both Havij and sqlmap were identified.  Some simple whitelisting or blacklisting against the UA in the IIS logs would have easily caught these low-hanging fruit.

Stay tuned for more in-depth analysis of User Agent strings and HTTP Request Headers, as well as out-of-the-box content to help secure web applications using SIEM.

Example MAC Address Regex’s:

No dashes, colons, or spaces: [a-fA-F0-9]{12}

With dashes, colons, or spaces: ([a-fA-F0-9]{2}(:|-|\s)){5}[a-fA-F0-9]

UPDATE:

Kaspersky Labs gives an example User Agent string for the Flashback malware.  Here’s a regex that will match it in proxy logs: id:[a-fA-F0-9]{8}-\w{4}-[a-fA-F0-9]{4}-\w{4}-[a-fA-F0-9]{12}

Today’s blog entry is the third and final blog in the series on SIEM features which support continuous monitoring requirements. The past two blog entries covered situational awareness, threats, assessing security controls, and collecting, correlating, and analyzing security information. In today’s entry I will cover security status communication and risk management requirements for continuous monitoring.

The FIFTH requirement is “providing actionable communication of security status across all tiers of the organization.” This requirement has to do with the organizations capability to provide accurate communication on the current security status of the organization at all levels within the organization and provide recommended action when needed. This particular requirement is focused on defining, providing, and communicating security status and metrics. A SIEM should be capable of providing notification of security-related issues to owners of particular systems allowing them to take remediation action as necessary. The more advance SIEMs actually have the capability to provide automated remediation actions when specific issues are identified. The metric portion of the requirement quantifies the current status of information security at all levels of the organization. The SIEM at a minimum should be able to provide an audit trail of the actual uses of the SIEM as part of a metric. The SIEM should audit alerts generated by critical events, the analyst’s acknowledgment of the alert, investigations initiated by the analyst in response to the event, and actions taken to remediate the threat of the event, and review of the event by management.

The SIXTH and final requirement is “active management of risk by organizational officials.” This particular requirement indicates that management must actively manage organizational risks. This is really an extension of the risk assessment process which ensures all risks are identified, mitigated, and acknowledged by management. A SIEM should extend managements view of the organizations risk landscape by providing a view of critical risks such as threats and vulnerabilities, and provide visibility to the effectiveness of mitigating controls such as anti-malware, firewalls, IDS, patch management, vulnerability scanners, etc…
A SIEM can be a powerful tool to meet continuous monitoring requirements through automated means. Keep in mind not all SIEMs are created equally and some provide limited functionality at a premium price. Ensure the organization performs an in-depth review of the regulatory requirements along with functional requirements before a SIEM selection is made. Robust SIEMs often provide mappings of key features directly to regulatory control requirements which they meet or supplement. Advance SIEMs which provide capability such as built-in alerts, threat advisories, and automated remediation functionality can help organizations stay informed and better prepared to quickly remediate security risks.

Today’s blog entry is a continuation of yesterday’s blog on SIEM features which support continuous monitoring requirements. Yesterday’s blog covered situational awareness and threats. In today’s entry I will cover continuous monitoring requirements for assessing security controls and collecting, correlating, and analyzing security information.

The THIRD requirement is “assessing all security controls.” For this requirement the organization must assess all implemented security controls to insure they properly mitigate the threat as intended. This is best accomplished by having a 3rd party perform an annual review of the organizations information security controls. The third party should be versed in reviewing controls specific to the organizations regulatory requirements. Organizations should also be conducting internal assessment in an ongoing basis in order to supplement the third party review. A SIEM should be able to help with this assessment by providing support for vulnerability and patch management. SIEMs should be capable of collecting notifications of vulnerabilities from anti-malware, firewalls, IDSs, and vulnerability scanners along with patch management notifications from hosts. The more advanced SIEMs actually have the capability to import vulnerability scan results or even launch scans from the console which allows for the verification of an identified vulnerability.

The FOURTH requirement is “collecting, correlating, and analyzing security-related information.” This is a mandate for organizations to collect security relate information, correlate the information with multiple sources, and analyze the information in order to properly assess the risk. All SIEMs should directly support the event & incident management process by automating the collection, correlation, analysis, and risk rating of security related information. SIEMs should collect information from a variety of logs (applications, hosts, network devices, physical devices, security devices, etc…). One of the most important things to understand about a particular SIEM is what systems they can collect logs from, how the collection occurs, and what can be done if a system log is not supported. A SIEM compatible with an organization should have the capability either native or through custom parsing to collect security information from all in scope systems. It is best practice for SIEMs to archive and retain logs in the original state for no less than one year in order to provide forensic investigation support. Be sure to tune in for tomorrow’s blog entry where I will finish the discussion by covering security status communication and risk management requirements for continuous monitoring.

Continuous monitoring is one area where most organizations often experience audit related issues during their regulatory review. The most typical issues are often related to analyzing security related information and assessing security controls. Many of my clients would enable logging on the majority of their systems but would not actually analyze any of their logs due to the large volume. I can certainly empathize with them having been in their shoes myself. However it’s not acceptable to stop monitoring critical system logs because the task seems too daunting, there is a better way. A robust SIEM (Security Information and Event Management) solution can centrally collect millions of logs, correlate information across the organizational infrastructure, and alarm on user-defined critical conditions resulting in a manageable subset of security related events. There are many different players in the SIEM market and a wide range of functionality offered; over the next three days my blog entries will tell you about specific features to look for in a SIEM to help meet continuous monitoring requirements.

FIRST, it is important to understand the six main continuous monitoring requirements outlined in NIST (National Institute of Standards and technology) 800-137 before seeking a SIEM solution. The first requirement is “maintaining situational awareness of all systems across the organization.” This describes the need for the organization to keep an awareness of all systems in their organization. Organizations should have an asset management program which actively maintains inventories of systems, software, and network diagrams. A SIEM should supplementary support the asset management program by providing details of all known assets (hosts, network devices, physical devices, security devices, etc…) within the organizations infrastructure. It is also best practice to implement technologies such as NAC (Network Access Control Systems) which have the ability to detect unidentified systems and deny them access to the infrastructure. A SIEM should also collect logs from these types of devices and generate alarms when unidentified systems are detected.

The SECOND requirement is “maintaining an understanding of threats and threat activities.” Organization must stay up to date on current threats and have the capacity to identify specific threats to their organization to meet this requirement. They are expected to keep their knowledge of threats current by researching in-scope threats to their systems on a regular basis. There are a variety of content providers which focus on providing threat advisories via RSS feeds. Organizational threats should be identified and assessed through the risk assessment process. However a SIEM should provide continuous threat assessment by collecting, correlating, and identifying threats from network and host anti-malware systems, firewalls, and IDSs (Intrusion Detection Systems). The more advanced SIEMs have the capability to give additional information about an identified threat through knowledge bases or 3rd party advisories.

Tune in for tomorrow’s blog entry where I will continue the discussion by covering requirements for assessing security controls and collecting, correlating, and analyzing security information.