Malicious SQL injection blues?

by John Holbo on October 27, 2008

Someone left a comment to my Blues Verification post, saying that when they visited the page in question their A-V software terminated the connection upon detection of a “HTML:Iframe-gen” virus, which, a quick Google informs me, might mean some sort of malicious SQL injection thingy. Does anyone know about such stuff? I certainly would feel bad about sending lots of readers off to some compromised site to get infected with malware.



John Holbo 10.27.08 at 3:20 pm

Bonus points for enunciating the answ, whatever it may be, in classic ‘got them old malicious SQL injection blues’ form.


Chuchundra 10.27.08 at 3:34 pm

Yes, Trend gives me an error as well

The URL that you are attempting to access is a potential security risk. Trend Micro OfficeScan has blocked this URL in keeping with network security policy.

Odds are that the site has been compromised. It’s very common these days, especially for sites that run on older versions of WordPress. It’s happened to me a couple times. I have a half dozen or so WordPress blogs. The cleanup process can be pretty painful, even if you’re a tech savvy person like myself.


Doctor Memory 10.27.08 at 4:34 pm

Yeah, it looks like is well and truly ownz0r3d as the kids say. Buried in the front page html is this charming little turd:

iframe src=”″ width=1 height=1 style=”border:0″

It might be a dead letter though — doesn’t appear to be up and serving at the moment.

Sorry, too early in the a.m. to do this in the proper meter.


Martin Bento 10.27.08 at 5:18 pm

(note: in some circles, SQL is pronounced “sequel”)

I thought I had the SQL injection blues
Thought I’d got SQL’d down to my shoes
I guess what I gotta face is
It only hits databases
It must been used to get the virus on the server
But now what’s hitting me is just plain ole malware.


Martin Bento 10.27.08 at 5:29 pm

I though I had mal
but it’s just a bad frame
Someone got into the file
and dropped a bomb in the game
Did they pull SQL on the server
or just become root?
Will they get what they deserve or
are these questions moot?


Martin Bento 10.27.08 at 5:48 pm

The charming little turd takes me to a new page
The charming little turd gives reason to spew rage
The charming little turd is something I can’t see
The charming little turd goes on a shooting spree
of code that spews who knows what
like a hole of Java butt
The charming little turd, it doesn’t even smell
The charming little turd is between me and McTell


Jonathan Hart 10.27.08 at 6:02 pm

It is not a SQL injection attack as the poster in that thread states. SQL Injection attacks only happen when a hacker wants to hack a website, not when a hacked website wants to infect a browsing user (I wont go into the details but if you want to know, email me :) )

It’s possible the hacker used SQL injection to hack the original website, but I wouldn’t even bother speculating on that. Just stay far away from these sites and make sure you’re running the latest browsers.


Martin Bento 10.27.08 at 6:16 pm

Jonathan, I think I already said that, but I possibly sacrificed clarity for verse.


Jonathan Hart 10.27.08 at 6:20 pm

Ah, I see that now, Martin… The cognitive dissonance of seeing geek-talk in poetry temporarily suspended my attention :)


justcorbly 10.27.08 at 8:02 pm

I’m not running any anti-virus softwre but I can attest that this site was timing out this morning.


john b 10.27.08 at 8:25 pm

“Just stay far away from these sites”

Only if you take a very risk-averse view on the ‘excellence of blues’ versus ‘miniscule chance of malware infection’ trade-off. I’m firmly on the ‘excellence of blues’ side…


sidereal 10.27.08 at 10:24 pm

Jon/Martin: SQL Injection is the mechanism by which the iframe was inserted into the site’s source. There’s been a massive outbreak of these attacks over the last 6 months or so. Once the iframe is injected into the site source, browsers are triggered to download a Trojan (usually it’s only IE that’s vulnerable, but not always). You’re right that the browser is at risk of a forced Trojan install, not a SQL Injection. But the SQL Injection is the vector to get bad code onto otherwise trustworthy sites.


Jon H 10.28.08 at 1:13 am

Some people pronounce SQL as ‘squeal’, which might help.


Martin Bento 10.28.08 at 2:00 am

Geez, I guess it doesn’t pay to get playful with geekspeak. Thanks, sidereal. I know SQL Injection is a way to get this stuff onto the database server, and said so.

I guess what I gotta face is
It only hits databases
It musta been used to get the virus on the server
But now what’s hitting me is just plain ole’ malware.

I think Jonathan knew it too. I didn’t know for a fact it was what was used in this case, but, as I suggested, for the purpose of the client the question is moot.

Did they pull SQL on the server
or just become root?
Will they get what they deserve or
are these questions moot?

Expressions like “pull SQL” are neologistic, of course, as is the word “neologistic” (Hey, kids! Recursion!). But you can do things like that in verse; they’re fun even.

To go more straight geek for a moment, the database user a web page connects as should not have DML privileges on the tables containing the code for that page, just query (if it needs to modify those tables, you probably need to change your database design). And it all should be encapsulated in stored procedures anyway, if the database supports such. Does anybody really want the conversation to go in this direction?


James Wimberley 10.28.08 at 8:46 am

Does Silicon Valley run a needle exchange programme for SQL injectors?


lemuel pitkin 10.28.08 at 4:47 pm

Does anybody really want the conversation to go in this direction?


Altho linking to a good overview of these types of attacks might be better than trying to explainthem here in mock-blues.


Martin Bento 10.29.08 at 2:36 am

Well, I don’t know a good overview, and I don’t feel like reading through some bad ones, so I’ll just roll my own. Some of this is what I said above, but more unpacked.

1)A website using a database should be using some server-based language like PHP, ASP, Python, Server-side Java, something like that. Don’t directly send SQL from the browser.
2)This server process will connect to the database as some database user, which is independent of OS users. This is where people get stupid. SQL has very granular permissions (“privileges” in SQL-speak) on database tables, but developers frequently have their websites connect to the database as the same user used for development, which will be a superuser (“DBA” in SQL). Create a user for your production web process to use that has only the needed privileges. You may have some tables that store data, for example, if you have user registration or use cookies. These should be separate from the tables that hold your web pages (for reasons beyond the security concerns; it would be really dumb to do it otherwise). On the latter, give your user only read, not write, privileges. In SQL, read operations are called “queries”, and the command and privilege are both called “SELECT”. Write operations are divided into INSERT, UPDATE, and DELETE, both privileges and commands, and are collectively known as “DML (Data Manipulation Language)”. Doing this would have stopped the SQL injection used here, although there are a few kinds, like DOS queries, that it may not stop.
3)Even better is to use stored procedures, if your database supports them. This means you write your data manipulation code in some language that is executed within the database as procedures or functions and give your website only the EXECUTE privileges on these procedures, not access to the underlying tables. A SQL injector knows about standard SQL commands like SELECT and CREATE; it does not know about your procedure “JumpAroundStupidly”.
4)Also validate the data before you pass it to the database. Simple trick: disallow semi-colons. Semi-colons are the command terminator in SQL and are how injectors typically interrupt your regularly-scheduled website for a special message from God-Knows-Where. How many people have semi-colons in their name or address?
This is all pretty basic, and I imagine you could find much more elaborate ideas. But I think this would suffice for the injector we’re dealing with here, and probably a lot of them. It has a couple of layers, making it harder for the dubyas(fn 1) who come to the code after you to screw it up. The commands you want to look up in your SQL manual are these:

CREATE USER or CREATE SCHEMA to create users.

GRANT and REVOKE to control privileges.

CREATE PROCEDURE, CREATE STORED PROCEDURE, or CREATE FUNCTION for stored procedures (this area is a bit less standardized).

Hope this helps.

fn. 1 As a fitting legacy for our current President, I am promoting the user of “dubya” as a generic term for moron or imbecile. Having a President with such a distinctive nickname has come in handy. It also works as a verb. e.g., “ I really dubya’d up that test”.

Comments on this entry are closed.