malware

43 Articles

UEFI-Hacked

Gigabytes The Dust With UEFI Vulnerabilities

April 4, 2017 by 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.

Super Mario Run(s) — Away With Your Money

January 11, 2017 by 37 Comments

If you are an Android user and a big fan of Super Mario beware: there is no Android version! There has been no official news on the Android version yet, let alone a version of the game. There is, however, a version circulating outside of Google Play market that will steal your bank account.

Right now attackers are taking advantage of the game’s popularity and Android users despair to spread malware posing as an Android version of Super Mario Run as they did in the past for Pokemon GO. The trojan is called Android Marcher and has been around since 2013, mostly targeting mobile users financial information. After installation, the application attempts to trick users with fake finance apps and a credit card page in an effort to capture banking details. The malware also locks out Google Play until the user supplies their credit card information.

In this new variant of Marcher, it can monitor the device and steal login data of regular apps, not just banking and payment apps, and send the stolen data back to command and control (C&C) servers. Facebook, WhatsApp, Skype, Gmail, the Google Play store are all vulnerable. Criminals can exploit these stolen accounts to carry out additional fraud.

Zscaler researchers advice is:

To avoid becoming a victim of such malware, it is a good practice to download apps only from trusted app stores such as Google Play. This practice can be enforced by unchecking the “Unknown Sources” option under the “Security” settings of your device.

We may add to turn on “App Verification”. Verify Apps regularly checks activity on your device and prevents or warns you about potential harm. Verify Apps is on by default, as is Unknown Sources turned off. Verify Apps also checks apps when you install them from sources other than Google Play. Of course, there is a privacy trade-off. Some information has to be sent about the apps you install back to Google.

The main advice is: use common sense. It’s common practice for companies to release official apps versions through Google Play and highly unlikely to do it via any other way.

Seeking Treachery In A Questionably Sourced Phone

September 26, 2016 by 24 Comments

Have you ever considered sourcing an off-brand phone from the China markets? Why, or what stopped you? The answer is data and identity. You are trusting both when you decide to use a smartphone. Let’s face it, smartphones are a personality prosthesis in our society. They know your physical location, what your interests are, the people you hang out with, and how you spend your money. The keys to the castle are shared with these devices and you shouldn’t grant that kind of trust without knowing your phone is worthy of it.

But… what if that phone has amazing features at an equally amazing price? [ijsf] bought the phone and then made it earn the proper level of trust. The model in question is a Blackview BV6000s — pictured above in a tub of soapy water proving it’s IP68 claim. This thing has flagship specs but not a flagship name so [ijsf] took [Dave Jones’] advice and took it apart instead of turning it on. In this case, it is a complete ROM dump and disassembly.

The goals was to find malware — anything that is potentially leaking data. Nothing was found, which we think is because this phone isn’t nearly shady enough. We’d expect the bargain basement models (like this $3 wonder vaporware) to be more in line. That one actually has a carrier behind it which means they plan to recoup on usage charges. But suspiciously cheap phones may be using a business model that makes it back by stealing a chunk of your identity.

Two good things come out of [ijsf’s] writeup. First, it’s a decent guide to dumping and snooping in a ROM. Second, in addition to the fruitless search for thieving apps, the annoying bloatware was removed for a cleaner ‘stock’ image.

Museum Shows Off Retro Malware

March 25, 2016 by 21 Comments

There’s some debate on which program gets the infamous title of “First Computer Virus”. There were a few for MS-DOS machines in the 80s and even one that spread through ARPANET in the 70s. Even John von Neumann theorized that programs might one day self-replicate. To compile all of these early examples of malware, and possibly settle this question once and for all, [Mikko Hypponen] has started collecting many of the early malware programs into a Museum of Malware.

While unlucky (or careless) users today are confronted with entire hard drive encryption viruses (or worse), a lot of the early viruses were relatively harmless. Examples include Brain which spread via floppy disk, the experimental ARPANET virus, or Elk Cloner which, despite many geniuses falsely claiming that Apples are immune to viruses, infected Mac computers of the 80s. [Mikko] has collected many more from this era that can be downloaded or demonstrated in a browser.

Retrocomputing is an active community, with users keeping gear of this era up and running despite it being 30+ years old. This software, while malicious at the time, is a great look into what the personal computing world was like in its infancy. And don’t forget, if you have a beige computer from a bygone era, you can always load up our Retro Page.

Thanks to [chad] for the tip!

Shmoocon 2016: GPUs And FPGAs To Better Detect Malware

January 17, 2016 by 40 Comments

One of the big problems in detecting malware is that there are so many different forms of the same malicious code. This problem of polymorphism is what led Rick Wesson to develop icewater, a clustering technique that identifies malware.

Presented at Shmoocon 2016, the icewater project is a new way to process and filter the vast number of samples one finds on the Internet. Processing 300,000 new samples a day to determine if they have polymorphic malware in them is a daunting task. The approach used here is to create a fingerprint from each binary sample by using a space-filling curve. Polymorphism will change a lot of the bits in each sample, but as with human fingerprints, patterns are still present in this binary fingerprints that indicate the sample is a variation on a previously known object.
Continue reading “Shmoocon 2016: GPUs And FPGAs To Better Detect Malware” →

Hard Drive Rootkit Is Frighteningly Persistent

June 8, 2015 by 82 Comments

There are a lot of malware programs in the wild today, but luckily we have methods of detecting and removing them. Antivirus is an old standby, and if that fails you can always just reformat the hard drive and wipe it clean. That is unless the malware installs itself in your hard drive firmware. [MalwareTech] has written his own frightening proof of concept malware that does exactly this.

The core firmware rootkit needs to be very small in order to fit in the limited memory space on the hard drive’s memory chips. It’s only a few KB in size, but that doesn’t stop it from packing a punch. The rootkit can intercept any IO to and from the disk or the disk’s firmware. It uses this to its advantage by modifying data being sent back to the host computer. When the computer requests data from a sector on the disk, that data is first loaded into the disk’s cache. The firmware can modify the data sitting in the cache before notifying the host computer that the data is ready. This allows the firmware to trick the host system into executing arbitrary code.

[MalwareTech] uses this ability to load his own custom Windows XP bootkit called TinyXPB. All of this software is small enough to fit on the hard drive’s firmware. This means that traditional antivirus cannot detect its presence. If the owner of the system does get suspicious and completely reformats the hard drive, the malware will remain unharmed. The owner cannot even re-flash the firmware using traditional methods since the rootkit can detect this and save itself. The only way to properly re-flash the firmware would be to use an SPI programmer, which would be too technical for most users.

There are many more features and details to this project. If you are interested in malware, the PDF presentation is certainly worth a read. It goes much more in-depth into how the malware actually works and includes more details about how [MalwareTech] was able to actually reverse engineer the original firmware. If you’re worried about this malicious firmware getting out into the wild, [MalwareTech] assures us that he does not intend to release the actual code to the public.

Excel Password

Breaking Dridex Malware With Excel Macro Password Exploit

March 20, 2015 by 17 Comments

[Ronnie] recently posted a new chapter in his adventures in malware deconstruction. This time the culprit was an infected Excel spreadsheet file. The .xls file was attached to a phishing email claiming to be related to a tax rebate. With tax season in full swing, this type of phishing message would be likely to be opened by an inexperienced user.

[Ronnie] saved the file to a virtual machine to prevent his real workstation from getting infected. He then opened it up in Excel and noticed that it immediately attempted to run macros. A macro is essentially visual basic scripting that runs inside of the spreadsheet file. You can use it for simple automation, cell formatting, or do even more complicated tasks like reach out to external websites and pull information. This malware focused on the latter.

[Ronnie] used the alt + F11 shortcut to view the macros. Unfortunately the attackers had password protected them. [Ronnie] wouldn’t be able to view the macro code without knowing the password. Luckily, he learned of a surprisingly simple trick to completely bypass the macro password. He opened up the .xls file in Notepad++ and located three keys; CMG, DPB, and G. [Ronnie] then created and saved a new blank .xls document and password protected the macros with his own password. He opened up this new file in Notepad++ as well, and located those same three keys. He copied the keys from the new file into the old one, and saved the old file. This effectively changed the password of the malware file to the new one he had set for his new file. This is a nifty trick that apparently only works on the older .xls formats, not the newer .xlsx format.

After loading the macros, [Ronnie] quickly noticed that most of the code was obfuscated to make it difficult to analyze. There were, however, three named modules that reference possible sandbox evasion techniques. The malware first invokes these functions to detect the presence of a virtual machine or other type of sandbox. If it detects nothing, then the rest of the malware program is decoded and executed. [Ronnie] removed these checks and then executed the macro to verify that his change had worked.

The next step was to try to view the decoded instructions. The decoded gibberish was saved to a variable. The simplest way for [Ronnie] to view the contents of the variable was to have the program create a pop-up box that displayed the contents of that variable. After making this change and running the program again, he was able to see exactly what the malware was doing. The code actually invoked Powershell, downloaded a file from the Internet, and then extracted and executed that file. In the full write-up, [Ronnie] goes even further by downloading and analyzing the executable.