Russian cyber actors are exploiting a vulnerability inVMwareAccess and Identity Manager products to access protected data on affected systems, according to aNational Security Agency(NSA) security advisory released this week.
The VMware vulnerability affects the following products:
Workspace One Access
Access Connector
Identity Manager
Identity Manager Connector
To exploit the VMware vulnerability, cyber actors must have access to a device’s management interface, NSA indicated. They can then forge security assertion markup language (SAML) credentials to request access to protected data.
How to Guard Against the VMware Vulnerability
NSA is urging National Security System (NSS), Department of Defense (DoD), and Defense Industrial Base (DIB) system administrators to apply vendor-provided patches to affected VMware products as soon as possible. It offers the following recommendations to guard against the VMware vulnerability:
Understand the Vulnerability: The VMware vulnerability requires password-based access to a web interface and allows cybercriminals to execute Linux commands. As such, system administrators should leverage multi-factor authentication (MFA) and other appropriate security measures to minimize the threat’s impact.
Understand the Relevance: The VMware vulnerability enables cybercriminals to target customer and partner networks. Therefore, system administrators should identify any networks that could be affected by the vulnerability.
Prioritize the Response: System administrators must identify which data can be accessed via vulnerable VMware products, assess the risk associated with data that cybercriminals could access and patch vulnerable products accordingly.
In addition, system administrators should review server logs and check and update service configurations to mitigate the VMware vulnerability, NSA stated. They also can leverage MFA for security credential services as needed.
State-sponsored hackers have attackedFireEyeand stolen the cybersecurity company’s Red Team penetration testing and assessment tools, FireEyedisclosed in an SEC filingon December 8, 2020. FireEye is concerned the hackers will potentially use the stolen Red Team penetration testing tools to attack additional companies. As a precaution, the company is sharing countermeasures to help potential targets mitigate attacks.
Among the key FireEye disclosures in the SEC filing:
1. State Sponsored Actor?: The attacker was a “highly sophisticated cyber threat actor” whose “discipline, operational security, and techniques lead us to believe it was a state-sponsored attack.” CEO Kevin Mandia believes the atack involves a “nation with top-tier offensive capabilities.”
2. FireEye Tools Were the Specific Target: This attack specifically targeted FireEye, and used methods that “counter security tools and forensic examination.” Hackers attacked “used a novel combination of techniques not witnessed by us or our partners in the past.” The attacker targeted and accessed certain Red Team assessment tools that FireEye uses to test our customers’ security.
3. FBI, Microsoft Assist Investigation: FireEye is investigating the attack in coordination with the Federal Bureau of Investigation and other key partners, including Microsoft.
4. Defending Against the Red Team Tools: FireEye is proactively “releasing methods and means to detect the use of our stolen Red Team tools.” The company doesn’t know if the attacker intends to use the Red Team tools or to publicly disclose them. FireEye has developed more than 300 countermeasures for customers and the community at large to use in order to minimize the potential impact of the theft of these tools.
5. No Additional Attacks So Far: FireEye has seen no evidence to date that any attacker has used the stolen Red Team tools, but continues to monitor for their use.
6. Customer Information Targeted, But Not Stolen: The attacker primarily sought information related to certain government customers. While the attacker was able to access some of FireEye’s internal systems, there’s no evidence (so far) that the attacker exfiltrated data from the company’s customer information, incident response or consulting engagements or the metadata collected by products in the dynamic threat intelligence systems. FireEye plans to contact customers directly if it discovers any information was detected.
A global threat hunting and intelligence firm, Group-IB, sponsored an INTERPOL-led Falcon operation targeting Nigeria's business email compromise (BEC) cybercrime gang, dubbed TMT by Group-IB. The arrest of three people in Lagos culminated in a cross-border anti-cybercrime effort involving INTERPOL's Cybercrime Directorate, the Nigerian Police Force, and the APAC Cyber Investigations Team of Group IB. The prolific gang has infiltrated at least 500,000 government and private sector enterprises in more than 150 nations since at least 2017. As some of the gang members remain at large, the investigation continues.
A type of email phishing attack that relies on social engineering is Business Email Compromise (BEC). Phishing emails may be targeted at specific individuals with an entity as part of BEC or sent out en masse. They attempt to steal confidential data, frequently disguised as money transfer requests, HR messages or business proposals.
With the support of Group-IB Cyber Investigations and CERT-GIB teams, the three BEC gang members with the initials «OC» (32 y.o.), «IO» (34 y.o.), and «OI» (35 y.o.) were arrested in Lagos not long ago as part of the Falcon operation by the Nigerian cybercrime police unit. According to the Nigerian Police, the data found on the computers of the arrested TMT members verified their role in the criminal scheme and reported stolen data from at least 50,000 targeted victims.
Pic. 1 Photograph courtesy of INTEPROL
Since 2019, Group-IB has been monitoring the gang and identified that TMT gang members may have compromised about 500,000 government and private sector businesses. Group-IB was also able to determine that the gang is split into subgroups with a number of individuals still at large based on the infrastructure that the attackers use and their techniques. The results of other alleged gang members that Group-IB was able to track were shared with the Cybercrime Directorate of INTERPOL. The inquiry continues.
The study of their activities showed that the gang focuses on mass email phishing campaigns spreading common strains of malware under the pretext of buying orders, product inquiries, and even COVID-19 help impersonating legitimate businesses:
Fig. 1 Sample of the TMT’s phishing email
The attackers send out phishing emails using Gammadyne Mailer and Turbo-Mailer. MailChimp is used to monitor whether the message has been opened by a receiving victim.
Fig. 2 Gammadyne Mailer used by cybercriminals
The gang was also seen using earlier compromised email account to push a new round of phishing attempts. The discovered email samples, detected and analyzed by Group-IB Threat Hunting Framework, were crafted in English, Russian, Spanish, and other languages, depending on the scammers target list.
Fig. 3 The example of the compromised data from the cybercriminals’ logs
Researchers from Group-IB note that the cybercriminals behind these BEC activities rely solely on a range of publicly accessible spyware and remote access (RAT) trojans, such as AgentTesla, Loky, AzoRult, Pony, NetWire, etc. The gang uses public crypters to prevent detection and monitoring by conventional security techniques. TMT-operated malware most frequently interacts with the C&C server of the attackers using SMTP, FTP and HTTP protocols.
The objective of their attacks is to steal browser, email, and FTP clients' authentication data. According to Group-IB info, the gang has managed to infect organizations around the world, including in the US the UK, Singapore, Japan, and even back home in Nigeria over the course of their operations. Although this gang's monetization tactics are still being investigated, selling account access as well as confidential data collected from emails to the highest bidder in the underground markets is not unusual for cybercriminals.
Craig Jones, INTERPOL’s Cybercrime Director highlighted the outstanding cooperation between all those involved in the investigation and underlined the importance of public-private relationships in disrupting virtual crimes.
Visa's payment fraud disruption team is warning of a recently uncovered digital skimmer called "Baka" that is stealing payment card data from e-commerce sites while hiding from security tools.
Researchers discovered the malicious code while examining a command-and-control infrastructure that previously hosted the ImageID skimmer.
Although Baka functions similarly to other JavaScript skimmers, the Visa fraud team found that this malicious code is able to load dynamically into e-commerce sites and then hide from security tools using obfuscation techniques, according to the Visa alert.
The Baka skimmer has been found in "several merchant websites across multiple global regions," the alert notes, but it does not provide further details.
"The most compelling components of this kit are the unique loader and obfuscation method," the Visa alert notes. "The skimmer loads dynamically to avoid static malware scanners and uses unique encryption parameters for each victim to obfuscate the malicious code. ... This skimmer variant avoids detection and analysis by removing itself from memory when it detects the possibility of dynamic analysis with developer tools or when data has been successfully exfiltrated."
How Baka Works
The Visa alert does not indicate how Baka is initially delivered to a network. But the report notes that the malicious code is hosted on several suspicious domains, including: jquery-cycle[.]com, b-metric[.]com, apienclave[.]com, quicdn[.]com, apisquere[.]com, ordercheck[.]online and pridecdn[.]com.
Once the initial infection takes hold, the skimmer is uploaded through the command-and-control server, but the code loads in memory. This means the malware is never present on the targeted e-commerce firm's server or saved to another device, helping it to avoid detection, according to the alert.
"The skimming payload decrypts to JavaScript written to resemble code that would be used to render pages dynamically," according to Visa.
Once embedded in an e-commerce site's checkout page, the skimmer begins to collect payment and other customer data from various fields and sends the information to the fraudsters' command-and-control server, Visa notes.
Once data exfiltration is complete, Baka performs a "clean-up" function that removes the skimming code from the checkout page, according to the alert. This also helps ensure that JavaScript is not spotted by anti-malware tools.
Visa's analysts found that the operators behind Baka use an XOR cipher as a way to obscure the malicious code and further hide it from detection, according to the alert.
"While the use of an XOR cipher is not new, this is the first time Visa has observed its use in JavaScript skimming malware," according to the alert.
Mitigating risks
The Visa alert advises e-commerce merchants to take several steps to mitigate skimming risks, including:
Run regular checks to determine if any code is attempting to communicate with a known command-and-control server;
Check code added through a service provider;
Vet content delivery networks and other third parties that have access to the checkout function;
Update and patch any software or services used on checkout sites and consider adding a firewall;
Limit access to online administrative portals and ensure that those with access use strong passwords.
Other Skimming Attacks
In November 2019, Visa researchers uncovered another type of skimmer called Pipka that had the ability to remove itself from the HTML of a compromised payment website after it executed, enabling it to avoid security detection (see: New JavaScript Skimmer Found on E-Commerce Sites).
Other security researchers have more recently warned about ongoing attacks against e-commerce websites using malicious JavaScript to steal payment card data.
For example, in August, security firm Group-IB warned of a cybercriminal gang called "UltraRank" that is using malicious code to skim payment card data and then selling that information to others on its own underground site (see: 'UltraRank' Gang Sells Card Data It Steals).
The alleged Twitter hacker has been arrested, The Wall Street Journal reports. Graham Ivan Clark, of Tampa, was arrested and charged as an adult on July 31, 2020. Clark faces 30 felony charges related to the hack, the report says.
The Twitter hack affected multiple celebrity and public official accounts, and tricked users into sending bitcoin to hackers. The Twitter attack raises serious economic, financial, political and national security concerns ahead of the 2020 U.S. Presidential Election.
How was Twitter security breached, who got hacked and what steps will the social media company take to further strengthen its platform? Here’s a regularly updated blog tracking the incident, Twitter’s investigation and corrective measures, and the high-stakes effort to keep social media secure.
Note: Blog originally published on July 16, 2020. Updated regularly thereafter with the latest investigation news.
Twitter Statements About Security Incident
In a July 18, 2020 statement about the security incident, Twitter indicated:
attackers targeted certain Twitter employees through a social engineering scheme.
The attackers successfully manipulated a small number of employees and used their credentials to access Twitter’s internal systems, including getting through two-factor protections.
130 Twitter accounts were targeted.
For 45 of those accounts, the attackers were able to initiate a password reset, login to the account, and send Tweets.
For up to eight of the Twitter accounts involved, the attackers took the additional step of downloading the account’s information through our “Your Twitter Data” tool.
Twitter’s incident response team secured and revoked access to internal systems to prevent the attackers from further accessing the systems and the individual accounts.
For the 130 accounts that were targeted, attackers were not able to view previous account passwords, as those are not stored in plain text or available through the tools used in the attack. Attackers were able to view personal information including email addresses and phone numbers, which are displayed to some users of our internal support tools. In cases where an account was taken over by the attacker, they may have been able to view additional information. Our forensic investigation of these activities is still ongoing.
More Twitter Breach Investigation Updates:
Twitter said hackers who breached its systems likely read the direct messages of 36 accounts, including one belonging to an elected official in the Netherlands. Source: Reuters, July 22, 2020.
More than a thousand Twitter employees and contractors as of early 2020 had access to internal tools that could change user account settings and hand control to others, making it hard to defend against the hacking that occurred in mid-July. Source: Reuters, July 23, 2020.
The breach involved hackers using phone-based spear phishing. Essentially, hackers gained entry to Twitter’s network by reaching out to Twitter employees on their phones. Source: Twitter, July 30, 2020.
Twitter emphasized that the investigation is ongoing, and the details above could change.
Twitter Hacked: Information About the Breach
Note: Information below published on MSSP Alert on July 16, 2020 through July 17, 2020.
How Did Twitter Get Hacked/Breached?: A hacker allegedly gained access to a Twitter “admin” tool on the social media network that allowed them to hijack high-profile Twitter accounts to spread a cryptocurrency scam. Source: TechCrunch, July 16, 2020.
Which Twitter Accounts Got Hijacked?: The accounts of U.S. presidential candidate Joe Biden, reality TV star Kim Kardashian, former U.S. President Barack Obama, Tesla and Space-X founder Elon Musk, and Microsoft co-founder Bill Gates were allegedly victimized. Source: Reuters, July 15, 2020.
How Many Twitter Accounts Were Victimized?: Hackers targeted about 130 accounts during the cyber attack this week. Twitter continues to assess whether the attackers were able to access private data of the targeted accounts. Source: Reuters, July 16, 2020.
What did Twitter Initially Say About the Security Incident?: Twitter’s security account posted around 5:45 p.m. EDT on July 15, 2020 that the company was investigating the incident and taking steps to rectify it. Within roughly a half hour, the company took the extraordinary step of limiting posts from verified accounts with blue check marks, which Twitter generally designates for more prominent users. Twitter, late July 15, said it believed the hackers perpetrated the attack by targeting employees who had access to the company’s internal systems and tools. The hackers may have accessed information or engaged in other malicious activity, Twitter said, adding it was still investigating the incident. The company didn’t say how long the hackers had been able to access its internal systems. Twitter said it had limited access to internal systems in response to the hack and locked compromised accounts. Source: The Wall Street Journal, July 15, 2020.
How is the U.S. Government Investigating the Twitter Hack?: The FBI’s San Francisco office has launched an investigation into the incident. Source: Reuters, July 16, 2020.
Twitter Hacked: The Bigger Concerns
Why Should MSSPs Care?: At first, there was concern that Twitter hackers may have bypassed two-factor authentication (2FA) security settings. But now, the concern has shifted to how hackers allegedly gained control of Twitter’s administration tool(s). Similarly, MSSP administration tools — including remote control and remote access software — have been popular hacker targets for infiltrating end-customer systems.
Why Are Regulators Concerned?: The Twitter breach raises serious questions and concerns — especially ahead of the 2020 U.S. Presidential Election. Hackers who gain control of social media administration tools can, in theory, spread misinformation that potentially manipulates financial markets, elections, international relations, protests, and overall confidence in political systems.
This remains a developing story. Check back for ongoing updates about the breach.
The vulnerability is one of 39 affecting various aspects of the mobile OS that the company fixed in a security update this week.
Google has patched a vulnerability in its Android OS that could allow attackers to completely take over someone’s device to install programs, steal or change data, or create new accounts with full privileges.
The flaw (CVE-2020-0103) was one of 39 vulnerabilities affecting Android OS builds that use older security profiles and are spread throughout various components of Android that the company fixed in its latest security patch, according to a security bulletin published Monday.
The vulnerabilities pose a high risk for consumers as well as business and government institution users, the company said. However, the most critical of these—found in the System component of Android–could allow for remote code execution (RCE), depending on the existing privileges on the device, according to Google.
“The most severe of these issues is a critical security vulnerability in the System component that could enable a remote attacker using a specially crafted transmission to execute arbitrary code within the context of a privileged process,” the company wrote in the bulletin.
However, the potential for exploitation depends on the privilege status of an application, according to the Center for Internet Security’s (CIS’s) advisory on the flaw.
“If this application has been configured to have fewer user rights on the system, exploitation of the most severe of these vulnerabilities could have less impact than if it was configured with administrative rights,” according to the post.
These vulnerabilities could be exploited through multiple methods such as email, web browsing and multimedia services (MMS) when processing media files, CIS explained in its post.
“Depending on the privileges associated with the application, an attacker could then install programs; view, change or delete data; or create new accounts with full user rights,” according to the post. However, so far none of the vulnerabilities patched in the update have been exploited in the wild, according to CIS.
The critical flaw was one of eight that Google patched for the System component of Android. The rest of the flaws were rated high-severity, except for one, which was rated moderate.
Google also patched a critical flaw in Android’s Framework component, CVE-2020-0096, that could enable a local attacker to execute arbitrary code within the context of a privileged process, the company said. The vulnerability was one of three patched in this component, the other two of which had a severity rating of high.
The only other critical vulnerability patched was a critical security vulnerability, CVE-2020-3641, found in the Qualcomm closed-source components. The flaw was one of 10 patched in these components, the rest of which were rated as high severity.
The security update also fixes four high-severity vulnerabilities in Android’s Media framework; eight high-severity vulnerabilities in Qualcomm components; four high-severity flaws in MediaTek components; and two high-severity vulnerabilities in Android Kernel components.
While the Android security platform and service protections such as Google Play Protect “reduce the likelihood that security vulnerabilities could be successfully exploited on Android,” Google recommended that Android users install the latest security patch just to be on the safe side.
Indeed, Google has historically struggled with the spread of malware via Android apps being downloaded from the Google Play store and has made a concerted effort in the last year and a half to try to stay on top of it.
Still, malware on the platform persists. Just last week researchers discovered a new Android mobile malware called EventBot that steals payment data from users of popular financial apps like PayPal, Barclays, CapitalOne and more.
A new bug on Whatsapp, based on MP4 videos flaws, has been revealed by Facebook. This vulnerability could lead to denial of service attacks or remote code execution. Facebook has revealed the existence of a serious vulnerability resulting a potential remote code execution attacks in Whatsapp messaging software. Last week, the tech giant said in a security advisory that the Whatsapp bug, known as CVE-2019-11931, is a stack-based buffer overflow issue that can be triggered by attackers sending .MP4 video files to the victims.
A stack-based buffer overflow could be triggered in WhatsApp by sending a specially crafted MP4 file to a WhatsApp user. The issue was present in parsing the elementary stream metadata of an MP4 file and could result in a DoS or RCE. This affects Android versions prior to 2.19.274, iOS versions prior to 2.19.100, Enterprise Client versions prior to 2.25.3, Business for Android versions prior to 2.19.104 and Business for iOS versions prior to 2.19.100.
Description
A stack-based buffer overflow could be triggered in WhatsApp by sending a specially crafted MP4 file to a WhatsApp user. The issue was present in parsing the elementary stream metadata of an MP4 file and could result in a DoS or RCE. This affects Android versions prior to 2.19.274, iOS versions prior to 2.19.100, Enterprise Client versions prior to 2.25.3, Windows Phone versions before and including 2.18.368, Business for Android versions prior to 2.19.104, and Business for iOS versions prior to 2.19.100.
Although there are not many technical details available, Facebook has presented this problem as being caused by the way the application parses MP4 elementary stream metadata. If exploited, the vulnerability can lead to denial of service (DoS) or remote code execution (RCE) attacks.
PROOF OF CONCEPT
In October, a Awakened a cybersecurity researcher discovered a free dual vulnerability, CVE-2019-11932, that could be used in attacks to compromise chat sessions, files, and messages. This double free vulnerability in the DDGifSlurp function in decoding.c in libpl_droidsonroids_gif before 1.2.15, as used in WhatsApp for Android before 2.19.244, allows remote attackers to execute arbitrary code or cause a denial of service.
When a WhatsApp user opens Gallery view in WhatsApp to send a media file, WhatsApp parses it with a native library called libpl_droidsonroids_gif.so to generate the preview of the GIF file. libpl_droidsonroids_gif.so is an open-source library with source codes available at Github.
A GIF file contains multiple encoded frames. To store the decoded frames, a buffer with name rasterBits is used. If all frames have the same size, rasterBits is re-used to store the decoded frames without re-allocation. However, rasterBits would be re-allocated if one of three conditions below is met:
Width height > originalWidth originalHeight
Width - originalWidth > 0
Height - originalHeight > 0
Re-allocation is a combination of free and malloc. If the size of the re-allocation is 0, it is simply a free. Let say we have a GIF file that contains 3 frames that have sizes of 100, 0 and 0.
After the first re-allocation, we have info->rasterBits buffer of size 100.
In the second re-allocation of 0, info->rasterBits buffer is freed.
In the third re-allocation of 0, info->rasterBits is freed again.
This results in a double-free vulnerability. The triggering location can be found in decoding.c:
Another set of interesting vulnerabilities in the email application was revealed by Check Point a month ago. The set of bugs "could allow the actors of the threat to intercept and manipulate messages sent in private and group conversations," said the researchers, and could be used as a weapon to exploit the functions of the "quote" group, answers and private messages. More information about this vulnerability can be found in the article (POC) wrote by Awakened.
A NECESSARY UPDATE
Users are advised to update their software versions to mitigate the risk of exploitation. However, there do not appear to be any reports of vulnerability exploited actively in the wild. Whatsapp is constantly working to improve the security of our service, said a Facebook spokesman. "We publish public reports on potential issues that we have resolved, in line with industry best practices, in which case there is no reason to believe that users have been affected," said the American giant.
Security experts don't recommend that users reboot their computers after suffering a ransomware infection, as this could help the malware in certain circumstances.
Instead, experts recommend that victims hibernate the computer, disconnect it from their network, and reach out to a professional IT support firm. Powering down the computer is also an alternative, but hibernating it is better because it saves a copy of the memory, where some shoddy ransomware strains may sometimes leaves copies of their encryption keys [1, 2].
Experts are recommending against PC reboots because a recent survey of 1,180 US adults who fell victim to ransomware in the past years has shown that almost 30% of victims chose to reboot their computers as a way to deal with the infection.
Image: Simoiu et al.
But while rebooting in safe mode is a good way of removing older screenlocker types of ransomware, it is not recommended when dealing with modern ransomware versions that encrypt files.
"Generally, the [ransomware] executable that actually encrypts your data is designed to crawl through attached, mapped and mounted drives to a given machine. Sometimes it trips, or is blocked by a permission issue and will stop encrypting," Bill Siegel, CEO & Co-Founder of Coveware, a company that provides ransomware data recovery services told ZDNet in an email this week.
"If you reboot the machine, it will start back up and try to finish the job," Siegel said.
"A partially encrypted machine is only partially encrypted due to some fortunate error or issue, so victims should take advantage and NOT let the malware finish its job...don't reboot!"
Siegel told ZDNet the advice applies to both enterprise and home users alike.
Further, ransomware victims should also take note that there are two stages of a ransomware recovery process they have to go through
The first is finding the ransomware's artifacts -- such as processes and boot persistence mechanisms -- and removing them from an infected host.
Second is restoring the data if a backup mechanism is available.
Siegel warns that when companies miss or skip on the first step, rebooting the computer often restarts the ransomware's process and ends up encrypting the recently-restored files, meaning victims will have to restart the data recovery process from scratch.
In the case of enterprises, this increases downtime and costs the company operating profits.
Third party SDKs can undermine the security of your mobileapp, all unbeknownst to you. Mobile applications, including iOS, Android, and WinMo apps, are built using native code usually written by developer teams; however, a chunk of the code is always sourced from 3rd party SDKs (commercial or open source). Leveraging external components is very normal for mobile apps, as 99% of all apps have some sort of 3rd-party commercial or open sourceSDK embedded in the binary. So what is the problem here? The big issue is that 3rd-party SDKs have FULL access to the app 's private data, permissions, network connections, TLSsessions, etc. There is no separation nor sandbox between the app’s internal code and the 3rd-party SDK. Once the SDK is included, the SDK *is* the app too, which includes all commercial for-profit SDKs and as well as the two-person developer projects on GitHub.
Okay, so yeah, what is the problem here?
The problem is that 3rd-party SDKs, an unvetted, uncontrolled, and unknown source, have:
Access to the entire app *and* all its data
SDKs can read, write, or delete any data located in private storage
Access to the app’s TLS layer
SDKs can disable TLS for the entire app (to all endpoints, not just the SDK’s)
Access to the parent’s app’s existing permission
SDKs can pull data from the device, including end-user
[any device permission the parent app has been granted]
Basically, the SDK has access to anything the app has access to
An Illustration of the Issue
Let’s take a quick look at MDLive, a popular medical app that connects doctors with end-users in need of medical assistance. MDLive has 10+ third party SDKs in its iOS mobile app, which is very normal. One of its SDKs is called TestFairy, a popular tool to help developers distribute apps to internal teams, collect logs, solicit user feedback, obtain crash reports, and record videos of end-user activity. These features help developers improve their mobile apps from one release to the next.
Well, it turns out the 3rd Party SDK (TestFairy) has an awesome "Video Recording" feature that has significant security and privacy implications. According to federal courts in the state Florida, the MDLive app was taking screenshots of real end-user activity, which includes all presented data, and sending it to a 3rd party (TestFairy). Well, what actually happened is that the TestFairy SDK was configured to collect screenshots of live user activity (it just looked like MDLive since there is no distinction from the App and its SDKs). Since the MDLive app leverages medical data, this equates to a 3rd party SDK receiving ePHI data of several thousand MDLive users (on another apps, the data could very well be credit card numbers, social security numbers, account balances, etc.).
So what went wrong here?
MDLive's mobile developers chose a SDK to improve their work flow, which is the right thing to do. Unfortunately, they enabled a feature from the SDK that collects end-user data from live app sessions. Did the security team know that TestFairy was being used? Did the security team know that TestFairy is collecting screenshots with live end-user data and sending it to TestFairy's headquarters, which happened to be in Israel? As a reminder, developer choose a variety of SDKs to enhance their app on an everyday basis, which is nothing new. The problem is that 1 of the 10+ SDKs had a significant security issue associated with it, which no one knew about until the federal courts got involved.
Okay, how does this issue compare to other attack classes, within mobile app security or other platforms? In our opinion, this attack surface is considerable, considering the amount of data that can be compromised. Let’s compare the major attack classes from client/server apps, web apps, and mobile apps altogether, which is shown below in Table 1.0. We will compare buffer overflows, SQL Injection, Cross-Site Scripting, and Mobile SDKs.
Table 1.0
As shown above, buffer overflows still rule the Win32 world; however, attacks on windows native apps are less common (and not as sexy anymore). SQLInjection still reigns strong for web apps, but notice SDKs actually have stronger impact on data than Cross-Site Scripting. While XSS and SDKs mirror each other in terms of the full control of data, developer sourced, and customer data, SDKs can gather large volumes of data with just one attack, where reflected XSS cannot (only persistent could). Furthermore, misbehaving SDKs are a bit harder to detect as several SDKs are legitimate, not evil at all. An enemy that looks like a friend is much harder to defend against than something known to be evil.
Okay, so what have we learned today?
SDKs are a major blind-spot for enterprise security teams, as the emerging attack surface can destroy a mobile app’s security model with behavior that developers perform everyday. While traditional app security teams focus on security flaws within the app, rightfully so, many of them are not aware of this attack surface at all. App security teams usually have 1) no idea which commercial/open source SDKs are bundled in the app 2) nor do they know which SDKs introduce security issues to the app.
More Real-world Examples
Okay, so where else is this happening?
Well, all over the place. To date, Data Theorem, Google, the FTC, and Fireeye have published most of the articles on this topic. A few examples are below:
Issue: Records audio, captures videos, collects geo-location & contacts
Source: Google, Inc.
iBackdoor(Not a legitimate SDK, but rather a purposely built library to steal data)
Issue: Collects audio, screenshots, geo-location, and accessed data in private storage/iOS keychain
Source: Fireeye, Inc.
Please note, these four SDKs are not exhaustive, just a small sample.
"What did the president know, and when did he know it"
A famous quote by Howard Baker in the middle of the Watergate scandal. Now that you know of this new class of issues, how do your apps rank? Data Theorem scans the App Store/Google Play on a daily basis, so if you have any concerns about your apps or their SDKs, please feel free to contact us and we’ll let you know either way free-of-charge. A full list of apps that have security or privacy issues sourced from a third party SDKs are listed below:
NO, the sky is not falling. Data Theorem has dynamically scanned over 10,000 SDKs and like everything else, 80% of them are just fine. 80/20 rule applies here too, where 20% of the SDKs cause 80% of the problems. Many of these SDKs introduce security issues by mistake, while others were purposely built to attack mobile apps and their data.
What’s next, what should I be doing?
There are a few next steps here:
Visibility is critical
Enumerate the commercial SDKs and open source libraries in your app. This will remove the blind spot(s):
Developers usually have a list of the SDKs somewhere, but not necessarily in a consolidated format
Data Theorem provides real-time visibility for your mobile apps and it's 3rd-Party SDKs for free
As you can see from the above, this is no easy task. Item number 2 is easy on paper, but hard to implement at-scale since it needs to be continuous and completed for every app’s release. Despite the challenge, it is something that must be done, as an absence of any action could very well lead to the compromise of large volumes of data (both consume or enterprise data).
