Compromised Mac with Parallels?

[carmen617]

Got a call from a new client last night - they were looking for some help with Gmail on an iMac and found an online company that could help them, sigh. After starting a remote session and being told that her system was full of trojans and her IP address was broadcasting all their personal information, she agreed to allow them 100% free access on her computer for the 24 hours they needed to fix the problem. After about 3 hours or so, she thought perhaps she should call the local computer person (me) and ask my opinion. My opinion is that after letting them have unfettered control of her system for 3+ hours, there is nothing to do but backup, nuke, and pave. Not to mention the identity theft ramifications, but that's not my issue - I'm just tasked with getting the computer safe to put back onto the internet.

Typically not a big deal - my process would be to back up to Time Machine, erase the hard drive, reinstall MacOS, and then restore data and settings, letting them reinstall programs on their own. However, in this case
they are running Parallels and have a full PC setup on their Mac. I've only worked with Parallels a few times, and am not 100% sure how to handle it in this scenario.

Will the TM backup and data/settings restore put the VM data back into place? Do I need to do some type of separate Windows backup first? They are going to reinstall Parallels themselves so I need to give them some way to restore the data - experienced suggestions are highly appreciated!

 

[Markverhyden]

Was the VM running when the blackhats had access to the computer? Did they have access to the credentials or is it setup to automatically boot to the desktop?

Parallels creates a .pvm which is actually a package, as in like an app package. But if you drill down into the contents you'll eventually get to the HD file and that is treated as a monolithic file. So TM can only backup the entire file each time, no incrementals. The correct way to backup any VM is to shut it down then do the backup. Customers will rarely do that. So getting a complete backup of the HD file, as well as the rest of the .pvm can be problematic. You can get it too work. Many times the restored .pvm will boot but then go into file repair but eventually may mount properly. But you might have to go back to a backup done late at night/early AM to have the best chance of success. Usually the VM is just idling so that file integrity is usually much better than other times. If the TM had been running to a USB drive it should be ok. Over a network, especially wireless, is a different matter.

I'd be far more worried about the VM side than the Apple side. It's much easier to p0wn a M$ machine than an Apple in a manner that is undetectable. Personally I'd do a separate backup of the VM data files and settings, say with Fabs, build the VM from scratch. I'd also make sure to scan the backup separately just to be on the safe side.

 

[carmen617]

Was the VM running when the blackhats had access to the computer? Did they have access to the credentials or is it setup to automatically boot to the desktop?

Parallels creates a .pvm which is actually a package, as in like an app package. But if you drill down into the contents you'll eventually get to the HD file and that is treated as a monolithic file. So TM can only backup the entire file each time, no incrementals. The correct way to backup any VM is to shut it down then do the backup. Customers will rarely do that. So getting a complete backup of the HD file, as well as the rest of the .pvm can be problematic. You can get it too work. Many times the restored .pvm will boot but then go into file repair but eventually may mount properly. But you might have to go back to a backup done late at night/early AM to have the best chance of success. Usually the VM is just idling so that file integrity is usually much better than other times. If the TM had been running to a USB drive it should be ok. Over a network, especially wireless, is a different matter.

I'd be far more worried about the VM side than the Apple side. It's much easier to p0wn a M$ machine than an Apple in a manner that is undetectable. Personally I'd do a separate backup of the VM data files and settings, say with Fabs, build the VM from scratch. I'd also make sure to scan the backup separately just to be on the safe side.

Thanks Mark - I haven't even looked at the machine yet, it just got dropped off, but it sounds like it's best to just do a Fabs backup in the VM and then restore once they have Parallels set up again. Do you concur that a TM backup, drive erase, fresh MacOS install, then restore of settings and data is sufficient for the Mac side?

 

[Markverhyden]

Thanks Mark - I haven't even looked at the machine yet, it just got dropped off, but it sounds like it's best to just do a Fabs backup in the VM and then restore once they have Parallels set up again. Do you concur that a TM backup, drive erase, fresh MacOS install, then restore of settings and data is sufficient for the Mac side?

Yep that's a good game plan for the Apple side. To be honest it's extremely difficult to seriously compromise OS X. Of course apps can be added, but the built security for OS X, System Integrity Protection, since 10.11 makes it nearly impossible to remotely compromise a machine. The only way to turn off SIP is to have physical access.

But that can take time and if it's flat rate it's much better from a time perspective to just backup, nuke, pave, restore. If you're doing the OS install via a wired connection you can be at first run in less than 30 minutes. Just make sure to scan both of the backups prior to restoring just to be on the safe side.

Also, if it was me, I'd pitch an SSD as an upgrade if it does not have one, Microcenter had the 500gb EVO's for 70-80 a week or two ago. Of course if it's one of the newer models you'd have to get the adhesive kit from iFixit. FYI, all the SSD's I've bought recently never had a 2.5>3.5 tray adapter.

 

[carmen617]

Yep that's a good game plan for the Apple side. To be honest it's extremely difficult to seriously compromise OS X. Of course apps can be added, but the built security for OS X, System Integrity Protection, since 10.11 makes it nearly impossible to remotely compromise a machine. The only way to turn off SIP is to have physical access.

But that can take time and if it's flat rate it's much better from a time perspective to just backup, nuke, pave, restore. If you're doing the OS install via a wired connection you can be at first run in less than 30 minutes. Just make sure to scan both of the backups prior to restoring just to be on the safe side.

Also, if it was me, I'd pitch an SSD as an upgrade if it does not have one, Microcenter had the 500gb EVO's for 70-80 a week or two ago. Of course if it's one of the newer models you'd have to get the adhesive kit from iFixit. FYI, all the SSD's I've bought recently never had a 2.5>3.5 tray adapter.

I have High Sierra on a thumb drive, lazy me hates waiting for downloads. The client has decided to ditch parallels so i'm just going to back up whatever data is in there and give that back to them as a file on the Mac to do whatever they want.

The system is a newer iMac with a fusion drive in it so I'm not going to make any upgrade recommendations. But good for you for remembering my flat rate model! Thanks again for your help!

 

[Markverhyden]

The system is a newer iMac with a fusion drive in it so I'm not going to make any upgrade recommendations. But good for you for remembering my flat rate model! Thanks again for your help!

Fusion? Yech! They can keep that. LOL!!!

 

[carmen617]

Fusion? Yech! They can keep that. LOL!!!

Lol - I agree - certainly wouldn't recommend it. However I'm not gonna pull that sucker apart to replace it either.

 

[phaZed]

Yep that's a good game plan for the Apple side. To be honest it's extremely difficult to seriously compromise OS X. Of course apps can be added, but the built security for OS X, System Integrity Protection, since 10.11 makes it nearly impossible to remotely compromise a machine. The only way to turn off SIP is to have physical access.

I wouldn't put too much confidence in SIP. It's one of the things that is often broken or bypassed first when I test these CVE's. The problem with SIP, it's the same chicken-egg problems as any system with an X86/64 architecture: how can you ensure that SIP is not vulnerable itself or vulnerable or unable to detect arbitrary code execution from trusted apps or services? Buffer Overflows? Keeping patched and up to date is the most one can do and should do for all systems, Mac or otherwise!

How does a 16 Year Old kid from Australia hack into Apple Servers in 2018 and steal 1TB of data over the course of more than a year? He uses Metasploit and Nessus and talks to people on WhatsApp. It's really not that hard if you can find that "in", apparently SIP "be damned".

Then Apple Responded with a load of horse sh** like always:

“At Apple, we vigilantly protect our networks and have dedicated teams of information security professionals that work to detect and respond to threats,” a company spokesman told Guardian Australia in a statement.

“In this case, our teams discovered the unauthorised access, contained it, and reported the incident to law enforcement. We regard the data security of our users as one of our greatest responsibilities and want to assure our customers that at no point during this incident was their personal data compromised.”

Well, your vigilant team didn't notice a year's worth of unauthorized access to a TB of data flowing to Australia! No personal data was compromised!?!? Well, the kid:

The Age said customer data had been accessed, and that the boy managed to obtain customers’ authorised keys – their login access.

So, I guess your Apple ID and password, according to Apple, isn't personal information even after he logs into your Apple account with your name and address plastered in the Personal info section, etc. Gimme a break!

This is why I really don't like Mac's - on the forums it is hard to convey this message without being called a "Mac-Hater" (Even while running VM's, 2 laptops and a Hackintosh) - It's because Apple operates in a pseudo-obscurity fashion. Because Apple is so "closed" and secret, they think that affords the right to have obscurity as security... then they never want to admit that, or that they are vulnerable... then deny the problem out of vanity.. yet, always advertise how "safe" or "better" they are, etc.. It's a lie for the most part. It was more true before the Intel chipsets.. now, it's just another computer, but overpriced. That's just my feelings, not a universal truth for all!

From a remote perspective, but on the same LAN network, Windows 10 and MacOSX are equally as hard/easy to exploit. The more vulnerable programs and Apps you have, the easier it becomes to drop a shell. Windows 10 As a Service - it's working pretty well.. mostly keeping everything up to date and vulns patched... quickly, end user side-effects not withstanding.

Up until 10.11.4 this is the exploit code to disable SIP as they failed to patch it the first time:

ln -s /S*/*/E*/A*Li*/*/I* /dev/diskX;fsck_cs /dev/diskX 1>&-;touch /Li*/Ex*/;reboot

Last week security media reported a critical privilege escalation flaw (CVE-2016-1757) in the Apple System Integrity Protection (SIP) security mechanism, a vulnerability that was present at the time of the discovery in all the version of the OS X operating system.

This week, Apple issued a security update of OS X El Capitan 10.11.4 and iOS 9.3 to solve the problem, but according to the experts it was ineffective in fixing the privilege escalation vulnerability.

The flaw was discovered by the security researcher Pedro Vilaça from SentinelOne and exposes more than 130 Million Apple customers at risk of hack. The attackers can exploit the flaw for various purposes, for example, the vulnerability could be exploited in a multi-stage attack in which crooks have already compromised the target system and use the flaw to gain persistence on compromised devices.

The SIP is a security mechanism implemented by Apple in the OS X El Capitan operating system for the protection of certain system processes, files and folders from being modified or tampered with by other processes, even when they are executed by a user with root privileges.

According to the experts at SentinelOne the flaw allows circumventing the SIP technology bypassing the key security feature without kernel exploits. Now Apple issued a security patch for both OS X El Capitan 10.11.4 and iOS 9.3, but it seems that the update is ineffective, causing the users’ disappointment.

This one is the latest one I have been trying to get working lately (that ME flaw!)(Using Nessus: Plugin ID 110324):

CVE-2018-4251 An issue was discovered in certain Apple products. macOS before 10.13.5 is affected. The issue involves the "Firmware" component. It allows attackers to modify the EFI flash-memory region that a crafted app that has root access.

With that one alone it should be possible to flip the bit on SIP. Call for a reboot and its all over. Patches are here, but what remains?



Regarding CVE-2018-4251:
http://iotsecuritynews.com/cve-2018...able-intel-manufacturing-mode-in-its-laptops/

Last year, experts from the Electronic Frontier Foundation asked Intel to provide a way to disable the IME.

In August 2017, the experts from Positive Technologies (Dmitry Sklyarov, Mark Ermolov, and Maxim Goryachy) discovered a way to disable the Intel Management Engine 11 via an undocumented mode.

The researchers discovered that it is possible to turn off the Intel ME by setting the undocumented high assurance platform (HAP) bit to 1 in a configuration file.

The experts discovered that the security framework was developed by the US National Security Agency … yes the NSA!

This week, researchers Maxim Goryachy and Mark Ermolov published a blog post that revealed Chipzilla’s ME contains an undocumented Manufacturing Mode.

“Intel ME Manufacturing Mode is intended for configuration and testing of the end platform during manufacturing, and as such should be disabled (closed) before sale and shipment to users,” states the security duo.

“However, this mode and its potential risks are not described anywhere in Intel’s public documentation.”

The only way to access the Intel Manufacturing Mode is using a utility included in Intel ME System Tools software, that anyway isn’t available to the public. The software allows to configure platform settings in one-time programmable memory called Field Programming Fuses (FPF), an operation that is usually made before the shipment, and in ME’s internal MFS (Minux File System) on SPI (Serial Peripheral Interface) flash memory, via parameters known as CVARs (Configurable NVARs, Named Variables).

On older systems, prior to Apollo Lake, Intel maintained access rights for th Intel Management Engine, Gigabit Ethernet, and CPU separate.

In newer systems, the SPI controllers implement the Master Grant feature that could override the access rights declared in the SPI descriptor.

“What this means is that even if the SPI descriptor forbids host access to an SPI region of ME, it is possible for ME to still provide access,” the researchers explain.

Experts pointed out that device makers cannot disable the Manufacturing Mode opening the door to cyber attacks by a local attacker.

This is just a few others (Many more at the CVE site) from 2018 to keep in consideration, they all allow for arbitrary code execution (generally as root) - essentially the entire system is vulnerable from WebKit to the Hypervisor to the Kernel. Encrypted Mail is broken for direct, remote exfiltration, etc. (All 2018 - but older OS CVE's - current, unknown CVE's are held for Apple to debug/fix etc.):

CVE-2018-4246 An issue was discovered in certain Apple products. iOS before 11.4 is affected. Safari before 11.1.1 is affected. iCloud before 7.5 on Windows is affected. iTunes before 12.7.5 on Windows is affected. tvOS before 11.4 is affected. watchOS before 4.3.1 is affected. The issue involves the "WebKit" component. It allows remote attackers to execute arbitrary code via a crafted web site that leverages type confusion.

CVE-2018-4243 An issue was discovered in certain Apple products. iOS before 11.4 is affected. macOS before 10.13.5 is affected. tvOS before 11.4 is affected. watchOS before 4.3.1 is affected. The issue involves the "Kernel" component. A buffer overflow in getvolattrlist allows attackers to execute arbitrary code in a privileged context via a crafted app.

CVE-2018-4242 An issue was discovered in certain Apple products. macOS before 10.13.5 is affected. The issue involves the "Hypervisor" component. It allows attackers to execute arbitrary code in a privileged context or cause a denial of service (memory corruption) via a crafted app.

CVE-2018-4241 An issue was discovered in certain Apple products. iOS before 11.4 is affected. macOS before 10.13.5 is affected. tvOS before 11.4 is affected. watchOS before 4.3.1 is affected. The issue involves the "Kernel" component. A buffer overflow in mptcp_usr_connectx allows attackers to execute arbitrary code in a privileged context via a crafted app.

CVE-2018-4237 An issue was discovered in certain Apple products. iOS before 11.4 is affected. macOS before 10.13.5 is affected. tvOS before 11.4 is affected. watchOS before 4.3.1 is affected. The issue involves the "libxpc" component. It allows attackers to gain privileges via a crafted app that leverages a logic error.

CVE-2018-4236 An issue was discovered in certain Apple products. macOS before 10.13.5 is affected. The issue involves the "IOGraphics" component. It allows attackers to execute arbitrary code in a privileged context or cause a denial of service (memory corruption) via a crafted app.

CVE-2018-4234 An issue was discovered in certain Apple products. macOS before 10.13.5 is affected. The issue involves the "IOHIDFamily" component. It allows attackers to execute arbitrary code in a privileged context or cause a denial of service (memory corruption) via a crafted app.

CVE-2018-4230 An issue was discovered in certain Apple products. macOS before 10.13.5 is affected. The issue involves the "NVIDIA Graphics Drivers" component. It allows attackers to execute arbitrary code in a privileged context via a crafted app that triggers a SetAppSupportBits use-after-free because of a race condition.

CVE-2018-4229 An issue was discovered in certain Apple products. macOS before 10.13.5 is affected. The issue involves the "Grand Central Dispatch" component. It allows attackers to bypass a sandbox protection mechanism by leveraging the misparsing of entitlement plists. Oh well for SIP!

CVE-2018-4228 An issue was discovered in certain Apple products. macOS before 10.13.5 is affected. The issue involves the "IOFireWireAVC" component. It allows attackers to execute arbitrary code in a privileged context via a crafted app that leverages a race condition.

CVE-2018-4227 An issue was discovered in certain Apple products. iOS before 11.4 is affected. macOS before 10.13.5 is affected. The issue involves the "Mail" component. It allows remote attackers to read the cleartext content of S/MIME encrypted messages via direct exfiltration.

CVE-2018-4226 An issue was discovered in certain Apple products. iOS before 11.4 is affected. macOS before 10.13.5 is affected. iCloud before 7.5 on Windows is affected. iTunes before 12.7.5 on Windows is affected. watchOS before 4.3.1 is affected. The issue involves the "Security" component. It allows local users to bypass intended restrictions on the reading of sensitive user information.

CVE-2018-4225 An issue was discovered in certain Apple products. iOS before 11.4 is affected. macOS before 10.13.5 is affected. iCloud before 7.5 on Windows is affected. iTunes before 12.7.5 on Windows is affected. watchOS before 4.3.1 is affected. The issue involves the "Security" component. It allows local users to bypass intended restrictions on Keychain state modifications.

CVE-2018-4223 An issue was discovered in certain Apple products. iOS before 11.4 is affected. macOS before 10.13.5 is affected. tvOS before 11.4 is affected. watchOS before 4.3.1 is affected. The issue involves the "Security" component. It allows local users to bypass intended restrictions on the reading of a persistent account identifier.

CVE-2018-4221 An issue was discovered in certain Apple products. iOS before 11.4 is affected. macOS before 10.13.5 is affected. The issue involves the "Security" component. It allows web sites to track users by leveraging the transmission of S/MIME client certificates.

CVE-2018-4219 An issue was discovered in certain Apple products. macOS before 10.13.5 is affected. The issue involves the "ATS" component. It allows attackers to gain privileges via a crafted app that leverages type confusion.
CVE-2018-4218 An issue was discovered in certain Apple products. iOS before 11.4 is affected. Safari before 11.1.1 is affected. iCloud before 7.5 on Windows is affected. iTunes before 12.7.5 on Windows is affected. tvOS before 11.4 is affected. watchOS before 4.3.1 is affected. The issue involves the "WebKit" component. It allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site that triggers an @generatorState use-after-free.

CVE-2018-4215 An issue was discovered in certain Apple products. iOS before 11.4 is affected. The issue involves the "Bluetooth" component. It allows attackers to gain privileges or cause a denial of service (buffer overflow) via a crafted app.

CVE-2018-4211 An issue was discovered in certain Apple products. iOS before 11.4 is affected. macOS before 10.13.5 is affected. tvOS before 11.4 is affected. watchOS before 4.3.1 is affected. The issue involves the "FontParser" component. It allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted font file.