Slashdot Mirror


How To Evade URL Filters With (Not-So) Fancy Math

Trailrunner7 writes "In their constant quest to find new and interesting ways to abuse the Internet, attackers recently have begun using an old technique to obfuscate URLs and IP addresses to bypass URL filters and direct users to malicious sites. The technique takes advantage of the fact that modern browsers will allow users to specify IP addresses in formats other than base 10. So a typical IP address that looks something like this — 192.10.10.1 — can also be written in base 8, hexadecimal or a handful of other formats, and the browser will recognize it and take the user to the specified site. What is interesting though is that due to the relative obscurity of using such methods to denote an IP or URL, it is quite feasible that existing security products do not correctly identify the URLs as valid or flag them as malicious when they point to existing known bad websites."

6 of 162 comments (clear)

  1. And the lesson people don't learn is... by Estanislao+Mart�nez · · Score: 4, Insightful

    You can't just do things like this based on the syntax of the input, but rather on the semantics. In this case, to properly block the URLs, you need to parse them and transform them into an abstract representation of what they mean, e.g. a struct that encodes the protocol, host, port, document and query strings, and then examine the parse result to check if it matches the rule.

    The IT industry just systematically fails this over and over, because of people's bad habit of doing shit with regular expressions instead of parsing and semantic analysis. See, for example, the gazillion ways that people get around cross-site scripting filters; or if you want to see it from the other angle (generation instead of parsing), see SQL injection.

  2. Why? by Anonymous Coward · · Score: 4, Insightful

    Who thought it was a good idea to allow IP addresses to be entered in so many different formats? Who are you to decide that 0x01 is not a domain name? This is a feature which is hardly ever going to be used legitimately, but the code must be written and tested. KISS. Keep it simple, stupid.

  3. Re:Oh come on by BitZtream · · Score: 2, Insightful

    You do realize this is a timothy post ... right?

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
  4. Re:Simple defense: by DavidRawling · · Score: 3, Insightful

    Unfortunately you now cannot configure your ADSL modem until you install and configure local DNS and add the modem to the zone. Hardly something most grandmothers can do.

  5. Re:Technical details here by SEWilco · · Score: 3, Insightful

    I learned about this back in 2002 in my Network security class

    Those who do not learn history are doomed to repeat it. And issue patches.

  6. This is totally going over your head. by Estanislao+Mart�nez · · Score: 3, Insightful

    No matter how you try to obfuscate the destination - a base-10 "number", octal, binary, who effing cares how - it still goes out on the wire as an IP packet with a destination address field, either sourced from your desktop or your proxy. Packets don't lie.

    Not all IP address filtering is done by IP firewalls. These days there are many applications, most notably web browsers, that consult online databases of known or suspected malicious hosts in order to protect users from malicious hosts. I know for a fact that Firefox and Safari do this--if you try to go to a known suspected malware site, the browser pops up a warning page instead of the page you asked for. Google also do it for their search results--suspected malware site results don't link to the site in question, they link to a warning page. Many websites also have anti-XSS submission filters that perform textual matching against known "bad" addresses, to protect their users from attacks.

    Apparently, many such programs are not parsing the textual IP addresses into a canonical form, and are therefore vulnerable to this sort of obfuscation. So the typical result here is that a comment submission system will fail to block a comment that has some XSS in it, and the users' browsers, running on a network whose firewally doesn't filter the IP address in question, will then fetch a malicious script from a known malware site.