Category Archives: apple

Facebook: A Top Launching Pad For Phishing Attacks

Amazon, Apple, Netflix, Facebook and WhatsApp are top brands leveraged by cybercriminals in phishing and fraud attacks - including a recent strike on a half-million Facebook users.

Hacking Apple for Profit

Five researchers hacked Apple Computer’s networks — not their products — and found fifty-five vulnerabilities. So far, they have received $289K.

One of the worst of all the bugs they found would have allowed criminals to create a worm that would automatically steal all the photos, videos, and documents from someone’s iCloud account and then do the same to the victim’s contacts.

Lots of details in this blog post by one of the hackers.

iPhone Hacks: What You Need to Know About Mobile Security

Guest Post by Jennifer Bell

Learn How Hackers Steal and Exploit Information to Ensure This Doesn’t Happen to You 


Cybersecurity is an important topic to know and understand in order to keep your information safe and secure. Even more specifically, it’s important to know and understand mobile security as well. Mobile security, especially with iPhones, is crucial as hackers are becoming smarter and more creative when it comes to iCloud hacks. Apple has partnered with network hardware and insurance companies such as Cisco and Aon to provide security against data breaches; but how can you ensure that even with these Apple partnerships that your iPhone is secure and protected against hackers? Here are the most common ways that hackers get into iPhones to steal or exploit personal information, keep these points in mind to best protect yourself from mobile security hacks.


Poor Passwords
Often, poor password choices or poor password management allows hackers to easily hack into iPhones and other Apple products. Hackers are skilled at obtaining Apple IDs and passwords using phishing scams which are attempts to obtain personal data and information by posing as credible and trustworthy electronic entities. Here are some tips to protect your password from hackers and phishing scams:

  • Set up two-factor authentication for your Apple account 
  • Choose passwords that have no significant personal meaning; such as birthdays or names of family or pets. Hackers can easily do their research and make educated guesses as to what a password maybe 
  • Back up information in other places besides just the iCloud 
  • Change all passwords if even just one account is hacked 
Untrustworthy Websites
One of the most common ways that hackers make their way into iPhones and other Apple products is by using websites that are not credible. These websites either have holes in the software that allows hackers to get into an iPhone or, they use websites to ask for personal information such as credit card information or contact information. How do you know if a website is credible?
  • Ask yourself, does this website look trustworthy? Have I ever heard of it? Does it make sense for it to be asking me these questions? 
  • Use a secure middle layer payment option for purchases. Using PayPal or Visa Checkout is a great way to make payments online because the payment is not directly connected to any of your bank information 
  • Don’t open emails or any attachments that link you to a website if it comes from an untrusted sender 
  • Look up websites if you haven't ever heard of them. If the website is untrustworthy, it’s likely that people have been scammed or hacked on there before and have shared/posted their story 
Public WiFi Networks
Hackers have been known to gain access to iPhones using WiFi spoofing which is creating a WiFi network that doesn’t require a password and seems like a trustworthy network. Computer forensic services have also discovered that if your iPhone is set up to automatically connect to WiFi, your iPhone will automatically sync up to a spoofed WiFi network and will open your phone up to hackers without you knowing. Avoiding public WiFi networks can potentially save your iPhone from hackers; similarly, avoid public hotspots for the same reason. 

Protect Your iPhone From Cyberattacks
Hackers are becoming more and more knowledgeable when it comes to stealing and exploiting people’s personal information found on their iPhones. Keep these points in mind and remember to keep your iPhone’s software up to date; these things can ultimately secure your personal information and save you from falling victim to hackers’ harsh motives.

About the Author 

Jennifer Bell is a freelance writer, blogger, dog-enthusiast and avid beachgoer operating out of Southern New Jersey

Cyber Security Roundup for July 2020

A roundup of UK focused Cyber and Information Security News, Blog Posts, Reports and general Threat Intelligence from the previous calendar month, June 2020.

Australian Prime Minister Scott Morrison announced a sophisticated nation-state actor is causing increasing havoc by attacking the country’s government, corporate institutions, and his country's critical infrastructure operators. He said, “We know it is a sophisticated state-based cyber actor because of the scale and nature of the targeting and the tradecraft used". While Morrison didn't actually name the specific country responsible in his statement, Reuters said its sources confirmed China was the culprit.  Political t
ensions have ramped up between Australia and China in recent months after Australia called for an investigation into China’s handling of the COVID-19 pandemic. China then reacted by placing tariffs on Australian exports and banning shipments of beef from Australia.

Why am I leading a UK cybersecurity blog with an Australian cyberattacks story? Well, it is because the UK might well be next in the cross-hairs of China's sophisticated cyber army, after the UK Governance stance on using Huawei in 5G infrastructure significantly soured last month. And also due to the increasing political pressure applied by the UK government on the Chinese government following their introduction of a controversial new security law in Hong Kong.

Increased UK Huawei Tensions in June 2020
While the Australian PM righty suggested their nation-state threat actor was sophisticated, the cyberattacks they described aren't so sophisticated. Their attackers engaged in spear-phishing campaigns designed to trick email recipients into clicking a link leading to a malicious files or credential harvesting page, opening malicious attachments or granting Office 365 OAuth tokens to the actors.  This is the same MO of cyber attacks orchestrated by the cybercriminals fraternity on a daily basis. The Australian government statement advises organisations to patch their internet-facing devices, including web and email servers and to use multifactor authentication. All good advise, in fact, all essential good practice for all organisations to adopt no matter their threat actor landscape.

Away from the international cyber warfare scene, a coalition led by security companies is urging the UK government to revamp the much-dated Computer Misuse Act. The UK's 'anti-hacking' law is 30 years old, so written well before the internet took root in our digital society, so is not really suitable for prosecuting for modern cybercriminals, they tend to be prosecuted under financial crime and fraud laws. The coalition is calling for a change in the law includes the NCC Group, F-Secure, techUK, McAfee and Trend Micro. They argue section 1 of the Act prohibits the unauthorised access to any programme or data held in any computer and has not kept pace with advances in technology. In their letter to PM they said "With the advent of modern threat intelligence research, defensive cyber activities often involve the scanning and interrogation of compromised victims and criminals systems to lessen the impact of attacks and prevent future incidents. In these cases, criminals are obviously very unlikely to explicitly authorise such access."

Since launching a 'Suspicious Email Reporting Service' in April 2020, the UK National Cyber Security Centre (NCSC) announced it has now received one million reports, receiving around 16,500 emails a day. NCSC Chief Executive Officer Ciaran Martin called the number of reports a “milestone” and “a testament to the vigilance of the British public". I think the email reporting service is another fantastic free service provided by NCSC (i.e. UK Gov) to UK citizens, so one thing the UK government is definitely getting right in the cybersecurity space at the moment.

Zoom announced it will extend 'optional' end-to-end encryption (E2EE) to free users. It is not certain when exactly Zoom's free E2EE will commence or whether it will be defaulted as on, given the Zoom CEO said, “We plan to begin early beta of the E2EE feature in July 2020.” Still good to see the much security criticised Zoom is continuing to bolstering its security, and also by appointing a seasoned Chief Information Security Officer from Salesforce.

Some men just want to watch the world burn...
With the recent uptick in ransomware, phishing, unsecured cloud buckets and massive data breaches dominating the media headlines over the past couple of years, you could be forgiven for forgetting about the threat posed by Distributed-Denial-of-Service (DDoS) attacks. So then, a timely reminder that some threat actors have vast botnets as their disposal for orchestrating huge DDoS attacks after Amazon reported thwarting the biggest ever DDoS attack, and a European bank suffered the biggest ever PPS DDoS attack. The motives of these colossal DDoS attacks are unclear, I guess some men just want to watch the world burn.
Quote from Batman butler Alfred (Michael Caine), The Dark Knight
BLOG
NEWS
VULNERABILITIES AND SECURITY UPDATES
AWARENESS, EDUCATION AND THREAT INTELLIGENCE

    Cyber Security Roundup for June 2020

    A roundup of UK focused Cyber and Information Security News, Blog Posts, Reports and general Threat Intelligence from the previous calendar month, May 2020.

    EasyJet's disclosure of a "highly sophisticated cyber-attack", which occurred in January 2020, impacting 9 million of their customers was the biggest cybersecurity story of May 2020 in the UK. Although no details about this 'cyber-attack' were disclosed, other than 2,208 customers had their credit card details accessed.  


    Using terms like "highly sophisticated" without providing any actual details of the cyberattack makes one think back to when TalkTalk CEO Dido Harding described a cyber-attack as "significant and sustained cyber-attack" in 2015. In TalkTalk's case, that cyber attack turned out to be a bunch of teenage kids taking advantage of a then 10-year-old SQL injection vulnerability.  City A.M. described Dido's responses as "naive", noting when asked if the affected customer data was encrypted or not, she replied: "The awful truth is that I don’t know". Today Dido is responsible for the UK governments Track, Test and Trace application, which no doubt will ring privacy alarms bells with some. 

    Back to the EasyJet breach, all we know is the ICO and the NCSC are supporting UK budget airline, EasyJet said "We take issues of security extremely seriously and continue to invest to further enhance our security environment. There is no evidence that any personal information of any nature has been misused, however, on the recommendation of the ICO, we are communicating with the approximately nine million customers whose travel details were accessed to advise them of protective steps to minimise any risk of potential phishing. We are advising customers to be cautious of any communications purporting to come from EasyJet or EasyJet Holidays." 

    It will be interesting to see the DPA enforcement line Information Commission's Office (ICO) adopts with EasyJet, especially considering the current COVID-19 impact on the UK aviation industry.  Some security commentators have called ICO a "Toothless Tiger" in regards to their supportive response, an ICO label I've not heard since long before the GDPR came into force. But the GDPR still has a sting its tail beyond ICO enforcement action in the UK, in that individuals impacted by personal data breaches can undertake a class-action lawsuit. So then, it can be no real surprise to law firm PGMBM announce it has issued a class-action claim in the High Court of London, with a potential liability of an eye-watering £18 billion!. If successful, each customer impacted by the breach could receive a payout of £2,000.

    The 2020 Verizon Data Breach Investigations Report (DBIR) was released, the most valuable annual report in the cybersecurity industry in my humble opinion. The 2020 DBIR used data compiled before COVID-19 pandemic.  The report analyses 32,002 security incidents and 3,950 confirmed breaches from 81 global contributors from 81 countries.
    • 86% of data breaches for financial gain - up from 71% in 2019 
    • 43% web application (cloud-based) - these attacks have doubled, reflecting the growth in the use of cloud-based services.
    • 67% of data breaches resulted from credential theft, human error or social attacks. 
    • Clearly identified cyber-breach pathways enable a “Defender Advantage” in the fight against cyber-crime 
    • On-going patching successful - fewer than 1 in 20 breaches exploit vulnerabilities
    The vast majority of breaches continue to be caused by external actors.
    • 70% with organised crime accounting for 55% of these. 
    • Credential theft and social attacks such as phishing and business email compromises cause the majority of breaches (over 67%), specifically:
      • 37% of credential theft breaches used stolen or weak credentials,
      • 25% involved phishing
      • Human error accounted for 22%
    The 2020 DBIR highlighted a two-fold increase in web application breaches, to 43%, and stolen credentials were used in over 80% of these cases. Ransomware had a slight increase, found in 27% of malware incidents compared to 24% in the 2019 DBIR with 18% of organisations reported blocking at least one piece of ransomware last year.

    REvil (aka Sodinokibi) hackers are said to have stolen celebrity data from a law firm 'Grubman Shire Meiselas & Sacks'. With 756 gigabytes of personal data, emails, and contract details were taken, including Lady Gaga, Madonna, Elton John, Barbara Streisand, Bruce Springsteen and Mariah Carey to name a few. 

    Pitney Bowes was hit with ransomware for the second time in 7 monthsPitney Bowes said attackers breached company systems and accessed “a limited set of corporate file shares” that “contained information used by our business teams and functional groups to conduct business-related activities.” News reports state the Maze ransomware group is behind the attack, threatening to post confidential if Pitney Bowes does not pay up.

    Amazon's UK website was defaced with racist abuse,  which appeared on multiple listings on its UK website. Amazon has not disclosed how long the racist language remained on the site, but it sparked outrage on Twitter, Amazon said: "We investigated, removed the images in question and took action against the bad actor".

    LogMeOnce, a password identity management suite provider, has published a detailed interview with myself titled 'Passwords are and have always been an Achilles Heel in CyberSecurity'. In the Q&A I talk about Passwords Security (obviously), Threat Actors, IoT Security, Multi-Factor Authentication (MFA), Anti-Virus, Biometrics, AI, Privacy, and a bit on how I got into a career in Cybersecurity.

    BLOG
    NEWS
    VULNERABILITIES AND SECURITY UPDATES
    AWARENESS, EDUCATION AND THREAT INTELLIGENCE

      The Guardian view on an NHS coronavirus app: it must do no harm | Editorial

      Smartphones can be used to digitally trace Covid-19. But not if the public don’t download an app over privacy fears – or find it won’t work on their device

      The idea of the NHS tracing app is to enable smartphones to track users and tell them whether they interacted with someone who had Covid-19. Yet this will work only if large proportions of the population download the app. No matter how smart a solution may appear, mass consent is required. That will not be easy. Ministers and officials have failed to address the trade-offs between health and privacy by being ambiguous about the app’s safeguards.

      Instead of offering cast-iron guarantees about the length of time for which data would be held; who can access it; and the level of anonymity afforded, we have had opacity and obfuscation. It is true that we are dealing with uncertainties. But without absolute clarity about privacy the public is unlikely to take up the app with the appropriate gusto.

      Continue reading...

      Rotten Apples: Resurgence

      In June 2016, we published a blog about a phishing campaign targeting the Apple IDs and passwords of Chinese Apple users that emerged in the first quarter of 2016 (referred to as the “Zycode” phishing campaign). At FireEye Labs we have an automated system designed to proactively detect newly registered malicious domains and this system had observed some phishing domains that were designed to appear as legitimate Apple domains. Most of the domains reported by this system were suspended in June 2016, which resulted in a loss of momentum for the Zycode phishing campaign. Throughout the second quarter of 2016, the Zycode phishing campaign was in hibernation.

      We recently observed a resurgence of the same phishing campaign when our systems detected roughly 90 phony Apple-like domains that were registered from July 2016 to September 2016. Once again, Chinese Apple users are being targeted for their Apple IDs and passwords using the same content reported on in our earlier blog. The majority of these domains are registered in the .com TLD by email accounts from qq[.]com, and the IPs of these domains point to mainland China, as seen in Figure 1.

      Figure 1: Google map showing the location of the hosted phishing domains

      What has not Changed?

      The attackers have not changed the content of the phishing sites. The obfuscated JavaScript used in the earlier version is once again being used here in this campaign. We have provided the details of JavaScript and screenshots of interaction with the website in our earlier blog.

      What has Changed?

      Apparently the domains and email addresses used in previous version of the campaign were effectively taken down. Now the attackers have moved to a new malicious infrastructure; new domains, IPs and email addresses are being used for this campaign. The new domain names for the campaign are listed in Table 1, while their IPs and registrant emails are reported in Table 2 and Table 3, respectively.

      Domains List

      Table 1: Apple phishing domains serving the Zycode phishing kit.

      Unique IP(s)

      Table 2 shows the list of unique IPs, which are not the same as what was seen before.

      Table 2. IP addresses used by the domains.

      Unique Email Addresses

      The email addresses used to register these domains, showing no similarity with email addresses in the previous campaign, are shown in Table 3.

      Table 3. List of unique registrant emails.

      Unique Registrants

      Table 4 shows the registrant names, which have no similarity with the previous registrant name information.

      Table 4. List of registrant names used by the phishing domains.

      How to Avoid Being a Victim

      Apple provides information on phishing here and here, and on iCloud security here. There are simple ways for a user to be more secure against this and similar attacks. The following are a few tips:

      • Enable two-factor authentication for Apple ID.
      • Always check the address bar for the correct web address.
      • Avoid clicking links in emails and SMS messages that supposedly direct to iCloud pages.
      • Use our FireEye EX appliance, which provides effective detection for the Zycode phishing campaign.

      iBackDoor: High-Risk Code Hits iOS Apps

      Introduction

      FireEye mobile researchers recently discovered potentially “backdoored” versions of an ad library embedded in thousands of iOS apps originally published in the Apple App Store. The affected versions of this library embedded functionality in iOS apps that used the library to display ads, allowing for potential malicious access to sensitive user data and device functionality. NOTE: Apple has worked with us on the issue and has since removed the affected apps.

      These potential backdoors could have been controlled remotely by loading JavaScript code from a remote server to perform the following actions on an iOS device:

      • Capture audio and screenshots
      • Monitor and upload device location
      • Read/delete/create/modify files in the app’s data container
      • Read/write/reset the app’s keychain (e.g., app password storage)
      • Post encrypted data to remote servers
      • Open URL schemes to identify and launch other apps installed on the device
      • “Side-load” non-App Store apps by prompting the user to click an “Install” button

      The offending ad library contained identifying data suggesting that it is a version of the mobiSage SDK [1]. We found 17 distinct versions of the potentially backdoored ad library: version codes 5.3.3 to 6.4.4. However, in the latest mobiSage SDK publicly released by adSage [2] – version 7.0.5 – the potential backdoors are not present. It is unclear whether the potentially backdoored versions of the ad library were released by adSage or if they were created and/or compromised by a malicious third party.

      As of November 4, we have identified 2,846 iOS apps containing the potentially backdoored versions of mobiSage SDK. Among these, we observed more than 900 attempts to contact an ad adSage server capable of delivering JavaScript code to control the backdoors. We notified Apple of the complete list of affected apps and technical details on October 21, 2015.

      While we have not observed the ad server deliver any malicious commands intended to trigger the most sensitive capabilities such as recording audio or stealing sensitive data, affected apps periodically contact the server to check for new JavaScript code. In the wrong hands, malicious JavaScript code that triggers the potential backdoors could be posted to eventually be downloaded and executed by affected apps.

      Technical Details

      As shown in Figure 1, the affected mobiSage library included two key components, separately implemented in Objective-C and JavaScript. The Objective-C component, which we refer to as msageCore, implements the underlying functionality of the potential backdoors and exposed interfaces to the JavaScript context through a WebView. The JavaScript component, which we refer to as msageJS, provides high-level execution logic and can trigger the potential backdoors by invoking the interfaces exposed by msageCore. Each component has its own separate version number.

      Figure 1: Key components of backdoored mobiSage SDK

      In the remainder of this section, we reveal internal details of msageCore, including its communication channel and high-risk interfaces. Then we describe how msageJS is launched and updated, and how it can trigger the backdoors.

      Backdoors in msageCore

      Communication channel

      MsageCore implements a general framework to communicate with msageJS via the ad library’s WebView. Commands and parameters are passed via specially crafted URLs in the format adsagejs://cmd&parameter. As shown in the reconstructed code fragment in Figure 2, msageCore fetches the command and parameters from the JavaScript context and inserts them in its command queue.

      Figure 2: Communication via URL loading in WebView

      To process a command in its queue, msageCore dispatches the command, along with its parameters, to a corresponding Objective-C class and method. Figure 3 shows portions of the reconstructed command dispatching code.

      Figure 3: Command dispatch in msageCore

      At-risk interfaces

      Each dispatched command ultimately arrives at an Objective-C class in msageCore. Table 1 shows a subset of msageCore classes and the corresponding interfaces that they expose.

      msageCore Class Name

      Interfaces

      MSageCoreUIManagerPlugin

      - captureAudio:

      - captureImage:

      - openMail:

      - openSMS:

      - openApp:

      - openInAppStore:

      - openCamera:

      - openImagePicker:

      - ...

      MSageCoreLocation

      - start:

      - stop:

      - setTimer:

      - returnLocationInfo:webViewId:

      - ...

      MSageCorePluginFileModule

       

      - createDir

      - deleteDir:

      - deleteFile:

      - createFile:

      - getFileContent:

      - ...

      MSageCoreKeyChain

      - writeKeyValue:

      - readValueByKey:

      - resetValueByKey:

      MSageCorePluginNetWork

      - sendHttpGet:

      - sendHttpPost:

      - sendHttpUpload:

      - ...

      MSageCoreEncryptPlugin

      - MD5Encrypt:

      - SHA1Encrypt:

      - AESEncrypt:

      - AESDecrypt:

      - DESEncrypt:

      - DESDecrypt:

      - XOREncrypt:

      - XORDecrypt:

      - RC4Encrypt:

      - RC4Decrypt

      - ...

      Table 1: Selected interfaces exposed by msageCore

      The selected interfaces reveal some of the key capabilities exposed by the potential backdoors in the library. They expose the potential ability to capture audio and screenshots while the affected app is in use, identify and launch other apps installed on the device, periodically monitor location, read and write files in the app’s data container, and read/write/reset “secure” keychain items stored by the app. Additionally, any data collected via these interfaces can be encrypted with various encryption schemes and uploaded to a remote server.

      Beyond the selected interfaces, the ad library potentially exposed users to additional risks by including logic to promote and install “enpublic” apps as shown in Figure 4. As we have highlighted in previous blogs [footnotes 3, 4, 5, 6, 7], enpublic apps can introduce additional security risks by using private APIs in certain versions of iOS. These private APIs potentially allow for background monitoring of SMS or phone calls, breaking the app sandbox, stealing email messages, and demolishing arbitrary app installations. Apple has addressed a number of issues related to enpublic apps that we have brought to their attention.

      Figure 4: Installing “enpublic” apps to bypass Apple App Store review

      We can see how this ad library functions by examining the implementations of some of the selected interfaces. Figure 5 shows reconstructed code snippets for capturing audio. Before storing recorded audio to a file audio_xxx.wav, the code retrieves two parameters from the command for recording duration and threshold.

      Figure 5: Capturing audio with duration and threshold

      Figure 6 shows a code snippet for initializing the app’s keychain before reading. The accessed keychain is in the kSecClassGenericPassword class, which is widely used by apps for storing secret credentials such as passwords.

      Figure 6: Reading the keychain in the kSecClassGenericPassword class

      Remote control in msageJS

      msageJS contains JavaScript code for communicating with a remote server and submitting commands to msageCore. The file layout of msageJS is shown in Figure 7. Inside sdkjs.js, we find a wrapper object called adsage and the JavaScript interface for command execution.

      Figure 7: The file layout of msageJS

      The command execution interface is constructed as follows:

                adsage.exec(className, methodName, argsList, onSuccess, onFailure);

      The className and methodName parameters correspond to classes and methods in msageCore. The argsList parameter can be either a list or dict, and the exact types and values can be determined by reversing the methods in msageCore. The final two parameters are function callbacks invoked when the method exits. For example, the following invocation starts audio capture:

      adsage.exec("MSageCoreUIManager", "captureAudio", ["Hey", 10, 40],  onSuccess, onFailure);

      Note that the files comprising msageJS cannot be found by simply listing the files in an affected app’s IPA. The files themselves are zipped and encoded in Base64 in the data section of the ad library binary. After an affected app is launched, msageCore first decodes the string and extracts msageJS to the app’s data container, setting index.html shown in Figure 7 as the landing page in the ad library WebView to launch msageJS.

      Figure 8: Base64 encoded JavaScript component in Zip format

      When msageJS is launched, it sends a POST request to hxxp://entry.adsage.com/d/ to check for updates. The server responds with information about the latest msageJS version, including a download URL, as shown in Figure 9.

      Figure 9: Server response to msageJS update request via HTTP POST

      Enterprise Protection

      To ensure the protection of our customers, FireEye has deployed detection rules in its Network Security (NX) and Mobile Threat Prevention (MTP) products to identify the affected apps and their network activities.

      For FireEye NX customers, alerts will be generated if an employee uses an infected app while their iOS device is connected to the corporate network. FireEye MTP management customers have full visibility into high-risk apps installed on mobile devices in their deployment base. End users will receive on-device notifications of the risky app and IT administrators receive email alerts.

      Conclusion

      In this blog, we described an ad library that affected thousands of iOS apps with potential backdoor functionality. We revealed the internals of backdoors which could be used to trigger audio recording, capture screenshots, prompt the user to side-load other high-risk apps, and read sensitive data from the app’s keychain, among other dubious capabilities. We also showed how these potential backdoors in ad libraries could be controlled remotely by JavaScript code should their ad servers fall under malicious actors’ control.

      [2] http://www.adsage.cn/
      [3] https://www.fireeye.com/blog/threat-research/2015/08/ios_masque_attackwe.html
      [4] https://www.fireeye.com/blog/threat-research/2015/02/ios_masque_attackre.html
      [5] https://www.fireeye.com/blog/threat-research/2014/11/masque-attack-all-your-ios-apps-belong-to-us.html
      [6] https://www.fireeye.com/blog/threat-research/2015/06/three_new_masqueatt.html
      [7] https://www.virusbtn.com/virusbulletin/archive/2014/11/vb201411-Apple-without-shell

      Memoryze for the Mac: Support Added for OS X Mountain Lion (10.8)

      Earlier this year, Mandiant launched a new freeware tool: Memoryze for the Mac™. The tool brings many of the features of Memoryze to the Apple® Macintosh platform, enabling acquisition of memory images via the command-line or a simple GUI. We are excited to announce it now fully supports OS X 10.6-10.8.

      Recently, OS X Mountain Lion added kernel Address Space Layout Randomization. It is a welcome security feature, raising the bar for kernel exploitation. This feature adds an extra step into the memory analysis tool. Previously, we could depend on the paging table IdlePML4 and IdlePDPT addresses being at the same physical memory location. With 10.8 and KASLR the physical memory addresses of IdlePML4 and IdlePDPT became BootPML4 and BootPDPT, while IdlePML4 and IdlePDPT are now randomized with ASLR. The boot paging tables do not contain the full kernel virtual memory layout. Since Memoryze for Mac does not depend on any symbol information, we developed a mechanism to uniformly discover the randomized location of the kernel paging tables.

      Once again, Mountain Lion has changed the memory location of nsysent. Prior to the change, it was located directly after the sysent table itself. As documented in several locations on the web, this made automated discovery and verification of the table size convenient. Unfortunately, Apple decided to move the location of nsysent, causing us to develop a new sysent size discovery mechanism.

      We have a growing list of cool new features to add to Memoryze for Mac, but it may be until after the new year before we are able to dev the features.

      Unibody Memory Analysis — Introducing Memoryze™ for the Mac 1.0

      Today, Mandiant is introducing a new free tool, Memoryze™ for the Mac 1.0, which brings memory imaging and analysis to the Mac. It joins a growing list of freeware tools Mandiant currently provides.

      Memoryze™ for the Mac 1.0 brings many of the features of Memoryze to the Apple Macintosh platform. This new tool enables acquisition of memory images via the command-line or a simple GUI. In addition, Memoryze™ for the Mac 1.0 can perform offline analysis against memory images or live analysis on a running system.

      The tool supports the following features:

      • Imaging the full range of system memory
      • Acquiring individual processes memory regions
      • Enumerating all running processes
        • Including those hidden by rootkits

      For each process, Memoryze™ for the Mac 1.0 can:

      • Report all open file handles in a process (e.g. all files,sockets, pipes, etc.)
      • List the virtual address space of a process including loaded libraries and allocated portions of heap and execution stack
      • List network connections
        • Active and listening
      • Enumerate
        • All loaded kernel extensions including those hidden by rootkits
        • The System Call Table and Mach Trap Table
        • All running Mach Tasks

      Okay, enough of the marketing. Memoryze™ for the Mac 1.0 can be downloaded here. To help get you started we'll present a few of the features in this blog post.

      For offline analysis your first step is going to be acquiring memory. The Mac Memory Dumper App makes this process as simple as pushing a button. To begin the acquisition, Memoryze™ for the Mac 1.0 will require you to authenticate so that the application can load a memory dumping driver. After selecting the location to store the image and authenticating, Memoryze™ for the Mac 1.0 will begin the acquisition process. The tool will provide you with a progress bar and an image size monitor for each of your acquisitions (fancy, huh?).

      Note that the final size of the dumped image may exceed the size of your physical RAM. If the system has 8GB of physical RAM installed the dump may be 10GB. You may ask yourself, "Self, why is the dumped image bigger than my actual memory size?" There are regions that are physically addressable but are not part of actual DRAM, pesky memory-mapped devices. These regions are written to the image file as 0x0-bytes to help preserve the correct offsets within the image.

      Once Memoryze™ for the Mac 1.0 finishes the acquisition; we can use it to perform memory analysis(note Memoryze™ for the Mac 1.0 can also perform analysis on images acquired by other tools). With our data ready, let's run through several of the process analysis features we mentioned above.

      We'll start by performing a basic process listing based on the memory image we just created. Execute the command below:

      macmemoryze proclist -f ~/Documents/my.mem 2>err.txt

      Memoryze™ for the Mac 1.0 will open "my.mem" for analysis and detect two critical pieces of information about the image: the operating system version and whether the system is running 32 or 64-bit kernel. Armed with this information the proclist analysis module locates the operating system data structure that maintains the list of running processes.

      If you take a look at the output below, you can see that Memoryze™ for the Mac 1.0 extracts the PADDR, or physical address, of each process (this is also the offset of the process in the acquired memory image file). You can use the PADDR to quickly locate the process in question in an offline tool such as a hex editor. Memoryze™ for the Mac 1.0 also extracts other standard identifying information such as the process NAME, PID and parent PID (PPID). In addition, the tool provides the start time for each process in UTC. Finally, Memoryze™ for the Mac 1.0 extracts each process' associated USERNAME, effective userid (EUID), and real userid (RUID).

      Based on the process listing above, we may be interested in getting a more complete understanding of what a particular process may be doing. We can list file descriptors and memory sections for all of the processes in the listing, but this would get pretty lengthy and present too much information at once. Using filters we can limit display to a smaller subset or a single process. We can use the "-n" option to filter processes by NAME or the "-p" to filter processes by PID.Execute the following command:

      macmemoryze proclist -w -p 14 ~/Documents/my.mem 2>err.txt

      In the image above, we show a snippet of a file descriptor listing for PID 14 using the command-line switch "-p 14". This shows us all open file descriptors for the given process. This includes files, UNIX domain sockets, networking sockets (such as TCP), and so on. For several of the types/subtypes, Memoryze™ for the Mac 1.0 will provide a value associated with the item type. The value for a descriptor of type FILE is the filename associated with the file descriptor while the value for a type SOCKET subtype TCP is the source IP address, destination IP address, and associated ports.

      Now that we've completed some filtering, let's dig a little deeper and perform detailed analysis of the "notifyd" process. The image below contains a snippet of its memory sections listing. Memoryze™ for the Mac 1.0 shows us the start and end virtual addresses and a human-readable size for each section. For some memory sections, Memoryze™ for the Mac 1.0 also provides a type, such as MALLOC or IOKIT. These types provide insight into the purpose of the memory section. For other memory sections, Memoryze™ for the Mac 1.0 displays the filename that is located at (or was used to initialize) that particular memory region. Please execute:

      macmemoryze proclist -s -p 14 ~/Documents/my.mem 2>err.txt

      Neat, huh? So now we've analyzed the standard operating system (OS) process list structure. If it's good enough for the OS, it's good enough for us, right? Not really. It's fairly trivial for malware to unlink itself from the process list that the OS maintains. In light of this, Memoryze™ for the Mac 1.0 provides a process carving feature that allows it to enumerate and analyze processes based on their signature in memory. This means that Memoryze™ for the Mac 1.0 does not have to depend on the OS to provide a list of processes. This enables Memoryze™ for the Mac 1.0 to discover processes that have been hidden from standard OS listings. This same carving feature extends to the kextlist and syscalllist Memoryze™ for the Mac 1.0 features, allowing you to discover other hidden data within the OS.

      Now don't forget, Memoryze™ for the Mac 1.0 can be run offline using an acquired memory image, or live, analyzing the running system in real-time. Below we show a system call table listing using the live memory analysis feature of Memoryze™ for the Mac 1.0. Notice the missing "-f" option. We can use this listing to check for system call table hooking. System call table hooking allows attackers to surreptitiously monitor or filter user-level programs interactions with the OS kernel. This is commonly used to hide files and network connections from user-level programs. The syscalllist feature also supports discovery and listing of the Mach Trap table. Mach Trap, what? The mach trap table is analogous to the system call table in the BSD portion of OS X, but within the Mach portion of OS X. So we want to ensure we can check for possible hooking within that table also. To perform a live listing execute:

      sudo macmemoryze syscalllist -s

      In order to hook the syscall table we would probably want to use a driver. Have no fear! Memoryze™ for the Mac 1.0 can carve loaded kexts from memory. A decent malware author would probably want to hide itself from the OS by unlinking from internal data structures. To combat this, Memoryze™ for the Mac 1.0 will parse live memory or a dead file to find loaded drivers, as shown in the screenshot below.

      Memoryze™ for the Mac 1.0 supports an XML output option ("-x") that will create an XML file with an extended version of the console output, only in XML format. "Extended version," you ask? There is only so much console real estate. We must make decision about what information to display. So therefore, stuff gets left out. For example, we parse the full file path of the executing process and the process arguments. These are not displayed in the console output, but are accessible if using the XML output option. These XML files can also be loaded into Mandiant Redline™ (currently windows only, boo!) for viewing in a GUI.

      There are other features of Memoryze™ for the Mac 1.0 that we have not detailed here, but we don't want to give you all the answers. What's the fun in that? We really want you to use the tool and provide us with some feedback on features, interface, usages, and so on.

      Memoryze™ for the Mac 1.0 currently supports:

      • Mac OS X Snow Leopard (10.6) 32/64-bit
      • Mac OS X Lion (10.7) 32/64-bit

      We hope to continue to improve the state of Mac memory analysis for incident responders and security professionals.

      "Mac" is a trademark of The Apple Corporation. Mandiant is not affiliated with or endorsed by The Apple Corporation.