• Screenshot Social Media, Don't embed

    Ever since the web was born, there have been concerns about preserving what's published on there for future generations. That's why things like the Wayback machine exist. Things like our approach, and concerns, around online privacy have also evolved with time.

    But, the way we communicate on the web has changed pretty dramatically. Personal blogs are still a thing, but humanity has increasingly leaned towards communicating via social media - Twitter, Facebook etc. 

    Now, we increasingly see news reports with embedded posts containing expert commentary about the topic of the news, and even reports about something someone has posted.

    Those expert commentators are even occasionally being asked to change the way they tweet to make it easier for news sites to embed those tweets into their own stories (that request turned out to be from Sky News btw).

    For all their many, many faults, the social media networks are a big part of how we communicate now, and posts on them are embedded all over the place.

    This brings with it a number of avoidable, but major issues.

    The aim of this post is to discuss those, and explain why you should instead be posting a screenshot of the tweet/post.

    I'm going to refer to "Twitter" and "Tweets" a lot, purely because it's shorter than "Facebook" or "Social Media", but the concerns here apply across the board.

  • 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.