One of the pleasures of consuming old science fiction movies and novels is that they capture the mood of the time in which they are written. Captain Kirk was a 1960s guy and Picard was a 1990s guy, after all. Cold war science fiction often dealt with invasion. In the 1960s and 70s, you were afraid of losing your job to a computer, so science fiction often had morality tales of robots running amok, reminding us what a bad idea it was to give robots too much power. As it turns out, robots might be dangerous, but not for the reasons we thought. The robots won’t turn on us by themselves. But they could be hacked. To that end, there’s a growing interest in robot cybersecurity and Alias Robotics is releasing Alurity, a toolbox for robot cybersecurity.
Currently, the toolbox is available for Linux and MacOS with some support for Windows. It targets 25 base robots including the usual suspects. There’s a white paper from when the product entered testing available if you want more technical details.
In case you hadn’t noticed, it was a bad week for system admins. Pennsylvania-based United Health Services, a company that owns and operates hospitals across the US and UK, was hit by a ransomware attack early in the week. The attack, which appears to be the Ryuk ransomware, shut down systems used by hospitals and health care providers to schedule patient visits, report lab results, and do the important job of charting. It’s not clear how much the ransomers want, but given that UHS is a Fortune 500 company, it’s likely a tidy sum.
And as if an entire hospital corporation’s IT infrastructure being taken down isn’t bad enough, how about the multi-state 911 outage that occurred around the same time? Most news reports seemed to blame the outage on an Office 365 outage happening at the same time, but Krebs on Security dug a little deeper and traced the issue back to two companies that provide 911 call routing services. Each of the companies is blaming the other, so nobody is talking about the root cause of the issue. There’s no indication that it was malware or ransomware, though, and the outage was mercifully brief. But it just goes to show how vulnerable our systems have become.
Our final “really bad day at work” story comes from Japan, where a single piece of failed hardware shut down a $6-trillion stock market. The Tokyo Stock Exchange, third-largest bourse in the world, had to be completely shut down early in the trading day Thursday when a shared disk array failed. The device was supposed to automatically failover to a backup unit, but apparently the handoff process failed. This led to cascading failures and blank terminals on the desks of thousands of traders. Exchange officials made the call to shut everything down for the day and bring everything back up carefully. We imagine there are some systems people sweating it out this weekend to figure out what went wrong and how to keep it from happening again.
With our systems apparently becoming increasingly brittle, it might be a good time to take a look at what goes into space-rated operating systems. Ars Technica has a fascinating overview of the real-time OSes used for space probes, where failure is not an option and a few milliseconds error can destroy billions of dollars of hardware. The article focuses on the RTOS VxWorks and goes into detail on the mysterious rebooting error that affected the Mars Pathfinder mission in 1997. Space travel isn’t the same as running a hospital or stock exchange, of course, but there are probably lessons to be learned here.
As if 2020 hasn’t dealt enough previews of various apocalyptic scenarios, here’s what surely must be a sign that the end is nigh: AI-generated PowerPoint slides. For anyone who has ever had to sit through an endless slide deck and wondered who the hell came up with such drivel, the answer may soon be: no one. DeckRobot, a startup company, is building an AI-powered extension to Microsoft Office to automate the production of “company compliant and visually appealing” slide decks. The extension will apparently be trained using “thousands and thousands of real PowerPoint slides”. So, great — AI no longer has to have the keys to the nukes to do us in. It’ll just bore us all to death.
And finally, if you need a bit of a palate-cleanser after all that, please do check out robotic curling. Yes, the sport that everyone loves to make fun of is actually way more complicated than it seems, and getting a robot to launch the stones on the icy playing field is a really complex and interesting problem. The robot — dubbed “Curly”, of course — looks like a souped-up Roomba. After sizing up the playing field with a camera on an extendable boom, it pushes the stone while giving it a gentle spin to ease it into exactly the right spot. Sadly, the wickedly energetic work of the sweepers and their trajectory-altering brooms has not yet been automated, but it’s still pretty cool to watch. But fair warning: you might soon find yourself with a curling habit to support.
This has been an interesting week. First off, security researchers at Armis discovered a set of serious vulnerabilities in the vxWorks Real Time Operating System (RTOS). Released under a name that sounds like the title of a western or caper movie, Urgent/11. Not familiar with vxWorks? It’s a toss-up as to whether vxWorks or Linux is more popular for embedded devices. Several printer brands, Arris modems, Sonicwall firewalls, and a whole host of other industrial and medical devices run the vxWorks RTOS.
Several of these vulnerabilities are in the network stack, rather than in applications. The worst offender is CVE-2019-12256, a vulnerability in error handling. An ICMP error response is generated from an incoming packet, and assumptions are made about that incoming packet. When data is copied from that packet into the ICMP error, the length is not first checked, allowing unconfined memory write. If this sounds familiar, it should. We covered a similar vulnerability in Apple’s XNU kernel not long ago.
This particular vulnerability can compromise a vxWorks machine even without an opened port. The saving grace of that vulnerability applies here: a maliciously crafted packet is necessarily malformed, and won’t navigate public routing. In other words, it’s LAN only, and can’t be sent over the internet.
A second class of vulnerability, where the name comes from, is related to the TCP urgent pointer. This rarely used TCP feature was intended to allow more up-to-date information to supersede data still being processed. Not only has TCP urgent not been widely used, the specifications were not written particularly well, with the various RFC documents describing conflicting implementations. It’s surprising that vxWorks supports it at all, but isn’t particularly surprising that their implementation is flawed. Manipulation of the data stream can cause a length integer to underflow. The nature of binary arithmetic means that underflowing an unsigned integer causes it to wrap around to maximum value, which can lead to writing packet data in the buffer in unexpected memory locations. These vulnerabilities require an established TCP connection, but the researchers describe several scenarios where that could be accomplished by an attacker.
The last RCE vulnerability they describe is in the DHCP client, ipdhcpc. This is a very simple vulnerability. One section of code allocates a buffer for DHCP options, but allocates 24 bytes fewer than the maximum size. An attacker could use this 24 byte overflow to manipulate the data structure and potentially jump execution into manipulated memory.
Update (2019-08-02 09:15 UTC-7): Hackaday received a statement from SonicWall that they made a patch for this vulnerability back on July 19th:
Ensuring the security of our customers is a responsibility we take seriously at SonicWall and we work vigilantly to always keep our customers secure. SonicWall physical firewall appliances running certain versions of SonicOS contain vulnerabilities in code utilized for remote management. At this time, there is no indication that the discovered vulnerabilities are being exploited in the wild. The patches are available now and we strongly advised our partners and end users July 19 th to apply the SonicOS patch immediately.
Capital One made use of Amazon AWS for storing customer data. This isn’t surprising, many companies have turned to Amazon’s seemingly inexhaustible cloud computing platform for storing large data sets. It seems, however, that Capital One failed to configure the security properly on that bucket. (As many other companies have done.) Information was leaked for over an estimated 100 million customers. A former Amazon employee has been arrested, and seems to have posted at least a portion of that data in a Github gist.
Reading between the lines, it seems that this was a very simple mistake. Perhaps credentials were leaked, or the S3 bucket was publicly available. That particular detail has not been released. There is something to be said for Capital One’s response to the incident. They were anonymously informed of the existence of the gist on July 17, using their responsible disclosure process. By the 29th, they had fixed the misconfiguration, coordinated with law enforcement, and publicly announced the breach. A twelve day turn-around is an impressive response, particularly when so many companies have tried to hide or ignore similar breaches.
Yes, the transfer went through, but the the county had been hit with a social engineering scam. The report refers to it as an Email Account Compromise (EAC) scam, which seems to indicate that the scammer first gained access to a legitimate email account of the contractor in question. Alternatively, an attacker could simply spoof the sender’s email address, and set a different reply-to field. Unless a user was particularly watching for such a scheme, it would be easy to overlook the discrepancy. In any case, even after recovering some of the transferred money, the county seems to be out about $1.7 million. These scams are becoming more and more popular, so remember, don’t believe anything you read in an email.
The Weird and Wacky
And to round out this week’s news, yet another [Satoshi Nakamoto] candidate has been found: Linus Torvalds. While it appears to be a serious suggestion, I’ll just note that the author doesn’t have his name attached to this article. He does make one interesting observation — git is the killer blockchain app. You see, I tend to compare blockchain to the laser. Both were very clever inventions, but didn’t have any immediate uses. They were solutions in search of a problem. This article points out that core concepts of blockchain are present in git, which seems to be an accurate and clever observation. So what is blockchain good for? Git!
The Linksys router seen about is a WRT54G version 1. It famously runs Linux and was the source of much hacking back in the heyday, leading to popular alternative firmware packages such as DD-WRT and Tomato. But the company went away from a Linux-based firmware starting with version 8 of the hardware. Now they are using a proprietary Real Time Operating System called VxWorks.
[Craig] recently put together a reverse engineering guide for WRT54Gv8 and newer routers. His approach is purely firmware based since he doesn’t actually own a router that runs VxWorks. A bit of poking around in the hex dump lets him identify different parts of the files, leading to an ELF header that really starts to unlock the secrets within. From there he carries out a rather lengthy process of accurately disassembling the code into something that makes sense. The tool of choice used for this is IDA Pro diassembler and debugger. We weren’t previously familiar with it, but having seen what it can do we’re quite impressed.