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.
And yet another exploit made possible by the lack of a length check on a data field, in this case the 15 character password.
People must keep in mind that when you exchange data things can go wrong! And as there’s no way to guarantee the consistency of data generated from an outside source, the safety resides in being prepared for detect error conditions and be able to react adequately.
That’s why I always say that client side protection is to protect the client against inconveniences, they are not protecting the server at all…
YES & AMEN! The first rule any web developer needs to get in his/her head is: You can NOT trust ANYTHING coming from the browser/client. Not the cookies you put there or the results of the JS you provided. The bad guys will corrupt those things or simply fake their own data. All data integrity/security checks MUST be handled on the server. And if you don’t want the user to have to wait for the post request… then you have to write the code again in JS. The client side being fluff and the server side being concrete.
After you absorb that then go learn the relevant languages.
I see a lot of “professionally” produced code that violates that principal and the devs have usually touted “security” as one of their selling points. All very shameful.
I agree, you write it the browser so the user can get specific areas and checking done locally, then you DO IT ALL AGAIN (AND MORE) on the server, as you assume people who are attacking you aren’t even running your web page, let alone your javascript…
Pogotv in title. Pongotv in article.