new(?) Geocities subsite obfuscation - SpamAssassin

This is a discussion on new(?) Geocities subsite obfuscation - SpamAssassin ; ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: new(?) Geocities subsite obfuscation

  1. Re: new(?) Geocities subsite obfuscation


  2. new(?) Geocities subsite obfuscation

    Just noticed a new (to me) Geocities obfuscation technique that uses
    embedded relative path(s):
    http://geocities.com/./qryz/../crist...mores7rhqzn5ba
    That breaks my own subsite extraction code.

    The pedantic part of my brain wants to rewrite my code to
    auto-adjust for relative paths, so I can continue testing the
    subsite against Uribl's great subsite list.

    The expedient part of my brain is thinking that either a ".." or a
    "/./" in a URL are most shiny signs of spam (or major mailing list
    stupidity), so I'm going to start with those as simple rules.

    Other than borked mailing lists, can anyone recall seeing either of
    those patterns in a legitimate emailed URL?

    Stay dry,
    - "Chip"


  3. Re: new(?) Geocities subsite obfuscation

    At 08:06 16-06-2008, Chip M. wrote:
    >Just noticed a new (to me) Geocities obfuscation technique that uses
    >embedded relative path(s):
    >
    >http://geocities.com/./qryz/../crist...mores7rhqzn5ba
    >That breaks my own subsite extraction code.


    [snip]

    >Other than borked mailing lists, can anyone recall seeing either of
    >those patterns in a legitimate emailed URL?


    Yes, this one if it's a legitimate email. :-)

    Given the way URLs are parsed, if the URL is preceded by "http://",
    it's less likely to hit legitimate emails. Such paths are commonly
    seen in messages about XSS. If the score is not too high, you can be
    offset it with other rules.

    Regards,
    -sm


  4. Re: new(?) Geocities subsite obfuscation

    On Mon, 16 Jun 2008, mouss wrote:

    > Chip M. wrote:
    >> Just noticed a new (to me) Geocities obfuscation technique that uses
    >> embedded relative path(s):
    >> http://geocities.com/./qryz/../crist...mores7rhqzn5ba
    >> That breaks my own subsite extraction code.

    >
    > "/." is a unix construct, so except for filenames like ".foo", I see no
    > use for that over the web (the web is not unix). so
    > \/\.\W
    > doesn't look to be needed for legitimate URLs. same goes for equivalent
    > encodings.


    I've seen multiple leading periods in phish messages. My local rule for
    this is equivalent to \/\.{1,4}\W

    > and since such URLs are used to evade detection by proxies and access
    > control implementations, I'd say get this out (old tomcat and
    > tomcat+apache used to have a vulnerability that allowed access to tomcat
    > admin using such URLs).


    They're also used to hide fraudulent website content from the
    administrators of compromised hosts. Ideally their presence should
    generate an alert to the abuse address of the host that appears in the
    URL. Implementation of this is left as an exercise for the student.

    --
    John Hardin KA7OHZ http://www.impsec.org/~jhardin/
    jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
    key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
    -----------------------------------------------------------------------
    Where We Want You To Go Today 07/05/07: Microsoft patents in-OS
    adware architecture incorporating spyware, profiling, competitor
    suppression and delivery confirmation (U.S. Patent #20070157227)
    -----------------------------------------------------------------------
    2 days until SWMBO's Birthday


+ Reply to Thread