Russian Hackers Target VMware Vulnerability, NSA Warns

 Russian cyber actors are exploiting a vulnerability in VMware Access and Identity Manager products to access protected data on affected systems, according to a National 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.

Operation Falcon: Group-IB helps INTERPOL identify Nigerian BEC cybercrime ring members

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.

reference: https://www.interpol.int/en/News-and-Events/News/2020/Three-arrested-as-INTERPOL-Group-IB-and-the-Nigeria-Police-Force-disrupt-prolific-cybercrime-group

"Group-IB is one of Tactical Intelligence Security's strategic partners.

If you want to know more about how Group-IB's solution can help your Business

contact us +233-574-55-09-79 info@taise.tech"

Experts: Don't reboot your computer after you've been infected with ransomware

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.

Source: ZDNet

Sleeping with the Friend-Enemy: Mobile Apps and their SDKs

Third party SDKs can undermine the security of your mobile app, 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 source SDK 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, TLS sessions, 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:

1. Access to the entire app *and* all its data
   1. SDKs can read, write, or delete any data located in private storage
2. Access to the app’s TLS layer
   1. SDKs can disable TLS for the entire app (to all endpoints, not just the SDK’s)
3. Access to the parent’s app’s existing permission
   1. SDKs can pull data from the device, including end-user
      1. Contact Lists
      2. Geo-Location
      3. SMS Logs
      4. Photos
      5. Camera
      6. Microphone
      7. [any device permission the parent app has been granted]
4. 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.

• Can you name the security flaw and privacy gap from the feature list above?

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). SQL Injection 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:

• Kochava SDK (Android)
  • Issue: Disables TLS Certificate Validation on the entire app and its connections
  • Source: Data Theorem, Inc.
• Silverpush
  • Issue: Tracks user habits without the user knowledge or permission
  • Source: Federal Trade Commission
• VPon
  • 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:

• https://itunes.apple.com/us/genre/ios/id36?mt=8
• https://play.google.com/store/apps
• Okay, so the sky is falling, right?

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:

1. Visibility is critical
   1. Enumerate the commercial SDKs and open source libraries in your app. This will remove the blind spot(s):
      1. Developers usually have a list of the SDKs somewhere, but not necessarily in a consolidated format
      2. Data Theorem provides real-time visibility for your mobile apps and it's 3rd-Party SDKs for free
2. Continuous testing
   1. Each commercial SDK and/or open source library, and each version of it, needs to be evaluated for the following items:
      1. What data, if any, does the SDK pull from the app?
      2. What security issues, if any, does the SDK introduce to the app?
      3. If the SDK is commercial…
         1. What are the privacy terms of the SDK?
         2. What security audits have been performed?
      4. If the library is open source…
         1. Who has reviewed the code for security flaws?

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).

By: Data Theorem courtesy of Peerlyst