Technical question about webshield

[Tonanet]

Hello avast people.

I was wondering, lets say that you configure webshield to block the download of files with dangerous extensions as : .exe, .scr, .pif, .com, .bat, etc...
If you enter in a site with an exploit to the browser that you are using, and this exploit allows the site to download a file to your computer, without user intervention (i.e download dialog box), will web shield intercept this download? Or the exploits that allows files to be downloaded ignore webshield for some reason?

My bet is that webshield would block it, but no warning would be show... I guess as the exploit would use http connections to download the file, web shield would verify the .exe going throught it and would block it...

Am I right?

Thanks for your time,

Elminster

[DavidR]

I only have *.pif in my URL Blocking section, the wildcard is important as it could appear in a URL string. When I set this up I believe I tested it by using a test file. and you could do the same.

I couldn't get this to work in a test I just did because the test files were just txt files witf a changed file type not a true .pif or .vbs file. I also tried using an .exe file on a file sharing site but that too failed to alert and arrived in my downloads folder. So all I can assume that it didn't come down using http port 80 as it didn't appear on the web shield details of files as they were scanned.

[Tonanet]

Hello!

Thanks for your answer.

Yes, I set up using *.exe, and from my test I know that it blocked all download attempts, in the traditonal way (click on the download link).
But I couldnt test it against an exploit that auto downloads a exe file to the computer, because I dont know where I can find some site with this exploit, and problaby my system is already patched against the know ones...

Thanks for your time,

Elminster

[DavidR]

No problem, though I wouldn't try testing this using a known exploited site, you might catch cold. But I would have thought it wouldn't matter if it was a user requested download or a background download provided it came through the http port 80 proxy.

Some sites like download.com, snapfiles, majorgeeks, etc. have a link that you click to download a file (which isn't a direct link to the file) to initiate the download, you could try it on one of those with a small program.

[Lisandro]

Yes, I set up using *.exe, and from my test I know that it blocked all download attempts, in the traditonal way (click on the download link).

Yeah... this is how it works... You can use the other rare extensions for a download (.scr, .pif, .com, .bat, etc.).

But I couldnt test it against an exploit that auto downloads a exe file to the computer, because I dont know where I can find some site with this exploit, and problaby my system is already patched against the know ones...

If you find such a site, please, don't post here a live link to it

[RejZoR]

Such URL blocking only works when filename is located in actual URL address (for example http://testvirus.com/virus.pif ). If the URL is called like this (http://testvirus.com/index.php?action=download ) it won't be blocked (ive made up the last one, usually they don't look like this).

[lukor]

RejZoR is right, the blocked string must be in the URL, that somewhat limits it's usage. Other methods include checking the actual content - a thats what an antivirus in WebShield does :-)

The download method does not really matters. WebShield does not care if the browser will display the returned blocked page, or if it just blocks the download silently. However, some page is returned - avast! blocked content - and the silent downloader may even consider it to be the downloaded file so the HTML text might actually end up saved somewhere on the disk.

[DavidR]

What confuses me is that the URL Blocker allows for the use of wildcards, * and ? now based on that *.pif or *.exe would surely be a valid string ?

Yet as I said I tested downloading an exe file from rapidshare (small one which I uploaded) and the web shield didn't bat an eyelid, so I can only assume the download somehow evaded the web shield proxy.

[lukor]

Yet as I said I tested downloading an exe file from rapidshare (small one which I uploaded) and the web shield didn't bat an eyelid, so I can only assume the download somehow evaded the web shield proxy.

Does the url on rapidshare really ends with the extension (.exe in your case). I thought they use some strange ID numbers in URLs. If you have such a case when you think the download skips WebShield, please post it here.

[RejZoR]

It's related to my explanation. Rapidshare doesn't give browser a direct URL with file but rather a redirection.
Web Shield scans it (it's just a regular HTTP transfer), but blocker won't block it based on your extension block rule.

[DavidR]

Yet as I said I tested downloading an exe file from rapidshare (small one which I uploaded) and the web shield didn't bat an eyelid, so I can only assume the download somehow evaded the web shield proxy.

Does the url on rapidshare really ends with the extension (.exe in your case). I thought they use some strange ID numbers in URLs. If you have such a case when you think the download skips WebShield, please post it here.

This is the page that does the redirect/download the file, so I guess the .html invalidates the *.exe wildcard URL, I was hoping that even so the file would be coming down through the web shield proxy as mirror.exe. I monitored the web shield Last scanned: field but mirror.exe didn't feature.

Code: [Select]

http://rapidshare.com/files/44355971/Mirror.exe.html

The above file is just a DOS backup tool that mirrors target and destination files/folders/partitions etc. it requires a batch file to run the mirror commands so in itself it is inert.

[lukor]

what about this wildcard:

*.exe.* ?

(I must admit, I am not sure if this works or not)

[DavidR]

I don't know, but I wouldn't use that way as the exe.* would be likely to block some security sites that display virus information of files associated with a virus as some use the file_name.exe as the page name with .html tagged on at the end file_name.exe.html and the *.exe.* would assuming it worked trap that as well.

What I'm confused with, when the file arrives on my HDD it is saved as mirror.exe (the file I uploaded), so it must surely come down the pipe associated with that file name, see image. Regardless if that is correct or not, even assuming it wasn't an exe file, it wasn't scanned by the web shield 'at all.'

So this type of download is bypassing the web shield completely and could be a potential entry point for malware using the same delivery method, whilst this isn't serious if you are paying attention firefox asks what action to take. I don't know the inner workings of how rapid share achieves the download, if it doesn't use port 80 or not but the file wasn't scanned by the web shield. Because I was monitoring the web shield details I didn't see if the standard shield scan a newly created file (which I assume it did).