Question on exploit to Javascript pros

[LotsOfZeros]

I've been given the task to locate the source of a recurring exploit. It's an iframed js exploit of some sort. AVG calls it "Exploit Javascript Obfuscation (Type 1938)" that keeps showing up on the main page of a site.

Site passwords have been changed

I've been able to determine the iframe disappears when clearing the cache on the site. The site was built on some old CMS that's no longer supported so it's no wonder there aren't more holes in it. The CMS also has some sort of export to html function where, from the admin panel, you can export your site's pages to static html files. Once I use this function, the iframe code shows up in these static files. The actual templates are kept in the mysql database and when viewing the html code in the database field, the iframe code is not present.

So, exploit code is present in cached pages, not fresh ones.. and .. code gets somehow injected upon exporting site pages to static html. I'm just about to edit those and ditch the CMS but I don't really have the time to rewrite all of the image, css, jquery file paths so basically does anyone have any idea how this is happening?

 

[stevehnsn]

I don't think that's enough info to diagnose the problem. All I can think of, is that the hacker is injecting sql into the query that pulls the template out of the database, but you probably already knew that. I think we'd have to look at the code to determine the exact cause.

 

[erect]

Most CMSs will pass all garbage through display pages (php or whatever) ... typically they'll save the whole page into a variable then output it at the end. If this is the case, do something to break the iframe, or if the code is static you can remove it all together on the spot.

That's not cleaning your problem. But it sounds like you'd prefer it to go away asap.

Option 2: export all to static html then do some htaccess magic and write a new custom script that simply displays what's in database since the iframe isn't present in mysql. The rewritten exploit is piggybacking the CMS, unless you want to dig deep, working around might be your fastest fix.

 

[mattseh]

Dump CMS, exporting all pages, regex out the iframe on all the pages.

Or, grep the database and all files to see where the iframe generating code is.

 

[Mahzkrieg]

To rule out the most common injection attack, search your source for "base64", "decode", and "eval". The reason you usually can't just grep the footprint of malicious code is because it's typically encoded and then wrapped in something like "eval(base64_decode("3nc0d3d5cr1pt..."))"