• My Own Little HeartBleed Headache

    When the HeartBleed bug was unveiled, I checked all of my servers to see whether they were running vulnerable versions. They weren't, but once the patched versions were released it seemed a good juncture to test and roll out the update to one server.

    What followed was something of a headache, initially with all the markings of a serious compromise.

    Having now identified and resolved the root cause, I thought I'd write a post about it so that others seeing similar behaviour can get something of a headstart.

    In response to threats such as CDorked, I run PHP Changed Binaries on all my servers, so any file in PATH is checked (daily) for changes, based on a cryptographic checksum. If any changes are detected, an alert is raised so that I can investigate the cause of the change.

    The day after I updated OpenSSL, I started receiving alerts for a wide variety of files (I'd updated hashes following the update of OpenSSL)

  • PHP Changed Binaries

    PHPChangedBinaries is a simple server monitoring script. It's designed and exists to do one thing - detect and notify when system files change. 

    I've been running a very similar script for years, but in the wake of CDorked/DarkLeech decided it needed a refresh. The script works by generating checksums for all files within pre-configured paths (you can add more through the configuration file). These are then checked against a stored hash to see if anything has changed - if it has, the system admin is alerted. 

  • RemoteHashStore Documentation

    RemoteHashStore is an API designed for use by the PHP Changed Binaries monitoring script. It's function is to simply maintain a database of file hashes and compare those hashes against those submitted when checking files. This documentation relates to the client included in the PHP Changed Binaries system. See the relevant documentation if you're attempting to build a client for the RemoteHashStore API (Coming Soon!).

  • Republished: Basic Malware Detector For Linux

    This was originally published on benscomputer.no-ip.org in Jun 2009

    OK, if this of use to anyone then fantastic!!!!

    It's a simple script that will generate MD5/SHA1/SHA256 sums of all files within your PATH. This is based on the PATH variable on my machine at time of writing, in fact it also checks the sums of my backups (you'll probably want to remove the /mnt/exthd line).

  • Republished: Hacking the Computrend Powergrid 902 Powerline Adaptor

    This was originally published on Benscomputer.no-ip.org in 2009

    I've been having a bit more of a play about with the adaptors, wondering what other weaknesses lay within. So far I haven't found a vast amount, but I have found a potential DoS attack that could be used by a local attacker.

  • Republished: How Safe are Webcam Sites?

    This content was originally published to benscomputer.no-ip.org in December 2008

    There are a variety of websites available online which allow users to stream live footage of themselves, either to a specific person or indiscriminantly. The dangers of using these sites depends largely on the user.

    There is a danger of users attracting unwanted attention, or of finding their webcam session more widely distributed than they expected. Users should be aware of this risk before accessing one of these sites, but it is expected that most would be mature enough to accept this risk.

    One of the benefits of using an online meeting place, is that should a user be plagued by unwated attention they can easily report the issue to a moderator or simply stop using the site. However, this is reliant on users not disclosing personal details to people they do not know. There is very little benefit in leaving a site if you have given the person your home address.

  • Republished: It's a Dangerous World

    This was originally posted to benscomputer.no-ip.org back in 2009


    It's a dangerous world out there, there's more than a few scams running at the moment. Whether you are trying to crack someones facebook account, or simply have a landline, there's people after your money.

    Take the current phone line scam, Some guy phones you up and tells you that;

    you owe the phone provider money, and you're going to be cut off if you don't pay.

  • Republished: Tips for fighting password theft

    Originally published on Benscomputer.no-ip.org Jan 2010.

     

    Password theft is a fast growing business, in the age of the internet a singular word or phrase is often all you need to verify your identity. Unfortunately this token is all that is needed for someone else to adopt your identity, and potentially commit fraud or criminal acts in your name.

    Everything seems to be online in this day and age, whether it's your bank, your mail or your shopping. Each of these require a unique login to identify you. Unfortunately usernames can be quite easy to come by, in fact on many sites your username is public (Ebay is a good example of this).

    So how do you protect yourself from this threat? Generally it simply requires a little bit of common sense. You wouldn't provide just anyone with a copy of the key to your house, so why do the same for your online persona?

     

  • Republished: UK government wants to put our networks at risk

    This was originally published to benscomputer.no-ip.org in May 2006

    Once again we are seeing another stupid law from our government. The story can be found on ZDNet as well as on Slashdot.

  • Republished: Why you should never share Login Details

    Originally published on Benscomputer.no-ip.org Aug 2009.

     

    Anyone who works in IT in any form knows the headache, despite signing to say they wont, users insist on sharing their login details with everyone! Whether it's because someone else can't remember their own username or simply because it's easier than logging out.

    On occassion it happens because the user didn't lock their desktop before walking away, and someone else happens to need to use a PC 'quickly.'

    We all know it, users just don't care about security. Why should they? It's 'Your' network to look after, not theirs. This article is aimed at that particular group to try and highlight exactly why they should care.

     

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

  • Security Flaw in the Computrend Powergrid 902 Adaptor

    This article was originally published at Benscomputer.no-ip.org in 2009

    OK, so I was playing around testing NetManage when I discovered something of a security flaw in the ComTrend Powerline 902 Adaptors I use when I want to use a laptop somewhere that I haven't got a Wired Connection.

  • Simple Reverse Shell

  • An example of using nc and /dev/tcp in order to establish a reverse shell

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

  • The Curious Case of BitFi and Secret Persistence

    For some slightly obscure reasons I've recently found myself looking at the Bitfi hardware wallet and some of the claims the company make, particularly in relation to whether or not it's actually possible to extract secrets from the device.

    The way the device is supposed to work is that, in order to (say) sign a transaction, you use an onscreen keyboard to enter a salt, and a >30 char passphrase.

    The device then derives a private key from those two inputs, uses it and then flushes the key, salt and passphrase out.

    Each time you want to use the device, you need to re-enter salt and passphrase - the idea being that if it never stores any of your secrets, then there's nothing to extract from a seized/stolen device. 

    From Bitfi's site we can see this wrapped up in marketing syntax:


    The Bitfi does not store your private keys. Ever. Your digital assets are stored on the Blockchains, when you want to make a transaction with your assets (move them, sell them, etc.) you simply enter your 6-character (minimum) SALT and your 30-character (minimum) PASSPHRASE into your Bitfi Legacy device which will then calculate your private key for any given token “on-demand” and then immediately expunge that private key.

    For various reasons (see Background) I was somewhat dubious about the veracity of this claim, and ultimately ended up looking over their source code in order to try and verify it.

    This post details the results of that examination, the following items should be noted

    • Although not explicitly vulnerabilities, the issues noted below have been submitted in advance to the Bitfi dev team (I did ask previously via email whether email or Bitfi.dev was preferable for raising issues).
    • Incomplete sources are published on Bitfi.dev - example here, so although I include code snippets in this post, it's updated versions of code that's already public - I'm not simply publishing their code on the net :)
    • I probably will make some mistakes: I've been ill, so focusing is hard, and I dislike C# so it's more than possible something's changed without me realising.
    • This is the result of a fairly short code review, and in no circumstances should be viewed or characterised as a full audit
    • In the sources, code version shows as v112

    The result is a long analysis, so some may prefer to jump to the Conclusion.  

  • The DVLA is routinely sending sensitive details via email

    It's that time of year - time to renew car tax. I figured I'd give the monthly direct debit a go and see whether paying the extra little bit is worth avoiding the yearly pain of remembering you need to find a few hundred quid up front.

    For anyone who's not used it yet, the process of setting up is smooth and easy (in an almost distinctly non-government IT way), unfortunately it turns out there's a fairly big issue with the final step.

    I should be fair, and point out that the service is provided by DirectGov rather than the DVLA directly, but IMHO it remains the DVLA's responsibility.

  • The Importance of Changing Default Passwords

    In today’s connected world, passwords are absolutely everywhere. We are constantly asked to
    create new passwords, whether for a Facebook account, financial management systems or a new
    router.


    Whilst new accounts seldom come with a default password, many devices do ship with a generic
    username and password. Despite wide awareness of the importance of password control, many
    people still fail to change these default passwords.

     

  • The Importance of Salting Stored Passwords And How To Do So Correctly

    Many will have watched the recent releases of user passwords from Sony (and others) with interest. A lot of people, won't however, realise why Sony's practises were so poor. For many, storing passwords means just that, purely because they aren't aware of the methods available to make it a lot harder for an attacker to gain access to users passwords.

    Whilst network security obviously plays a very important part, even when that fails it should be almost impossible for an attacker to tell you what your password was based on nothing but a database dump. In this short post we'll examine exactly how passwords should be handled and stored in a database.

  • The State of Mobile Banking (in the UK)

    News recently broke that Tesco Bank's Android App refuses to run when Tor is also installed on the handset, presumably in the name of security.

    So, out of morbid curiousity, I thought I'd take a quick look at just how effectively various banking apps were secured. Banks, after all, should be at the forefront of security (even if they often aren't)

    To start with a disclaimer - personally, I think using banking services on any mobile device is a bad idea from the outset, and some of the results definitely support that idea. I've only taken a cursory look, and not made any attempt to dis-assemble any of the apps.

     

  • Twitter Screws Up With Data It Shouldn't Hold

    I recently had a (NSFW) grumble about Twitter. Part of that grumble was about the fact that Twitter insist you provide a mobile phone number in order to re-instate your account after a suspension.

    As part of my appeal against the suspension I noted that that's arguably not GDPR compliant - a phone number is (undoubtedly) PII, and is not required in order to provide the service. For Twitter to hold that number requires consent, and it's unlawful for them to withhold the service if consent is not given for non-essential data processing.

    Part of the reason for my objection was because Social Media companies (in the form of Facebook) have already proven they cannot be trusted with things like mobile phone numbers.

    Presumably Twitter weren't happy with the fact that I needed to use Facebook as an example, as they've now gone ahead and had a data processing screw up of their own.