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.
https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2019-0009
Capital One: What’s in Your Data
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.
Cabarrus County, NC
It seemed simple enough. The general contractor for the county’s new school building needed to update bank account information. The appropriate forms were signed and filed, and the information was updated. Nothing seemed amiss unto two months later, when the contractor notified the county that they had missed a scheduled payment of 2.5 million dollars. But the transaction went through, and the money was transferred to the account on file.
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!
And the most useless security news of the week? The CAN bus on airplanes is exploitable when an attacker has unsupervised physical access. Yes, people with unsupervised physical access can do bad things to airplanes. Think about what they could do if they brought a wrench.
Maybe DMARC would help?
https://www.zdnet.com/article/dmarcs-abysmal-adoption-explains-why-email-spoofing-is-still-a-thing/
Surprised you didn’t mention the libreLogo vulnerability in LibreOffice on this article. Anyone know how to get rid of librelogo when you’re using a flatpak version of libreoffice on an ubuntu PC? All the librelogo removal instructions are foolishly aimed at windows, who on earth uses libreoffice but hasn’t ditched windows for linux? I’ve tried apt-get remove but that tells me that libreoffice-librelogo isn’t present, when by looking in libreoffice at it’s python macros list I can plainly see librelogo is there but has no option to delete or otherwise disable.
I didn’t come across this one when writing, I’ll go take a look, and maybe we’ll mention it next week.
Manually search for the file and move/rename it ?
Some technical stuff about the Capital One incident here: https://start.jcolemorrison.com/the-technical-side-of-the-capital-one-aws-security-breach/
(author is writing for an audience familiar with AWS stuff, so it might be a bit opaque for others)
git is not an application of blockchains in any meaningful way. It’s a merkle DAG with the coordination deferred to humans instead of whatever scheme the blockchains people are up to this week. The fact that bitcoin came along several years later to also use a merkle structure is neither here nor there; or if it is, then the inspiration clearly came the other way around.
I was particularly struck by the nonsense of this quote from the linked article: “I am reminded of this every time I see a commit hash [on Git]: bdd5fd74686bdee484227eb42d21190618a59ce4. That looks very similar to a blockchain address! I know that it is just common SHA encryption, but always feels like an eery coincidence to me.”
This is amazing. A hex string and a base58 string don’t even look alike, for starters. Secondly, both kinds of string are just encodings for arbitrary binary data. Who on earth would think this an “eerie coincidence”?
Of course, if you want absolute hard proof that Linus didn’t write the bitcoin client, you need look no further than noting that it was written in C++. :-D
=D
I also have trouble believing that Linus could could write bitcoin and not have said anything about it yet.
Why is the “Cabbarus County” thing in there? Those towns hire car salesmen and nepotists as engineers and tech people of course they have primitive security issues..
> Think about what they could do if they brought a wrench.
It is tricky to break say the plumbing to the motor in such a way that it will cause maximum havock. Either the motor breaks down while taxing to takeoff and everybody returns to the gate with a broken motor, or the motor breaks down while high so they gently float down a few thousand feet (on one motor you can’t fly as high as on two) and then they calmly divert to the closest suitable airport. (remember that Southwest incident? There they had a complication: depressurisation because parts of the motor flew through the cabin. Still: plane landed safely.)
With access to the control bus, you can start inserting “interesting stuff” at critical moments in the flight. Say turn off both motors 10 seconds prior to landing and for sure you’ll crash before the runway. (a plane can glide down just fine, but just prior to landing it is below the line that it can follow “engines out”, so it needs the engines to stay on the normal approach path. )
You know what would be awesome? If there was an eCAN bus interface for simulation software. Imagine being able to mount a dash from a car in your driving rig and the gauges just work, or creating a cockpit for a Ka-50 attack helicopter for DCS that only requires a single USB 3.0 connection that not only interfaces with the controls, but DCS recognizes the USB2HDMI interface sitting on the bus and pushes a video feed to it.