A massive ransomware attack is currently under way. It was first widely reported having crippled the UK hospital system, but has since spread to numerous other systems throughout the world including FedEx in the US, the Russian Interior Ministry, and telecommunications firms in Spain and Russia.
The virus is known by names WannaCrypt, WannaCry, and a few other variants. It spreads using the ExternalBlue exploit in unpatched Windows machines older than version 10. The tools used to pull off this attack were likely from an NSA toolset leaked by the Shadow Brokers.
NHS services across England and Scotland have been hit by the ransomware attack, crippling multiple hospitals and doctor’s practices. The UK has universal healthcare — the National Health Service — covering Doctors, Hospitals and generally everything medical related is free at the point of service. but today they have had to turn away patients and cancel consultations.
NHS is unable to access medical records of patients unless they pay £230 ($300) in bitcoin for infected machines. There is no evidence patient data has been compromised, NHS Digital has said. The BBC has stated that up to 39 NHS organisations and some GP practices have been affected.
The National Cyber Security Centre (NCSC) was “working closely” with the NHS and that they will protect patient safety. We are aware that a number of NHS organisations have reported that they have suffered from a ransomware attack.
-Prime Minister Theresa May
Infected Systems Throughout the World
Computers in regions across the globe have been under attack today, including Telefonica (O2 in the UK), with at least 45,000 computers compromised in Russia, Ukraine, India, and Taiwan alone. There’s no indication of who is behind the attack yet.
The ransomware’s code takes advantage of an exploit called EternalBlue, made public in April by Shadow Brokers which was patched by Microsoft in March, It comes as a shock that an organisation the size of the NHS seem not to have kept their computers updated. This is perhaps just a taster of what is to come in the future as cyber crime and warfare become more and more commonplace.
Keyloggers are nasty little things that have the potential to steal the credit card numbers of you and everyone you care about. Usernames and passwords can be easily stolen this way, so they’re a useful tool for the black hats out there. One would generally expect to find a keylogger in a dodgy movie torrent or perhaps a keygen for pirated software, but this week a keylogger was found in an audio driver for an HP laptop.
The logger was found by Swiss security researchers modzero. The Conexant HD Audio Driver Package version 1.0.0.46 and earlier apparently logs keystrokes in order to monitor things like the laptop’s volume up and down keys. The real killer here is that it feels the need to log all keystrokes detected to a readily accessible file, for reasons we can’t possibly fathom. It’s a huge security risk, but it doesn’t stop there – the driver also exposes the keystrokes through an API as well, creating an even wider attack surface for malicious actors. One can in principle access the keystroke log remotely.
There’s no word from the company yet, but we really want to know – why save the keystrokes to a file at all? Code left over from debugging, perhaps? Speculate in the comments.
We’ve always been a fans of wargames. Not the movie (well, also the movie) but I’m referring to hacking wargames. There are several formats but usually you have access to an initial shell account somewhere, which is level0, and you have to exploit some flaw in the system to manage to get level1 permissions and so forth. Almost always there’s a level where you have to exploit a legitimate binary (with some shady permissions) that does more than what the regular user thinks.
[Timo Schmid] details how the git-shell, a restricted shell meant to be used as the upstream peer in a git remote session over a ssh tunnel, can be abused in order to achieve arbitrary file read, directory listing and somewhat restricted file write. The git-shell basic idea is to restrict the allowed commands in an ssh session to the ones required by git (git-receive-pack, git-upload-pack, git-upload-archive). The researcher realized he could pass parameters to these commands, like the flag –help:
$ ssh git@remoteserver "git-receive-pack '--help'"
GIT-RECEIVE-PACK(1) Git Manual GIT-RECEIVE-PACK(1)
NAME
git-receive-pack - Receive what is pushed into the repository
[...]
What the flag does is make the git command open the man page of git, which is passed on to a pager program, usually less. And this is where it get interesting. The less command, if running interactively, can do several things you would expect like searching for text, go to a line number, scroll down and so on. What it can also do is open a new file (:e), save the input to a file (s) and execute commands (!). To make it run interactively, you have to force the allocation of a PTY in ssh like so:
$ ssh -t git@remoteserver "git-receive-pack '--help'"
GIT-RECEIVE-PACK(1) Git Manual GIT-RECEIVE-PACK(1)
NAME
git-receive-pack - Receive what is pushed into the repository
Manual page git-receive-pack(1) line 1 (press h for help or q to quit)
Press h for help and have fun. One caveat is that usual installations the code execution will not really execute arbitrary commands, since the current running login shell is the git-shell, restricted to only some white listed commands. There are, however, certain configurations where this might happen, such as maintaining bash or sh as a login shell and limit the user in ways that they can only use git (such as in shared environments without root access). You can see such example here.
The quickest solution seems to be to enable the no-pty flag server-side, in the sshd configuration. This prevents clients from requesting a PTY so less won’t run in an interactive mode.
$ man less
LESS(1) General Commands Manual LESS(1)
NAME
less - opposite of more
If you have more than a few bank cards, door-entry keycodes, or other small numeric passwords to remember, it eventually gets to be a hassle. The worst, for me, is a bank card for a business account that I use once in a blue moon. I probably used it eight times in five years, and then they gave me a new card with a new PIN. Sigh.
Quick, What’s My PIN?
How would a normal person cope with a proliferation of PINs? They’d write down the numbers on a piece of paper and keep it in their wallet. We all know how that ends, right? A lost wallet and multiple empty bank accounts. How would a hacker handle it? Write each number down on the card itself, but encrypted, naturally, with the only unbreakable encryption scheme there is out there: the one-time pad (OTP).
The OTP is an odd duck among encryption methods. They’re meant to be decrypted in your head, but as long as the secret key remains safe, they’re rock solid. If you’ve ever tried to code up the s-boxes and all that adding, shifting, and mixing that goes on with a normal encryption method, OTPs are refreshingly simple. The tradeoff is a “long” key, but an OTP is absolutely perfect for encrypting your PINs.
The first part of this article appears to be the friendly “life-hack” pablum that you’ll get elsewhere, but don’t despair, it’s also a back-door introduction to the OTP. The second half dives into the one-time pad with some deep crypto intuition, some friendly math, and hopefully a convincing argument that writing down your encrypted PINs is the right thing to do. Along the way, I list the three things you can do wrong when implementing an OTP. (And none of them will shock you!) But in the end, my PIN encryption solution will break one of the three, and remain nonetheless sound. Curious yet? Read on.
Here’s a puzzler for you: how do you securely send data from one airgapped computer to another? Sending it over a network is right out, because that’s the entire point of an airgap. A sneakernet is inherently insecure, and you shouldn’t overestimate the security of a station wagon filled with tapes. For his Hackaday Prize entry, [Nick Sayer] has a possible solution. It’s the Sankara Stones from Indiana Jones and the Temple of Doom, or a USB card reader that requires two cards. Either way, it’s an interesting experiment in physical security for data.
The idea behind the Orthrus, a secure RAID USB storage device for two SD cards, is to pair two SD cards. With both cards, you can read and write to this RAID drive without restriction. With only one, the data is irretrievable so they are safe during transit if shipped separately.
The design for this device is based around the ATXMega32A4U. It’s pretty much what you would expect from an ATMega, but this has a built-in full speed USB interface and hardware AES support. The USB is great for presenting two SD cards as a single drive, and the AES port is used to encrypt the data with a key that is stored in a key storage block on each card.
For the intended use case, it’s a good design. You can only get the data off of these SD cards if you have both of them. However, [Nick] is well aware of Schneier’s Law — anyone can design a cryptosystem that they themselves can’t break. That’s why he’s looking for volunteers to crack the Orthrus. It’s an interesting challenge, and one we’d love to see broken.
Everything is online these days creating the perfect storm for cyber shenanigans. Sadly, even industrial robotic equipment is easily compromised because of our ever increasingly connected world. A new report by Trend Micro shows a set of attacks on robot arms and other industrial automation hardware.
This may not seem like a big deal but image a scenario where an attacker intentionally builds invisible defects into thousands of cars without the manufacturer even knowing. Just about everything in a car these days is built using robotic arms. The Chassis could be built too weak, the engine could be built with weaknesses that will fail far before the expected lifespan. Even your brake disks could have manufacturing defects introduced by a computer hacker causing them to shatter under heavy braking. The Forward-looking Threat Research (FTR) team decided to check the feasibility of such attacks and what they found was shocking. Tests were performed in a laboratory with a real in work robot. They managed to come up with five different attack methods.
Attack 1: Altering the Controller’s Parameters
The attacker alters the control system so the robot moves unexpectedly or inaccurately, at the attacker’s will.
Attack 2: Tampering with Calibration Parameters
The attacker changes the calibration to make the robot move unexpectedly or inaccurately, at the attacker’s will.
Why are these robots even connected? As automated factories become more complex it becomes a much larger task to maintain all of the systems. The industry is moving toward more connectivity to monitor the performance of all machines on the factory floor, tracking their service lifetime and alerting when preventive maintenance is necessary. This sounds great for its intended use, but as with all connected devices there are vulnerabilities introduced because of this connectivity. This becomes especially concerning when you consider the reality that often equipment that goes into service simply doesn’t get crucial security updates for any number of reasons (ignorance, constant use, etc.).
For the rest of the attack vectors and more detailed info you should refer to the report (PDF) which is quite an interesting read. The video below also shows insight into how these type of attacks might affect the manufacturing process.
Betteridge’s Law of Headlines states, “Any headline that ends in a question mark can be answered by the word no.” This law remains unassailable. However, recent claims have called into question a black box hidden deep inside every Intel chipset produced in the last decade.
Yesterday, on the Semiaccurate blog, [Charlie Demerjian] announced a remote exploit for the Intel Management Engine (ME). This exploit covers every Intel platform with Active Management Technology (AMT) shipped since 2008. This is a small percentage of all systems running Intel chipsets, and even then the remote exploit will only work if AMT is enabled. [Demerjian] also announced the existence of a local exploit.
Intel’s ME and AMT Explained
Beginning in 2005, Intel began including Active Management Technology in Ethernet controllers. This system is effectively a firewall and a tool used for provisioning laptops and desktops in a corporate environment. In 2008, a new coprocessor — the Management Engine — was added. This management engine is a processor connected to every peripheral in a system. The ME has complete access to all of a computer’s memory, network connections, and every peripheral connected to a computer. The ME runs when the computer is hibernating and can intercept TCP/IP traffic. Management Engine can be used to boot a computer over a network, install a new OS, and can disable a PC if it fails to check into a server at some predetermined interval. From a security standpoint, if you own the Management Engine, you own the computer and all data contained within.
The Management Engine and Active Management Technolgy has become a focus of security researchers. The researcher who finds an exploit allowing an attacker access to the ME will become the greatest researcher of the decade. When this exploit is discovered, a billion dollars in Intel stock will evaporate. Fortunately, or unfortunately, depending on how you look at it, the Managment Engine is a closely guarded secret, it’s based on a strange architecture, and the on-chip ROM for the ME is a black box. Nothing short of corporate espionage or looking at the pattern of bits in the silicon will tell you anything. Intel’s Management Engine and Active Management Technolgy is secure through obscurity, yes, but so far it’s been secure for a decade while being a target for the best researchers on the planet.
Semiaccurate’s Claim
In yesterday’s blog post, [Demerjian] reported the existence of two exploits. The first is a remotely exploitable security hole in the ME firmware. This exploit affects every Intel chipset made in the last ten years with Active Management Technology on board and enabled. It is important to note this remote exploit only affects a small percentage of total systems.
The second exploit reported by the Semiaccurate blog is a local exploit that does not require AMT to be active but does require Intel’s Local Manageability Service (LMS) to be running. This is simply another way that physical access equals root access. From the few details [Demerjian] shared, the local exploit affects a decade’s worth of Intel chipsets, but not remotely. This is simply another evil maid scenario.
Should You Worry?
This hacker is unable to exploit Intel’s ME, even though he’s using a three-hole balaclava.
The biggest network security threat today is a remote code execution exploit for Intel’s Management Engine. Every computer with an Intel chipset produced in the last decade would be vulnerable to this exploit, and RCE would give an attacker full control over every aspect of a system. If you want a metaphor, we are dinosaurs and an Intel ME exploit is an asteroid hurtling towards the Yucatán peninsula.
However, [Demerjian] gives no details of the exploit (rightly so), and Intel has released an advisory stating, “This vulnerability does not exist on Intel-based consumer PCs.” According to Intel, this exploit will only affect Intel systems that ship with AMT, and have AMT enabled. The local exploit only works if a system is running Intel’s LMS.
This exploit — no matter what it may be, as there is no proof of concept yet — only works if you’re using Intel’s Management Engine and Active Management Technology as intended. That is, if an IT guru can reinstall Windows on your laptop remotely, this exploit applies to you. If you’ve never heard of this capability, you’re probably fine.
Still, with an exploit of such magnitude, it’s wise to check for patches for your system. If your system does not have Active Management Technology, you’re fine. If your system does have AMT, but you’ve never turned it on, you’re fine. If you’re not running LMT, you’re fine. Intel’s ME can be neutralized if you’re using a sufficiently old chipset. This isn’t the end of the world, but it does give security experts panning Intel’s technology for the last few years the opportunity to say, ‘told ‘ya so’.
