This Week In Security: F5, Novel Ransomware, Freta, And Database Woes

July 10, 2020 by Jonathan Bennett 5 Comments

The big story of the last week is a problem in F5’s BIG-IP devices. A rather trivial path traversal vulnerability allows an unauthenticated user to call endpoints that are intended to be restricted to authenticated. That attack can apparently be as simple as:

'https://[F5 Host]/tmui/login.jsp/..;/tmui/locallb/workspace/tmshCmd.jsp?command=list+auth+user+admin'

A full exploit has been added to the metasploit framework. The timeline on this bug is frighteningly quick, as it’s apparently being actively exploited in the wild. F5 devices are used all over the world, and this vulnerability requires no special configuration, just access to the opened management port. Thankfully F5 devices don’t expose the vulnerable interface to the internet by default, but there are still plenty of ways this can be a problem.

Freta

Microsoft has made a new tool publicly available, Freta. This tool searches for rootkits in uploaded memory snapshots from a Linux VM. The name, appropriately, is taken from the street where Marie Curie was born.

The project’s namesake, Warsaw’s Freta Street, was the birthplace of Marie Curie, a pioneer of battlefield imaging.

The impetus behind the project is the realization that once a malicious actor has compromised a machine, it’s possible to compromise any security software running on that machine. If, instead, one could perform a security x-ray of sorts, then a more reliable conclusion could be reached. Freta takes advantage of the VM model, and the snapshot capability built into modern hypervisors.

Continue reading “This Week In Security: F5, Novel Ransomware, Freta, And Database Woes” →

Explaining Efail And Why It Isn’t The End Of Email Privacy

May 21, 2018 by Pedro Umbelino 25 Comments

Last week the PGPocalipse was all over the news… Except that, well, it wasn’t an apocalypse.

A team of researchers published a paper(PDF) where they describe how to decrypt a PGP encrypted email via a targeted attack. The research itself is pretty well documented and, from a security researcher perspective, it’s a good paper to read, especially the cryptography parts.

But we here at Hackaday were skeptical about media claims that Efail had broken PGP. Some media reports went as far as recommending everyone turn off PGP encryption on all email clients., but they weren’t able to back this recommendation up with firm reasoning. In fact, Efail isn’t an immediate threat for the vast majority of people simply because an attacker must already have access to an encrypted email to use the exploit. Advising everyone to disable encryption all together just makes no sense.

Aside from the massive false alarm, Efail is a very interesting exploit to wrap your head around. Join me after the break as I walk through how it works, and what you can do to avoid it.

Continue reading “Explaining Efail And Why It Isn’t The End Of Email Privacy” →

Gigabytes The Dust With UEFI Vulnerabilities

April 4, 2017 by Jack Laidlaw 46 Comments

At this year’s BlackHat Asia security conference, researchers from Cylance disclosed two potentially fatal flaws in the UEFI firmware of Gigabyte BRIX small computers which allow a would-be attacker unfettered low-level access to the computer.

Gigabyte has been working on a fix since the start of 2017. Gigabyte are preparing to release firmware updates as a matter of urgency to only one of the affected models — GB-BSi7H-6500 (firmware vF6), while leaving the — GB-BXi7-5775 (firmware vF2) unpatched as it has reached it’s end of life. We understand that support can’t last forever, but if you sell products with such a big fault from the factory, it might be worth it to fix the problem and keep your reputation.

The two vulnerabilities that have been discovered seem like a massive oversight from Gigabyte, They didn’t enable write protection for their UEFI (CVE-2017-3197), and seem to have thrown cryptography out of the window when it comes to signing their UEFI files (CVE-2017-3198). The latter vulnerability is partly due to not verifying a checksum or using HTTPS in the firmware update process, instead using its insecure sibling HTTP. CERT has issued an official vulnerability note (VU#507496) for both flaws.

Attackers may exploit the vulnerabilities to execute unsigned code in System Management Mode (SMM), planting whatever malware they like into the low level workings of the computer. Cylance explain a possible scenario as follows:

The attacker gains user-mode execution through an application vulnerability such as a browser exploit or a malicious Word document with an embedded script. From there, the attacker elevates his privileges by exploiting the kernel or a kernel module such as Capcom.sys to execute code in ring 0. A vulnerable SMI handler allows the attacker to execute code in SMM mode (ring -2) where he finally can bypass any write protection mechanisms and install a backdoor into the system’s firmware.

With all this said, it does raise some interesting opportunities for the hacker community. We wonder if anyone will come up with a custom UEFI for the Brix since Gigabyte left the keys in the door.

When Responsible Disclosure Isn’t Enough

January 8, 2015 by Rick Osgood 37 Comments

Moonpig is a well-known greeting card company in the UK. You can use their services to send personalized greeting cards to your friends and family. [Paul] decided to do some digging around and discovered a few security vulnerabilities between the Moonpig Android app and their API.

First of all, [Paul] noticed that the system was using basic authentication. This is not ideal, but the company was at least using SSL encryption to protect the customer credentials. After decoding the authentication header, [Paul] noticed something strange. The username and password being sent with each request were not his own credentials. His customer ID was there, but the actual credentials were wrong.

[Paul] created a new account and found that the credentials were the same. By modifying the customer ID in the HTTP request of his second account, he was able to trick the website into spitting out all of the saved address information of his first account. This meant that there was essentially no authentication at all. Any user could impersonate another user. Pulling address information may not sound like a big deal, but [Paul] claims that every API request was like this. This meant that you could go as far as placing orders under other customer accounts without their consent.

[Paul] used Moonpig’s API help files to locate more interesting methods. One that stood out to him was the GetCreditCardDetails method. [Paul] gave it a shot, and sure enough the system dumped out credit card details including the last four digits of the card, expiration date, and the name associated with the card. It may not be full card numbers but this is still obviously a pretty big problem that would be fixed immediately… right?

[Paul] disclosed the vulnerability responsibly to Moonpig in August 2013. Moonpig responded by saying the problem was due to legacy code and it would be fixed promptly. A year later, [Paul] followed up with Moonpig. He was told it should be resolved before Christmas. On January 5, 2015, the vulnerability was still not resolved. [Paul] decided that enough was enough, and he might as well just publish his findings online to help press the issue. It seems to have worked. Moonpig has since disabled its API and released a statement via Twitter claiming that, “all password and payment information is and has always been safe”. That’s great and all, but it would mean a bit more if the passwords actually mattered.

Bad Code Results In Useless Passwords

December 7, 2014 by Rick Osgood 18 Comments

[HeadlessZeke] was excited to try out his new AT&T wireless cable box, but was quickly dismayed by the required wireless access point that came bundled with it. Apparently in order to use the cable box, you also need to have this access point enabled. Not one to blindly put unknown devices on his network, [HeadlessZeke] did some investigating.

The wireless access point was an Arris VAP2500. At first glance, things seemed pretty good. It used WPA2 encryption with a long and seemingly random key. Some more digging revealed a host of security problems, however.

It didn’t take long for [HeadlessZeke] to find the web administration portal. Of course, it required authentication and he didn’t know the credentials. [HeadlessZeke] tried connecting to as many pages as he could, but they all required user authentication. All but one. There existed a plain text file in the root of the web server called “admin.conf”. It contained a list of usernames and hashed passwords. That was strike one for this device.

[HeadlessZeke] could have attempted to crack the passwords but he decided to go further down this rabbit hole instead. He pulled the source code out of the firmware and looked at the authentication mechanism. The system checks the username and password and then sets a cookie to let the system know the user is authenticated. It sounds fine, but upon further inspection it turned out that the data in the cookie was simply an MD5 hash of the username. This may not sound bad, but it means that all you have to do to authenticate is manually create your own cookie with the MD5 hash of any user you want to use. The system will see that cookie and assume you’ve authenticated. You don’t even have to have the password! Strike two.

Now that [HeadlessZeke] was logged into the administration site, he was able to gain access to more functions. One page actually allows the user to select a command from a drop down box and then apply a text argument to go with that command. The command is then run in the device’s shell. It turned out the text arguments were not sanitized at all. This meant that [HeadlessZeke] could append extra commands to the initial command and run any shell command he wanted. That’s strike three. Three strikes and you’re out!

[HeadlessZeke] reported these vulnerabilities to Arris and they have now been patched in the latest firmware version. Something tells us there are likely many more vulnerabilities in this device, though.

[via Reddit]

Black Hat Hackers Face Off In Iron Chef Style Competition

July 7, 2008 by Juan Aguilar 1 Comment

Which is a better method for finding vulnerabilities, fuzzing or static-code analysis? The question will be put to the test at next month’s Black Hat USA conference, where two experienced ~~hackers~~ security researchers will be given a piece of mystery code and one hour to find all the vulnerabilities they can using one of the two methods. [Charlie Miller] from Independent Security Evaluators will use fuzzing and [Sean Fay] from Fortify Software will use static-code analysis to detect the vulnerabilities in the code. We reported on [Miller]’s fuzzing talk while at Toorcon 9.

The pair will be allowed to use their own equipment, but they won’t see the code until the moment the showdown begins. For an added bit of fun, conference attendees are welcome to join in the contest. The audience member who finds the most exploits within the hour wins a free dinner at a new Las Vegas restaurant. But you don’t have to wait until then to weigh in; go ahead and post your thoughts on fuzzing vs. static-code analysis in the comments, just be ready to back up your claims.