Adobe's Serious Magic site SQL Injected by Asprox botnet

Adobe's Serious Magic site SQL Injected by Asprox botnet

Summary: According to SophosLabs Adobe's owned has been automatically SQL injected by the Asprox botnet, becoming the very latest high profile legitimate web sites injected with links to exploits and malware serving sites :"The infection, which resides at hxxp://www.

TOPICS: Security

Adobe asprox malwareAccording to SophosLabs Adobe's owned has been automatically SQL injected by the Asprox botnet, becoming the very latest high profile legitimate web sites injected with links to exploits and malware serving sites :

"The infection, which resides at hxxp://, instructs users browsers to silently install a malicious file from a series of domains known to host attack sites. Adobe announced its acquisition of Serious Magic two years ago and whois records indicate the company is the owner of the domain.

According to this post from anti-virus provider Sophos, Adobe was notified of the infected page on Friday. The Register visited the link (using a virtual machine, of course) on Thursday and found it was still trying to redirect users to a series of nefarious sites including hxxp:// w.js and hxxp:// While those links no longer appeared to be active, two other sites used in the attack, hxxp:// w.js and hxxp:// new.htm, were still active at time of writing."

With the asprox botnet making an appearance at the sites of Redmond magazine, and Sony Playstation in May and June respectively, is once again among the several hundred sites injected with the same malicious domains.  Let's take a peek at this malware campaign, and see where it ends.

Adobe asprox malwareIn short, every tutorial entry is SQL injected with a malicious domain, which means that if there are 60 tutorial entries, the malicious javascript loads 60 times ending up in an endless loop of redirections to other malware and advertising revenue earning domains set up in this campaign. More specifically, the malicious w.js attempts to execute a multitude of already patched client-side exploits, using the following structure and ultimately leading to a copy of Worm.Win32.AutoRun.qtg with a high detection rate (29 AV scanners out of 36 detect it - 80.56%) : /csrss/ new.htm /csrss/ flash.htm /csrss/ i1.htm /csrss/ f2.htm /csrss/ i1.html /csrss/ flash112.htm /csrss/ ff.htm /csrss/ xl.htm /csrss/ mi.htm /csrss/ real10.htm /csrss/ real11.htm /csrss/ rondll32.exe

Despite Adobe's delayed response and the fact that the domains are still active, they seem to have solved the issue by redirecting all traffic from the site to the clean

Topic: Security

Dancho Danchev

About Dancho Danchev

Dancho Danchev is an independent security consultant and cyber threats analyst, with extensive experience in open source intelligence gathering, malware and cybercrime incident response.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • "But I only go to safe sites"

    This is why I want to slap everyone who says that is protection against infection.
    • No doubt, especially while Googling.

      Its funny how people think they just go to legit and safe sites, especially when they go googling. They just don't get the fact that they need some protection no matter what. Trusting everything is not how you get through life unvictimized. That includes the internet and most everything in life, but this day in age its all too common.
    • That's true

      That's one of the reasons why i always use the No-script add-on with my Firefox browser when i use Windows. I'm also now doing far more internet browsing from inside Linux to provide added protection.
  • RE: Adobe's Serious Magic site SQL Injected by Asprox botnet

    I appreciate when articles like this give the user an advanced warning. However, I would like to see a message when the site has been "cleansed" so we can visit it without worry.
    Does this make sense to others?
  • RE: Adobe's Serious Magic site SQL Injected by Asprox botnet

    NO such thing as a truly "safe site" now days.

    Those days are long gone.
  • Wanna see something scary?

    Type ?"/csrss/w.js"? (with double quotes) into Google.

    A few of the result pages are articles like this one describing the hack, but the vast majority are actual hacked sites.

    And that?s just [i]one[/i] variant URL!

    This sort of thing is easy for web developers to avoid, though, but all too few do it.

    Rule #1: the old rules no longer apply. Merely using Parameterized Queries, once thought to be nigh-ironclad protection against SQL Injection, no longer suffices, for instance. Asprox will blow right past your Parameterized Queries as if they were ad-hoc queries assembled by unvalidated concatenation (the most dangerously vulnerable kind)!

    Rule #2: What DOES work against this, and is easily implemented, is limiting the total QueryString length. Design your .aspx (or other server-side) pages to require a minimum of parameters, preferrably short, preferrably numeric. Other info should be read from the database using the numeric info as a lookup.

    For instance, ??showarticle.aspx?id=1234?.

    If the maximum length of an article ID is, say, 5 characters (if using a Short Integer as the Primary Key), and there are no other QueryString parameters and you never use Anchor links (?#anchor?), then you can be sure that a valid QueryString would never be longer than 9 characters long (four for ??id=? and five for the digits in the short integer ID).

    So, the very first thing your code should do (e.g. in ?Sub Page_PreInit? if using ASP.NET) is check the total length of the complete Request.QueryString. If it?s ? 9 characters long, reject the request with a Request-URI Too Long status (HTTP 414).

    Of course, you should still follow all the usual rules: validate [i]all[/i] input (QueryString, Session, Cookie, and even database-read). [i]Never, [b]ever[/b][/i] have your Web server connect to your SQL server as DBOwner, or, worse, SA! The database logins and users used should have only the permissions needed to actually run the site, and it would be good to have multiple logins, such as a read-only one used on all SELECT queries that aren?t also tied to INSERT, DELETE, or UPDATE queries. Any page that just displays information, therefore, would use only the read-only login, so even if the hackers somehow got past all your other protections, the injection wouldn?t work because the database login would lack the permissions needed to execute it.

    Better yet, do everything with Views and Stored Procedures, and deny [i]all[/i] direct access (even SELECTs) of the underlying Tables (or any other Tables for that matter) to all logins used by the website. Of course, no Web login to the database should have permissions to execute any DDL statement (DROP TABLE, etc.), administration statement, [i]etc.[/i]
    Joel R