• Schema.org - Something's afoot..

    There's speculation that Schema.org may have been compromised in some manner. A number of people (including myself) have noticed some very spammy links showing up in Webmaster tools as Itemtypes under Structured Data.

    Rather than displaying (for example) http://schema.org/SiteNavigationElement, there's an itemtype pointing to various URLs on domains including www.yalwa.com, locanto.fr and askalo.fr. The only thing any of the sites have in common is their use of Schema.org.

    Curiously, you can also reproduce the issue using the Structured Data Testing Tool and entering a small HTML snippet. The issue only seems to be affecting those in Europe though, with US users only able to reproduce by using an EU based proxy.

  • Spamhaus still parties like it's 1999

    I recently had visibility of a Spamhaus Block List (SBL) listing notification on the basis of malware being detected within a file delivered via HTTP/HTTPS.

    As part of the report, they provide the affected URL (for the sake of this post we'll say it's https://foo.example.com/app.exe) along with details of the investigation they've done.

    Ultimately that investigation is done in order to boil back to a set of IPs to add to their list.

    Concerningly, this is, literally just 

    dig +short foo.example.com

    Which gives them output of the form

    CNAME1
    CNAME2
    1.2.3.4
    4.5.6.7

    They then run a reverse lookup (using nslookup) on those IP addresses in order to identify the ISP. The IPs are added to the SBL, and a notification sent to the associated ISP.

    In this case, the URL was a legitimate file, though it had been bundled with some software falling under the Possibly Unwanted Application (PUA) category. The point of this post, though, is not to argue about whether it should have been considered worthy of addition.

    The issue is that Spamhaus' investigation techniques seem to be stuck in the last century, causing potentially massive collateral damage whilst failing to actually protect against the very file that triggered the listing in the first place.

    In case you're wondering why Spamhaus are looking for malware delivery over HTTP/HTTPS, it's because the SBL has URI blocking functionality - when a spam filter (like SpamAssasin) detects a URL in a mail, it can check whether the hosting domain resolves back to an IP in the SBL, and mark as spam if it does (in effect limiting the ability to spread malware via links in email - undoubtedly a nice idea).

     

    Just to note, although they make it difficult to identify how to contact them about this kind of thing, I have attempted to contact Spamhaus about this (also tried via Twitter too).

    It also seems only fair (to Spamhaus) to note that I also saw a Netcraft incident related to the same file, and they don't even provide the investigative steps they followed. So not only might Netcraft be falling for the same traps, but there's a lack of transparency preventing issue from being found and highlighted.