Twilio, the cloud provider for all things telecom, had an embarrassing security fail a couple weeks ago. The problem was the Amazon S3 bucket that Twilio was using to host part of their public facing content. The bucket was configured for public read-write access. Anyone could use the Amazon S3 API to make changes to the files stored there.
The files in question were protected behind Cloudflare’s CDN, but there’s a catch to Cloudflare’s service. If you know the details of the service behind Cloudflare, it can often be interacted with directly. In many cases, knowing the IP address of the server being protected is enough to totally bypass Cloudflare altogether. In this case, the service behind the CDN is Amazon’s S3. Any changes made to the files there are picked up by the CDN.
Someone discovered the insecure bucket, and modified a Javascript file that is distributed as part of the Twilio JS SDK. That modification was initially described as “non-malicious”, but in the official incident report, Twilio states that the injected code is part of an ongoing magecart campaign carried out against misconfigured S3 buckets.
IPTV
We received a story on the Hackaday tip line this week about a Swedish IPTV service, Pongo IPTV. This report is unsubstantiated, but there seems to be something going on. At the very least, pongotv.com is currently returning a Cloudflare error, “This website is using a security service to protect itself from online attacks.”
A pair of Youtube videos seem to show access to the Pongotv backend, with exposed customer records and all. At this point, I have to stress that this is unconfirmed report. Based on the details provided, it sounds like the tipster is actually pretty closely involved with this story, maybe even part of the group that is behind the attack.
Espressif
[Lukas Bachschwell] discovered a flaw in the Espressif SDK, tracked as CVE-2020-12638. The vulnerability affects devices running firmware built using the vulnerable SDK. In short, it allows a WiFi authentication downgrade attack. An attacker can inject WiFi traffic, and cause the device to connect to a network under the attacker’s control. For devices used for home automation and other similar applications, this could have serious consequences. Patches are available for most of the devices the SDK covers, and the rest are in progress.
D-Link Patches EOL Device
In response to a series of flaws discovered by researchers at Loginsoft, D-Link has released firmware for an End Of Life device, and strongly recommends taking other affected devices out of use. The devices in question are the DAP-1520, DAP-1522, and DIR-816L.
These aren’t sophisticated vulnerabilities, either. The first one, CVE-2020-15892, can be triggered as simply as sending 256 characters as the password when trying to log in. The login page limits this value to 15 characters, but that limit is imposed on the client side, so an attacker can easily manipulate the raw response to bypass that restriction. The longer than expected password overflows the buffer and crashes the device. A proper exploit would take it over instead.
Another rather trivial vulnerability, CVE-2020-15893, affects the DIR-816L. A shell command can be injected in a UPnP request, as simply as including a semicolon in the packet data. When the UPnP request is parsed, part of it is used as a command line option. Including a semicolon breaks out of that command, and allows executing arbitrary commands.
Sharepoint
CVE-2020-1147 is a vulnerability in Microsoft Sharepoint, found by multiple researchers independently. [Steven] at Source Insight wrote up an explainer on the bug, and concludes that at its heart it’s a deserialization issue. In this case, it seems that functions of a DataSet object, like parse() and Deserialize() can be overwritten by the data being deserialized.
The write-up includes a full PoC, so consider this vulnerability to fully weaponized already. Patches are available, so be sure to go take care of your Sharepoint servers. [Steven] also suggests that we’ll see this same bug show up in other .net applications, as the DataSet object has been considered safe for outside data.
Apple Research Device
Apple has announced the Security Research Device, a modified iPhone that is essentially rooted from the factory. The program is run in typical Apple fashion, as the device is only loaned out 12 months at a time, and comes with a list of do’s and don’ts. I have to wonder if this is a response to Google Project Zero’s debuggable iPhone work from last year. Either way, Project Zero’s [Ben Hawkes] has already issued a statement that the program is likely a non-starter for them, as their strict 90 day disclosure policy is incompatible with the sign-up agreement.
BootHole
And finally, a vulnerability in Grub2 was released this week, BootHole. This vulnerability is a rather simple buffer overflow bug that can be triggered by a malicious grub.cfg file. You might point out that if an attacker can modify grub.cfg, isn’t the system hopelessly compromised anyway? This is a fair question, and the answer is yes, usually. What makes BootHole novel is that taking control of Grub in this way can allow a Secure Boot bypass. This will obviously be more important in specific use cases where Secure Boot is a key part of security.
This vulnerability was found by [eclypsium], who privately disclosed the bug to the Grub developers and other upstream projects. Patches are available, so make sure to get those updates installed. If your curious about the in-depth details, the writeup and PDF on BootHole are quite detailed, go check them out.
No comments:
Post a Comment