Search results matching tag 'URlScan SQL Injection'

What to do for a rootkit...

rgsnowman — Sun, 14 Jun 2009 13:01:38 GMT

I have recently found a rootkit on my computer through AVG and am wondering how to get this thing off. I tried to get AVG to delete it but it said it cannot. I heard you can re-install windows vista and also restore default settings but I am not sure if that deletes everything and I'll have to get external hd and if the rootkit would get itself into there and I'd be re-installing a rootkit. This rootkit is screwing up my xps one it tiny ways, it changed all my security setting and turned my anti-viruses off and I can't turn them back on, messed up background, screwed up start menu and toolbar, and the side panel. I just want to know the best way to get this off computer. Thanks in advance.

URLScan Recycle

jeremyn11 — Fri, 05 Sep 2008 18:24:12 GMT

In our URLScan logs we get the following quite a bit

- - - - - - - - - - - - - - - - - - - - - - - -

#Software: Microsoft UrlScan 3.0

#Version: 1.0

#Date: 2008-09-04 01:01:20

- - - - - - - - - - - - - - - - - - - - - - - -

Does anyone know if this means that UrlScan is recycling and we have a period of time where something like an SQL injection (if you setup the filters of course) can get through?

Respectfully,

-Jeremy

URLScan 3.0 RTW: [AlwaysAllowedQueryStrings]

jgraham — Tue, 02 Sep 2008 13:46:32 GMT

Doing some testing, currently, and running into some issues with this.

We've got a couple cases where things like 'cast' or 'open' are appropriate for our webpages.

I've setup an AlwaysAllowedQueryStrings section:

[AlwaysAllowedQueryStrings]
branch=Openshaw
branch=Newcastle+upon+Tyne

Now, this is great... and it works fine, if I look up /town.asp?branch=Openshaw

However, some of our pages will send branch=Openshaw&x=22&y=9 and URLScan appears to be treating "&x=22&y=9" as part of branch=

Is there any way around this? The product could really save us while we hound vendors to update their code to account for SQL injection/etc. But with these cases, it would do about as much harm as good, at this stage.

Thanks in advance.

Re: urlScan 3.0 rtw [AlwaysAllowedUrls] not working? Wildcard/regex in [AlwaysAllowedQueryStrings]

ytkaczyk — Thu, 28 Aug 2008 15:46:00 GMT

Hi Zhao,

Thank you for your reply. I now understand how [AlwaysAllowedUrls] works and where the query string check is still performed on the allowed Urls.

To clarify, here is what I would like to achieve. For instance, I would like the following 'url+query string' to be valid:

http://www.domain.com/search.aspx?keyword=declare(exec(...))

with proper escaping of course. I initially added the following to the urlscan.ini

[AlwaysAllowedUrls]
/search.aspx

but as you explained this should not and did not work. Looking at the documentation and from my experimentation, there is no way to introduce any wildcard in the [AlwaysAllowedQueryStrings] section which is what I would need here. Ideally, I would like to be able to define something like (if regex if possible):

[AlwaysAllowedQueryStrings]
keyword=.*

Is this possible? This would be very useful for implementing the Sql Injection custom rules.

Thank you,

Yves

urlScan 3.0 rtw [AlwaysAllowedUrls] not working?

ytkaczyk — Mon, 25 Aug 2008 18:30:45 GMT

I would like to allow a search page to accept all text in the query string. To do this I added the result page to the [AlwaysAllowedUrls].

One thing that is ambiguous from the documentation is if the [AlwaysAllowedUrls] settings also bypasses the custom rules and if the pages listed in [AlwaysAllowedUrls] can have any query string values. It does not seem to be the case but I thought I would check. Could anybody shed any light on this?

Thank you.

Yves

Re: Requests to / and /default.aspx with URLScan 3.0 rtw handled differently

ytkaczyk — Mon, 25 Aug 2008 18:27:20 GMT

You need to capture the 'extensionless' requests by adding the . extension to the ApplliesTo section:

[SQL Injection Raw]
AppliesTo=.asp,.aspx,.

Yves

Re: UrlScan 3.0 Beta not capturing SQL Injection

apajlopez — Mon, 18 Aug 2008 12:51:54 GMT

Rovastar,

I can confirm that the workaround that KentZhou posted works. I have included below the contents of the RuleList section in the UrlScan.ini as I have it in my test box.

After changing the rule though I issued an iisreset /restart command before I tested so the UrlScan.ini's settings were taken into account. I don't know if there is a cycle by which these settings in the .ini file are refreshed.

I tried issuing the following request, all of which were stopped by URLScan:

http://localhost/?declare
http://localhost/default.asp?declare
http://localhost/default.aspx?declare

RuleList=SQLInjection

[SQLInjection]
AppliesTo=.asp,.aspx,.
DenyDataSection=SQL Injection Strings
ScanUrl=0
ScanAllRaw=0
ScanQueryString=1
ScanHeaders=

[SQL Injection Strings]
--
%3b ; a semicolon
/*
@ ; also catches @@
char ; also catches nchar and varchar
alter
begin
cast
convert
create
cursor
declare
delete
drop
end
exec ; also catches execute
fetch
insert
kill
open
select
sys ; also catches sysobjects and syscolumns
table
update