Broadband Tech > Security > Security > Filtering character sequences in firewalls

Filtering character sequences in firewalls

Secunia's advisory faulted IE for an "input validation
error" that let a certain character sequence mask the
actual Web address and substitute a fake one.

It recommended using a proxy server or firewall to filter
the character sequence out of Web addresses

If you can block any URL with an at sign ("@") in it that would do the trick. I don't know of any personal firewalls that allow this though, that I know of. I could be wrong though.

KJP

reply to Bubba
I would be interested in the answer, as well.

reply to Bubba
You need a firewall able to examine html traffic. I'm not sure if any of the personall firewall are able to that. So use Proxomitron instead to filter all the traffic as per

»www.securityfocus.com/archive/1/···-12-14/0

"..So, anyone busily setting up further filters
in any sanitizing procedures for incoming HTML should not only be
looking for "%01" but straight 0x01 characters (although reliably
interpreting this when combined with scripting -- see below -- might be
a headache).."

Cudni

reply to kpatz

said by kpatz:

---

If you can block any URL with an at sign ("@") in it that would do the trick. I don't know of any personal firewalls that allow this though, that I know of. I could be wrong though.

KJP

---

reply to Bubba
Proxo filter writers, take note... this should be defusable, as a stop gap measure, with a filter... I intend to have a look later on this evening, time permitting, for a quick way of getting something into proxo. Firewalls will only do this job if they're "security suites," with built in web filters... not the job description of packet filtering, in a general sense... this is web content filtering...
--
The willow bends unbroken when angry tempests blow,The stately oak is levelled and all its strength laid low...Oliver Wendell Holmes
Even when you feel like your life is fading
I know that you'll go on forever
You're that good...

reply to Bubba
OK, here goes. We need some independent verification. After experimenting with a few ideas, I had an idea for a temporary, quick fix. Testing on our example page (from the BBR frontpage) »i.dslr.net/symantec/worse2.html, it seems to defuse the exploit, at least as an interim quick fix, inelegant as it may be, and it's as simple as adding the following strings to your "Ad-User-Domains" list in Proxomitron...

*%1*.*
*%0*.*

and, if desired:

*@*.*

I took these constructs from what I seem able to piece together on a very quick, cursory examination of the exploit. I figured adding three lines to a block list file would be easier than setting up a new filter, and I figure this is a proposed (and untested, except quickly, by me) down and dirty interim patch, until some of the more qualified proxo gurus (uhhh -- JD5000... are you out there ) can look things over, and, perhaps, get something better worked out...

Please, let us know how things work out, if you decide to give it a whirl... What it appears to do is strip the url effectively enough to deliver you to the real website, instead of the bogus one... hope it really is effective ...
--
The willow bends unbroken when angry tempests blow,
The stately oak is levelled and all its strength laid low...
Oliver Wendell Holmes

Even when you feel like your life is fading

I know that you'll go on forever

You're that good...

reply to Bubba
I just happened to go off on a Symantec search for firewall rules last night. Some of this may be relevant, some may not. Why let all this go to waste?

I may never get these rules straight!

How to configure Symantec Enterprise Firewall to block Nimda and Code Red worms
»service1.symantec.com/SUPPORT/en···=&csm=no

Search Results for: filtering character sequences in firewalls > norton internet security 2003:
»search.symantec.com/custom/us/te···3A%2Feme a-entcustserv.nsf%2F+url%3A%2Favcenter%2Fvenc%2Fdata&search.x=36&search.y=19

Default firewall rules for Norton Internet Security and Norton Personal Firewall
»service1.symantec.com/SUPPORT/ni···=&csm=no

Search Results for: 2003 advanced > general rules:
»search.symantec.com/custom/us/te···&action=

Search Results for: default firewall rules for norton internet security 2003 and norton personal firewall:
»search.symantec.com/custom/us/te···3A%2Feme a-entcustserv.nsf%2F+url%3A%2Favcenter%2Fvenc%2Fdata&search.x=32&search.y=13

Search Results for: 2003 default firewall settings:
»search.symantec.com/custom/us/te···3A%2Feme a-entcustserv.nsf%2F+url%3A%2Favcenter%2Fvenc%2Fdata&search.x=32&search.y=14
--
oO^..^Oo__Computer Infected? Read me!__oO^..^Oo

reply to Bubba
I see not way to fix ZAP to block/stop this either

OK Proxomitron was mentioned anyone tried this with success who uses it?

Also is WebWasher a tool that can deal with such a problem? I tried it like 2 years ago and can not recall what all it does.
--
arf, bow wow, woof!

reply to Bubba
I'll check sonicwall's content filter tomorrow and report back if it works..

reply to Bubba
Who knows how to write Perl-style substitutions?

If so, Privoxy will do the job.

If anyone would like to IM me, I will send Privoxy's pattern matching defaults, so that you can send me back a suitable substitution. I will test it and report back here.
--
Falsehood, Like a Nettle, Stings Those Who Meddle With It - Inquire Within Upon Everything (1880?)

reply to Bubba
Regular expressions? I used a simple wildcard, and told it to kill anything matching the wildcard expression... that is, just kill any URL with %0, %1, or @ (optional) in it. That should work on any proxy that reads regular expressions... Due to the odd mechanism IE uses to pass the url, the net result with proxomitron seems to be that the URL that appears in the address bar is the one that's sent, stripping off the excess that doesn't appear. The "dummy" page is so real, it took me a few visits to verify it's really Symantec I'm getting, with the new match added, but it is... all the links work, and it checks out. Reverse DNS of my netstat confirmed I was on the "real" akami sub-hosted Symantec page... which is hosted out of verizon-gni, at

Canonical name: a568.x.akamai.net
Aliases:
www.symantec.com
www.symantec.d4p.net
www.symantec.com
Addresses:
130.81.64.26
130.81.64.27
130.81.64.13
130.81.64.18
130.81.64.20
130.81.64.21

... for anyone trying any tests of their own.

Now, rather than mess with any complex pattern matching, what I decided to do was just swat the fly with a baseball bat, as it were, and wildcard the match. Crude, but effective, and gets something out and up on my proxy to see how it works... wildcarding should work (being a natural subset of regular expressions ) quite effectively with any proxy that uses them. The remaining task is to tell your proxy, in whatever specific constructs it recognizes, "if you see this pattern in a URL, terminate it with extreme prejudice"... in proxo, that's just "/k," in the "replacement" box, if you want to tinker with a specific rule... but that could involve some time consuming tinkering to get just the way you want it... most any proxy that filters ads, etc., has the necessary rule preconstructed, somewhere in its filter set...

Here's my logic: almost every proxy server parses some kind of "URL kill list", rather than having an individual filter for every single restricted IP and URL ... it might be called the "ad list" or the "killfile" or whatever, but it's generally a plaintext and regexp list of IP and URL combinations you want blocked... so putting those two or three wildcarded expressions I offered into that "killfile" should do the deed... until we possibly come up with a more elegant regexp to handle it... if your proxy recognizes regular expressions, in other words, universal wildcards, being a subset of regexps, are the down and dirty quickest way...

By the way, the "@" [ *@*.* as it would appear in the file] is unnecessary; using the *%1*.* and *%2*.* matches seems to work just fine, for me, with this test page...

In fact, I should have been more explicit... this pattern match should work with any filtering proxy that has a list of blocked urls and recognizes regular expressions... if you just add it to your list of blocked URL's. You can always delete it, if it causes a problem, doesn't work, or if something better comes along...

gone phishing...
--
The willow bends unbroken when angry tempests blow,The stately oak is levelled and all its strength laid low...Oliver Wendell Holmes
Even when you feel like your life is fading
I know that you'll go on forever
You're that good...

reply to Bubba
I put those filters in WebWasher and blocked a lot of things.

With both the URL and Access filter, »www.securityfocus.com/archive/1/···2-symnsj. did not show up as a hyperlink. With just the access filter it would show up as a link but WebWasher would block the page.

WebWasher would block this link. »media.wushuonefamily.net/media/w···ands.mpg

It also blocked all but the top link in this post. »Re: Filtering character sequences in firewalls

This Phish POC »www.zapthedingbat.com/security/ex01/vun1.htm was not blocked.

And the DSLR POC, »www.symantec.com
@i.dslr.net/···dex.html , when the link appears, was not blocked.

reply to Bubba
Thanks...

Here's what I get...

The bugtraq archive gives me a page, and tells me the "post does not exist"

wushonefamily.net works for me... a quicktime displays...

the linkback to the DSLR page works fine...

BAD... zapthedingbat shows MS in the addressbar, and does not redirect to the legitimate webpage... I get a blue MS banner and a single text line informing me my address bar should show microsoft.com --- it does...

The local test page (link broken above) loads the REAL Symantec page... I verified this by checking my outbound connections, and looking up symantec's legitimate site... that's where I ended up, with the filter ...

It looks, overall, though, that even with Proxo, that "Phish POC" page DID make it through... so it's

... back to the proverbial drawing board.
--
The willow bends unbroken when angry tempests blow,
The stately oak is levelled and all its strength laid low...
Oliver Wendell Holmes

Even when you feel like your life is fading

I know that you'll go on forever

You're that good...

reply to Bubba
K-Meleon 8.1 has been fixed to avoid this type of phish. It correctly goes to the url after the '@'-sign. It also displays this url 'down below'.

Any attempt to use a malformed url of this type without the '@'-sign only results in "xxx.yyy(phish)zzz.aaa.bbb could not be found. Please try again".
--
Falsehood, Like a Nettle, Stings Those Who Meddle With It - Inquire Within Upon Everything (1880?)

reply to Bubba
You have to remember that if you're going to add a Proxomitron filter for this phishing exploit, it won't protect you against the use of a phished URL in an HTML email.
--
"Security is a tax on the honest." --Bruce Schneier, Beyond Fear, Copernicus, 2003

reply to Bubba
man I can,t get my proximitron to work, sort of had it running before my HD crashed. Anyone nice enough to send me thier config file that successfully hides your IP along with the new character foiling trick as well..pm me!

regards

reply to Bubba

quote:

---

It recommended using a proxy server or firewall to filter the character sequence out of Web addresses

---

reply to Bubba
Proxomitron can filter https

Enabling SSL Filtering

If you want to use the SSLeay .DLL files to filter Secure (») pages, you need to check the box here after adding the .dll files to Proxomitron's program folder.

However, Use this with caution! If the SSL is being used for something sensitive (like on-line banking or credit card purchases) you're probably better off not filtering the connection.

Also this option is only available after you place the ssleay32.dll and libeay32.dll files in Proxomitron's program folder. Because of the laws regarding exporting cryptography from the US, Proxomitron does not include these .DLL files. However with some luck you may find them as part of other packages.

reply to Bubba
Unfortunately, Proxomitron has trouble with a header filter. It can't seem to parse the URL before the "@". Project's on hold, but by no means forgotten...

Maybe it could test the pages for tampered url's and flag or block them... well, more in due time, I guess...

SSL: Yes, and I do filter SSL, but with this caveat - I bypass for sites I do business with. If I trust the site to use the SSL ofr its intended authentication purpose, I trust them for the proxy, as a general rule... but if I just surf in somewhere, I don't automatically trust them, and I don't need their credentials unless and until I decide to trust them... so I let Proxo act as my border guard until then. SSL doesn't need to be a tunnel to the world, as I figure it, just a tunnel to my trusted sites. No business relationship, no need to establish a trust relationship, either, as a rule...

Mail: I do filter my mailclient, since it is HTML, after all, and the client's acting as a browser when it displays. No lower chance HTTP content in a mail is malicious than surfed to on the web... greater, even... so I shape on the firewall, and send all untrusted http connections only through Proxo. Of course, embedded HTML in an e-mail can present special filtering problems, too... by the way, doesn't Outlook take proxy info from IE? If so, it would default to try and conect through proxo... I would (especially with OE; I use Pegasus, myself, where you have to authorize web content before it displays) leave it do so, and make a firewall rule allowing the loopback connection, and another denying any other connections whatsoever, if appropriate on your firewall, to force the mailer through the proxy...
--
The willow bends unbroken when angry tempests blow,The stately oak is levelled and all its strength laid low...Oliver Wendell Holmes
Even when you feel like your life is fading
I know that you'll go on forever
You're that good...