This blog post was written by Rick Simon.

At the RSA Conference 2016 in San Francisco, Chris Young, GM and SVP of McAfee, said that one of the best ways to improve response time to attacks and overall awareness of attacks and adversaries is through the timely sharing of threat intelligence. He also talked about McAfee’s responsibility as a leading security vendor to set an example for the industry by pushing the boundaries of threat intelligence sharing.

We believe that by sharing threat intelligence, we can shift the balance of power away from the adversaries and back to us, the defenders. By crowdsourcing threat data and leveraging collaborative analytics, we can “connect the dots” to form better pictures of the attacks and adversaries that surround our customers. Collectively, we can deliver better protection.

Leading by example, McAfee partnered with other leading cybersecurity solution providers in 2014 to form the Cyber Threat Alliance (CTA). CTA members share threat information, raising our situational awareness about advanced threats, including the motivations, tactics, and the actors behind them. Once shared, CTA members can automatically deploy prevention controls to stop the identified threats. Based on collaborative research, we also published a joint threat research report late last year around our collective analysis of the CryptoWall Version 3 campaign.

McAfee is also helping drive the development of voluntary standards for those who wish to establish threat intelligence sharing organizations. We lead several committees within the Information Sharing and Analysis Organization (ISAO) Standards Organization, established through a US Presidential order in 2015. The ISAO SO’s objective is to encourage threat information sharing within the private sector and between the private sector and government.

To gain a better understanding of threat intelligence sharing and McAfee’s leadership in driving its development, we recently created a web page that educates and shows how we use threat intelligence sharing to better protect our customers. You can visit the page here.

The post Improve Protection Against Cyberattacks Through Shared Threat Intelligence appeared first on McAfee Blogs.

This blog was written by Kunal Garg.

One of the best ways to develop secure Android applications is to engage in penetration (pen) testing, in effect trying to break into your application just as an attacker might do. This is the third in a series of posts on pen testing Android applications. In the first we set up the testing environment and captured traffic. In the second, we discussed some tools and proxy techniques—Drozer, Apktool, and a “man in the middle” proxy—that come in handy during a security review of Android applications.In this chapter, we’ll look at reviewing Android’s manifest file.

Every Android binary is packaged with the file Andoridmanifest.xml, which provides the system with necessary information such as permissions, intents, activities, services, broadcasts, etc. It also functions as a basic configuration file.

Access

You can obtain the manifest file by changing the Android binary extension from .apk to .zip. However, this change does not create a readable format. To convert manifest into readable format you can use Apktool to disassemble the Android binary. Once the binary is disassembled, the manifest file is readable. You can also use Manifest Explorer to view the manifest file.

Command:

Apktool d binarypath\binaryname

Here we see the manifest file for the test application Sieve:

You should review several elements in the manifest file.

1. Package name: The package name is the unique name of the application, with the application data generally present in the folder /data/data/packagename in the Android directory. While reviewing Packagename it is useful to identify and examine the application directory for any sensitive data.
2. Permissions: An application should not request unnecessary permissions. Only the permissions required by the application should be assigned. For example, if an application does not need access to GPS or the camera, then these permissions should not be requested.

android:protectionLevel defines the risks associated with permissions. If a permission is marked as dangerous, you should review this permission because it may grant control to the device or user data. Some permissions categorized as dangerous:

• Calendar
• Camera
• Contacts
• Location
• Microphone
• Phone
• Sensors
• SMS
• Storage

For detailed information on permissions refer to this link.

3. Exported components: This element provides the components of an application (provider, activity, service, or receiver) to be invoked by other application components.

If this value is set to true, other components can access this application’s components.

For example, if in a banking application a “view account statement activity” has exported a value set to true, a malicious application could invoke it. Thus this value should be set to false.

android:exported="false”

An example of the fourgoats application with the exported value set to true.

4. Android flags (debuggable, backup): The manifest file contains information about Android flags.

Android backup: Allows the application to participate in backup. This is not desirable in cases where the application has sensitive data and user data is at risk due to the backup.

Android debuggable: This flag indicates whether the Android application can be debugged. Once the application moves from test to production, the debug flag should be set to false. If this flag is set to true, any entity with access to the device can execute code under the application’s permissions, and can also obtain sensitive data from the application.

During the security review these flags should be set to false:

android:debuggable="false"

android:allowBackup="false”

5. API level

The attribute android:minSdkVersion defines the minimum API level required by the application to run on an emulator or device. If the device version is earlier than the minsdkversion, the application may not run on the device. No application should support obsolete versions. The latest API level is 24.

The post How to: Testing Android Application Security, Part 3 appeared first on McAfee Blogs.

This blog post was written by Rick Simon.

Data is leaking out of your organization: accidentally or intentionally, by internals or externals, physically or electronically. During the past year, we have performed extensive research to identify what data is being targeted, who is taking it, how they are getting it out, and the best practices to reduce your exposure to data loss.

We found that most organizations do not realize that they are leaking data. Between 50% and 80% of data breaches are discovered by outside entities, typically when the data is used or sold. According to the 2016 Verizon Data Breach Investigation Report, internal discovery of breaches has been on a downward trend for 10 years.

It should be no surprise that data thefts are usually about the money or that between 60% and 80% of them are conducted by external agents. However, that still means that 20% to 40% of data loss is the result of intentional or accidental actions by people on the inside. Physical media, such as USB keys and laptops, are the most common method of data loss from internals, but fewer than 40% of organizations surveyed are watching these devices closely enough to catch them.

Organizations with data loss prevention (DLP) systems should be well positioned to block data leakage, but many do not appear to be using the tools to their best advantage. Data loss is increasingly happening with unstructured data, such as office documents, yet many organizations do not monitor unstructured data. Relying solely on regular expressions, which is a common method to find things such as credit card or social security numbers, leaves too much valuable information unmonitored.

On average, the IT professionals we surveyed reported dealing with about 20 incidents per day, but there was a tremendous range. Small companies and those in the Asia-Pacific region tend to run below average, while large companies, especially those in financial services and retail, tend to run higher than average. Because false negatives, or data loss that does not trigger an incident alert, are one of the challenges with DLP systems, we found that configuring systems to watch more actions is an important part of reducing the likelihood of data loss.

On the positive side, we found that 85% of all organizations surveyed delivered regular security awareness training to keep the importance of data protection fresh in people’s minds. Teaching employees how to recognize the value of the data they are processing makes the issue real for their particular jobs. Automatic pop-ups that notify them when they are doing something potentially risky are a great reminder, and do not consume a lot of resources.

For more information on this research, download the McAfee Labs Threats Report: September 2016.

The post ‘McAfee Labs Threats Report’ Delves Into Dangers of Data Loss appeared first on McAfee Blogs.

This blog was written by Kunal Garg.

One of the best ways to develop secure Android applications is to engage in penetration (pen) testing, in effect trying to break into your application just as an attacker might do. This is the fourth in a series of posts on pen testing Android applications. In the first we set up the testing environment and captured traffic. In the second, we discussed some tools and proxy techniques—Drozer, Apktool, and a “man in the middle” proxy—that come in handy during a security review of Android applications. In the third, we looked at reviewing Android’s manifest file.

During pen testing of Android applications it is often necessary to modify the app’s source code to bypass SSL pinning, check for tampering protection, bypassing application logic, and other steps. In this article, we will cover the process to successfully modify the source code.

Tools required

• Download and set up Apktool
• Jarsigner
• JD-GUI

Step 1: Convert the code into Smali format

Set up Apktool and use the following command to disassemble the APK. We used the test application Sieve.

apktool d <your apk path here> -o <output path>

The disassembled APK folder contains the Smali files. These files can be modified using any text editor, as shown in the following screen:

You can also use JD-GUI (by converting classes.dex file into .jar format) to identify the class or methods you want to modify, and then to patch the corresponding Smali files.

Step 2: Repack the APK

After modifying the Smali code, you must repack the APK. Use the following command:

apktool b <deassembled apk path> -o <output apk path>

Android requires every APK to be signed. Any unsigned binary results in a passing error. Thus the next step is to create a key pair, and sign the APK with that.

Step 3: Create and sign the key

Keytool and Jarsigner come packaged in the Java Development Kit bundle and are required to complete this step. Use this command to generate the key:

keytool -genkey -v -keystore mykey.keystore -alias <Any alias name> -keyalg RSA -keysize 2048 -validity 10000

After you answer the series of questions that follow, a keyfile (mykey.keystore) is created in the C:\Users\<username> directory.

Once the key pair is created, the APK can be signed using the following command:

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore mykey.keystore <apk path> alias_name

After completing all the steps, the repacked APK can be successfully installed on the device.

In our next post we will focus on obtaining and analyzing the Android memory dump for sensitive information.

The post How to: Testing Android Application Security, Part 4 appeared first on McAfee Blogs.

This blog was written by Stanley Zhu.

The Windows kernel privilege escalation vulnerability CVE-2016-7255 has received a lot of media attention. On November’s Patch Tuesday, Microsoft released a fix for this vulnerability as part of bulletin MS16-135. CVE-2016-7255 was used to perform a targeted attack and a sample was found in the wild, according to Microsoft. Google and Microsoft have already confirmed the Russian hacker group APT28 used a Flash vulnerability (CVE-2016-7855) along with this kernel privilege escalation flaw to perform a targeted attack. Google has also discussed this vulnerability.

• https://security.googleblog.com/2016/10/disclosing-vulnerabilities-to-protect.html
• https://threatpost.com/microsoft-says-russian-apt-group-behind-zero-day-attacks/121722/
• http://securityaffairs.co/wordpress/53242/hacking/cve-2016-7255-zero-day.html

The vulnerability research team at McAfee Labs has spent a significant amount of time analyzing this vulnerability. In this post we will briefly discuss some of our findings.

We started our analysis with the patch of MS16-135, and very soon we noticed that MS16-135 updated win32k.sys on the target system. Our investigation continued with the comparison (via binary diffing) of the two win32k.sys files (before and after installing the patch). Our test system ran Windows 7 Version 6.1.7601.23584.

Looking at the binary diffing results, we noticed the following functions were modified.

Figure 1: The changed function xxxNextWindow in win32k.sys.

After some preliminary investigation we concluded the patch for CVE-2016-7255 was applied solely in the function xxxNextWindow in win32k.sys.

The following screenshot shows a very high-level overview of the changes made to xxxNextWindow(x,x):

Figure 2: High-level diffing results in the function xxxNextWindow.

We can see some new logic has been added (highlighted in red) to the middle of the patched function. Zooming into the first newly inserted basic block, we can see that the newly introduced code compares the value of eax+0x23.

Figure 3: The first inserted basic block in xxxNextWindow.

We see similar logic in next newly inserted basic block.

Figure 4: The second inserted basic block in xxxNextWindow.

Google has stated the vulnerability “can be triggered via the win32k.sys system call NtSetWindowLongPtr() for the index GWLP_ID on a window handle with GWL_STYLE set to WS_CHILD.”

In fact, NtSetWindowLongPtr only helps trigger this vulnerability, while the root cause lies in xxxNextWindow. More specifically, the inappropriate parameters set by NtSetWindowLongPtr can trigger an “arbitrary address write” scenario in xxxNextWindow.

Now let’s take a look at the decompiled version of the unpatched xxxNextWindow(x,x…).

Figure 5: The decompiled version of the unpatched xxxNextWindow.

After the patch is applied, xxxNextWindow (x,x…) looks like this：

Figure 6: The decompiled version of the patched xxxNextWindow.

The code after the patch has enhanced the parameter verification with the conditional branch statement “(*(_BYTE *)(v8 + 0x23) & 0xC0) != 0x40.”

In this new statement, variable v8 (in eax) is the return value of a previous GetNextQueueWindow call. (See following figure.)

Figure 7: Variable v8 comes from a call to GetNextQueueWindow: “v8 = _GetNextQueueWindow(v7, v31, 1);”

A quick look at the implementation of _GetNextQueueWindow(x,x,x,…) reveals that the function actually returns a pointer to the tagWND structure.

The following screen shows the tagWND structure in windbg:

Figure 8: The structure of tagWND.

Analyzing this code, we know the field at offset 0x78 in the tagWND structure is relevant to the vulnerability. The following lines of decompiled code from the unpatched function illustrate that the field at offset 0x78 is relevant to the vulnerability:

Figure 9: Problematic code in the unpatched xxxNextWindow.

Now the problem becomes simple: If we can control the value at v8+0x78, we will be able to write to an arbitrary address in kernel land, and this could potentially allow the elevation of privilege. Luckily, a user-mode API (NtSetWindowLongPtr) is available to set an arbitrary value in that position.

The following screen shot shows that the value (0x41414141) we passed to NtSetWindowLongPtr is reflected in the tagWND structure, making it easy to gain an arbitrary memory write through this vulnerability.

Figure 10: An arbitrary value is set in the tagWnd structure.

To to trigger the vulnerability, the WS_CHILD attribute of the newly created window must be assigned, and the GWLP_ID attribute must be set with the help of the API NtSetWindowLongPtr(). Moreover, the last hurdle is to trigger xxxNextWindow. After some research, we found we can trigger it by pressing a combination of Alt+Tab keys or simulating the key press with the keybd_event API.

Now that we understand the root cause of this vulnerability from the high level, let’s try reproducing the vulnerability. We will create a simple window and populate some values in its tagWND structure.

HWND hwnd = CreateWindowEx(0, L”TestWnd”, 0, WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CHILD, 5, 5, 1, 1, hWndParent, 0/*hMenu */, h, 0);

SetWindowLongPtr(hwnd, GWLP_ID,/*0xfffffff4=GWLP_ID*/ 0x41414141);

Figure 11: Debugging the vulnerable function xxxNextWindow.

The preceding screenshot shows the live debugging output. Here the ebx register is holding the pointer to the tagWND structure, and a write violation will occur very soon. As you can see in the following figure, the destination of the offending instruction is just the address (adding 0x14) that we previously passed in via the NtSetWindowLongPtr API, and this perfectly illustrates an arbitrary address write attack.

Figure 12: Scenario for an arbitrary address write attack.

Let’s return to Microsoft’s patch, which starts by checking the value at offset 0x23 of the tagWND structure. In the patched code, we can see the newly introduced statement

(*(_BYTE *)(v8 + 0x23) & 0xC0) != 0x40

When it comes to the patched version of the function, ebx points to the tagWND of the structure ebx + 0x23 = 0x54;

0x54 & 0xc0 = 0x40 ;(1)  ,  0x40 != 0x40 (2) ;

Now this statement becomes false. Therefore, the program skips the following code lines that attempt to modify memory, and avoids the program crash (the write access violation).

*(_DWORD *)(*(_DWORD *)(v30 + 0x78) + 0x14) &= 0xFFFFFFFB;

*(_DWORD *)(*(_DWORD *)(v8 + 0x78) + 0x14) |= 4u;

How can this vulnerability be exploited to achieve a privilege escalation? Instead of allowing the writing of an arbitrary value to an arbitrary address, this vulnerability can change only one bit; that is, the value on the address will be logically OR-ed with 0x04 (or its multiples) as shown below:

Value = Value | 0x04;

Value = Value | 0x0400;

Value = Value | 0x040000

Value = Value | 0x04000000

In this case, if the attacker can find a certain array of objects in kernel land and enlarge the index of the objects array (such as tagWnd->cbWndExtra) with this logical OR primitive to cause an out-of-bound access, the attacker will be able to gain arbitrary address read/write ability from user mode (by using some user mode APIs). We currently know some exploitation skills of this kind, such as GetBitmapbits/SetBitmapbits (first discovered by KeenTeam) or SetWindowText/GetWindowText.

Today, privilege escalation using a kernel mode vulnerability is still the primary vector to break application sandboxes (Internet Explorer’s EPM or Edge’s AppContainer). This path has been well demonstrated by most successful in-the-wild exploits targeting Internet Explorer/Edge/Adobe Reader and Flash that we have seen. Against current versions of Windows, with multilayer defenses, escaping the sandbox with a kernel escalation of privilege is still the attacker’s first choice. KeUsermodeCallback used to be a very popular type of Windows kernel mode vulnerability that can lead to kernel mode code execution, as we saw in CVE-2014-4113 and CVE-2015-0057. Microsoft’s work on addressing kernel vulnerabilities and adding more mitigation security features has led to a decline in this type of attack. In response, attackers have begun to look into kernel font and GDI vulnerabilities. Windows 10 has already restricted win32k calls in Edge, which significantly reduces the attack surface. And Microsoft has also fixed the kernel memory information disclosure issue that leverages the GDI-shared handle table. No doubt, kernel exploitation will become more and more difficult. However, we foresee that attackers will still use win32k as the main attack surface to exploit the kernel to achieve code execution or elevation of privilege. The battle will continue around this hot spot for both attackers and defenders. 

I thank my colleagues Bing Sun and Debasish Mandal for their help with this post.

The post Digging Into a Windows Kernel Privilege Escalation Vulnerability: CVE-2016-7255 appeared first on McAfee Blogs.

This blog post was written by Rick Simon.

The annual Verizon Data Breach Investigations Report (DBIR) was published today. Once again, it is a hefty report that is sure to become one of the most referenced data breach reports in the world.

That is because Verizon’s analysis is based on a broad set of real breach data collected from 65 law enforcement agencies, security product vendors, and security consulting firms. In fact, this year’s report analyzed more than 42,000 incidents and 1,900 confirmed breaches spanning 84 countries and 20 industries. Although the data set is neither comprehensive nor a random sample, it certainly looks at a large set of data and is very likely to be directionally accurate.

The report reconfirms many of the things we already know, but it also provides many “aha” moments. In the “what we already know” category, here are the main findings:

• 75% of the breaches in VERIS, Verizon’s incident database, were perpetrated by outsiders; 51% involved organized crime.
• A whopping 81% involved stolen or weak passwords.
• 73% of the breaches were financially motivated.
• 66% of malware was installed through malicious email attachments.
• Typical time-to-compromise continues to be measured in minutes, while time-to-discovery remains in weeks or months.
• Financial services firms are still the top dogs in confirmed breaches, with health care running second.
• In the manufacturing sector, cyber espionage is by far the most common type of incident; usually, this comes from competitors or nation-states trying to steal intellectual property.

In the “aha” category, the report reveals these interesting finding:

• Over a billion credential sets were stolen in 2016, more than three times greater than the previous high-water mark in 2013. In the McAfee Labs 2017 Threats Predictions report, we predicted increased credential theft activity, so we think this trend will continue.
• Social attacks were part of 43% of all breaches. Phishing is the most common social tactic (93% of social incidents). Almost all phishing attacks that led to a breach were followed with some form of malware.
• There was a disturbing rise in cyber espionage in the education sector, with state-affiliated actors most often the culprits; manufacturing and the public sector remain the most common targets for cyber espionage.
• Chip-and-pin (the EMV standard) use in the United States is still in its infancy (just 25% of ATMs are chip-and-pin ready, lower for other payment card terminals), so the impact of 2015’s chip-and-pin mandate still does not show up in the numbers.

McAfee coauthored the chapter on ransomware, highlighting ransomware technical advancements in 2016 and ways in which the security industry is fighting back. We also provided anonymized breach data, used by Verizon in their analysis throughout the report.

Here are some highlights from the ransomware chapter:

• Ransomware has moved up to the fifth most common form in this year’s data from the 22nd most common form of malware in 2013.
• The number of ransomware incidents increased to 229 in 2016 from 159 in 2015.
• The most significant change to ransomware in 2016 was the swing away from targeting individual consumer systems toward vulnerable organizations.
• Web drive-by’s were the number one attack vector in 2015, but were supplanted by email in 2016. Social actions, notably phishing, were found in 21% of incidents in 2016, up from just 8% in 2015.
• Public sector organizations were the number one industry target, with healthcare second, and financial services third.
• In 2016, attackers introduced master boot record locking and partial- and full-disk encryption in an effort to make it more difficult to recover systems without paying. They also experimented with a variety of methods to avoid detection by security sandboxes.
• Criminals began offering ransomware-as-a-service in 2016, enabling anyone to extort their favorite targets, while taking a cut of the action.

In the McAfee Labs 2017 Threats Predictions report, we postulated that ransomware will subside in the latter half of 2017. We believe this for several reasons:

• Security software will better protect and detect ransomware: Endpoint protection software can now detect millions of ransomware samples. Security vendors are also adding detection techniques such as sandboxes that can mimic a user environment to catch obfuscated ransomware, behavioral analysis to prevent ransomware from executing completely, and file-creation blocks to prevent ransomware from writing encrypted files.
• Vendors, law enforcement agencies, and other organizations will share more threat intelligence: Organizations of all sizes are increasingly sharing threat intelligence information to help detect ransomware before it reaches systems.
• Security vendors will increasingly work with law enforcement: Collaborating with law enforcement agencies will lead to the disruption of ransomware criminal enterprises.
• Ransomware will become less profitable: These efforts, coupled with free methods to decrypt locked systems without paying the ransom, will make it harder for criminals to make a buck. The most visible source for free decryption tools is the No More Ransom initiative, which now offers several dozen decryption tools.

The Verizon DBIR can be downloaded here. Information about ransomware can be found here.

The post ‘Aha’ Moments From the ‘Verizon 2017 Data Breach Investigations Report’ appeared first on McAfee Blogs.

This blog was written by Kunal Garg.

One of the best ways to develop secure Android applications is to engage in penetration (pen) testing, in effect trying to break into your application just as an attacker might do. This is the fifth in a series of posts on pen testing Android applications. In the first, we set up the testing environment and captured traffic. In the second, we discussed some tools and proxy techniques—Drozer, Apktool, and a “man in the middle” proxy—that come in handy during a security review of Android applications. In the third, we looked at reviewing Android’s manifest file. In the fourth, we covered the process to successfully modify the source code.

In this article, we will focus on capturing and analyzing the heap dump.

Android applications should not leak information such as passwords, social security numbers, or credit card numbers in the form of long-lived references or objects in memory. Data leakage via these references is a common occurrence and is categorized in the Open Web Application Security Project list Mobile Top 10 2016-M2-Insecure Data Storage.

While performing a pen test we must analyze the heap to identify and flag any sensitive information-leakage issues.

A heap dump is basically a snapshot of all the objects. We need to focus on the following:

• Long-lived references
• Caches holding objects
• Objects holding references

Obtaining the heap dump

Open the Android Device Monitor using the command “monitor” from the tools directory of the Android software development kit (SDK). Next select the application package, click “Dump HPROF file,” and save the file. (HPROF stands for heap/CPU profiling.)

This heap dump is not identical to the one obtained from the Java HPROF tool. This needs to be converted into Java SE HPROF format, which you can accomplish using the HPROF-conv utility located in the platform tools directory of the Android SDK.

Converting the HPROF file

Use this command to make the conversion:

HPROF-conf <input file> <output file>

Analyzing the heap dump

You can employ the Eclipse Memory Analyzer, for example, to analyze the heap dump.

• Open the converted HPROF file using the memory analyzer.
• Click on “open dominator tree for entire heap” and search for the application package, for example, com.mwr.example.Sieve.
• Search the objects for any sensitive information entered in the application.

We entered password Test@1234123 in the sieve application and found the same in clear text among the objects in the heap dump.

Recommendations

Your best practice is to nullify objects that contain any sensitive information.

References

https://developer.android.com/studio/profile/investigate-ram.html

The post Pen Testing Android Apps, Part 5: Analyzing the Heap Dump appeared first on McAfee Blogs.

This blog post was written by Rick Simon.

We know that devices in the Internet of Things make enticing targets for attack. They are often insecure and can act as open windows into trusted networks. Cybercriminals are capitalizing on that more and more each day, gathering hundreds of thousands of insecure IoT devices into giant botnets. Remember what happened last fall when Mirai malware conducted the largest DDoS attack we have seen so far. The downstream effect of that attack was that millions of people could not reach such popular sites as Twitter, Spotify, Box, The New York Times, and Airbnb.

Now, two new attacks targeting IoT devices have emerged. The BrickerBot malware has been infecting and “bricking” poorly secured IoT devices. It is said that the BrickerBot operator is making these devices unusable to keep Mirai from infecting the same devices. Apparently, this attacker may be a modern-day vigilante.

The second attack is based on malware called Hajime. It appears to use its power for good instead of evil, actually securing the IoT devices it infects to protect them from more malicious attacks like Mirai. However, because the devices have been infected by Hajime, there is nothing stopping the Hajime botnet operator from changing their objectives.

What do these attacks have in common? They all take advantage of poor network and credential management. In these attacks, the malware scans for open Telnet or SSH ports, discovers IoT devices behind them, performs brute-force attacks using a dictionary of common default usernames and passwords, and then looks for ways to send the malware payload. Once infected, each malware family has different objectives, as we discussed above.

Given that these IoT device attacks follow the same attack sequence, why don’t IoT device makers simply address their weaknesses? And if they address the problems of poor network and credential management, will that solve the IoT device security problem once and for all?

We offered an answer to the first question in the McAfee Labs 2017 Threats Predictions report. In that report, we said that in their drive to be first to market with certain types of IoT devices, developers focus on features designed to capture early adopters. Unfortunately, sound security is usually not at the top of the list of must-have features by that class of buyers. Further, the use of poorly written, insecure third-party code libraries can exacerbate the problem. So, until the IoT device land rush subsides, we will probably continue to see obvious security weaknesses.

Addressing the problems of poor network and credential management will solve only the IoT device security weaknesses being exploited today. There will be other exploited weaknesses tomorrow.

The right way to look at security in an IoT device is by using an assist such as the OWASP IoT Attack Surface model. From an attacker’s point of view, an IoT device is very similar to any other computer system and should be assessed for security just as with other systems. I created this previously unpublished image last year to make the point:

This is the toaster attack surface!

In fact, when our threat research team examines an IoT device for security weaknesses, they use the OWASP model for guidance. If IoT device makers simply examined their products during development through an attacker’s lens, they could reduce the number of security weaknesses significantly.

What can you do today to mitigate IoT device security weaknesses? Some weaknesses unfortunately fall into the category of acceptable risk. Other weaknesses, however, can be addressed. Check out the Solution Brief “Secure IoT Devices to Protect Against Attacks” to learn more. In that brief, we offer actionable policies and procedures for securing IoT devices. We also provide detailed advice on how McAfee products can protect systems and networks from IoT device attacks.

To stay up to date on all cybersecurity news, follow @McAfee and @McAfee_Labs.

The post Mirai, BrickerBot, Hajime Attack a Common IoT Weakness appeared first on McAfee Blogs.

This blog was written by Sanchit Karve.

McAfee Labs has discovered that banking malware Pinkslipbot (also known as QakBot/QBot) has used infected machines as control servers since April 2016, even after its capability to steal personal and financial data from the infected machine has been removed by a security product. These include home users whose computers are usually behind a network address translation router. To do so, Pinkslipbot uses universal plug and play (UPnP) to open ports, allowing incoming connections from anyone on the Internet to communicate with the infected machine. As far as we know, Pinkslipbot is the first malware to use infected machines as HTTPS-based control servers and the second executable-based malware to use UPnP for port forwarding after the infamous W32/Conficker worm in 2008.

Pinkslipbot is a notorious banking-credential harvester that has been active since 2007. It primarily targets users and enterprises located within the United States and includes components for password stealers, keyloggers, and man-in-the-browser attacks that are used as vectors to steal various kinds of information—including credit cards, social security numbers, online account credentials, email passwords, digital certificates, etc. Pinkslipbot controls a large botnet of more than 500,000 infected machines and steals over a half-million records every day. As a result, this malware has been documented extensively by the antimalware industry. The malware authors are clearly benefiting from Pinkslipbot; they have maintained the code base since 2007 and regularly add new features to it.

When Pinkslipbot resurfaced in December 2015, we analyzed the samples and published our findings at the Virus Bulletin Conference (VB2016) in October 2016. That report described its use of “ATSEngine” to automatically transfer money from bank accounts that belonged to infected users. At the time, Pinkslipbot was equipped with a domain generation algorithm with antisinkhole capabilities to locate its control server. After April 26, 2016, the malware sidelined the algorithm as a backup option in favor of a list of control server IP addresses embedded within every sample. Because many of the IP addresses belonged to legitimate organizations, we believed the malware authors intentionally included them to deter the cybersecurity industry from blacklisting all IP addresses en masse.

Turns out we were wrong in that assessment. We have discovered that the list of IP addresses consists solely of infected machines that serve as HTTPS-based proxies to the actual control servers. This setup (shown in the following diagram) is used to mask the real IP addresses of the Pinkslipbot control servers.

Figure 1: Layout of a typical Pinkslipbot control server.

Our VB2016 paper also showed how all server components (control server, JavaScript-download server, exploit kit servers) were interchangeable and contained the same functionality. This information continues to hold true with this new discovery. All control server-related information described as follows has been observed on other server components used by Pinkslipbot.

From infected machine to control server proxy

The exact procedure of determining whether an infected machine is eligible to be a control server proxy is unknown. However, we believe this decision depends on an infected machine’s satisfying a combination of three factors.

• IP address located in North America
• High-speed Internet connection
• Capability to open ports on an Internet gateway device using UPnP

To gauge the Internet connection speed, the malware downloads an image from Comcast’s Speed Test service from four locations in the United States.

• http://sanjose.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1
• http://boston.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1
• http://jacksonville.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1
• http://houston.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1

Once the downloads are complete, the results of the speed test are sent to the control server.

The Pinkslipbot binary then uses the miniupnpc library to issue a Simple Service Discovery Protocol packet and look for the following UPnP devices:

• urn:schemas-upnp-org:device:InternetGatewayDevice:1
• urn:schemas-upnp-org:service:WANIPConnection:1
• urn:schemas-upnp-org:service:WANPPPConnection:1
• upnp:rootdevice

Figure 2: Pinkslipbot’s device discovery over the Simple Service Discovery Protocol.

Once devices are discovered, their descriptions are downloaded to look for Internet gateway devices (IGD). This is done by looking for the service type urn:schemas-upnp-org:service:WANCommonInterfaceConfig: in the device description. The IGD is then checked for connectivity (for example, by calling the GetStatusInfo function on the device and confirming the returned response is “Connected”) and the external IP address is retrieved using the GetExternalIPAddress() function on the device.

Once an IGD is discovered, port-forwarding rules are created by using the AddPortMapping function on the IGD.

Figure 3: Disassembled code showing port mapping functionality.

The malware attempts to port-forward 27 internal and external ports, listed below.

• 443*
• 465*
• 990*
• 993
• 995*
• 1194
• 2078*
• 2083
• 2087
• 2222*
• 3389
• 6881
• 6882
• 6883
• 8443*
• 32100
• 32101
• 32102
• 32103*
• 50000
• 50001
• 50002
• 50003
• 50010
• 61200*
• 61201*
• 61202

The ports marked with a * are currently in use (as of June) by Pinkslipbot control servers.

If any port-forwarding request succeeds (and if other open ports are found), the malware saves the port number into a buffer and removes the port-mapping rule. The port-forwarding results are submitted to the control server using an HTTP POST request:

URL: hxxps://{control server-IP-Address}:{Port}/bot_serv
POST-DATA:
cmd=1&msg={obfuscated-string}&ports=993,80,465,21,50000,61200,61202

Based on this data, the malware author decides whether the infected machine can be used as a control server. Once an infected machine is selected, the “wgetexe” control server command (more accurately, command 25 using control server protocol Version 14) is issued to the infected machine to download a Trojan binary as “tmp_{timestamp}.exe.” This sample is responsible for the control server proxy communication, as we shall explain.

The downloaded Trojan is a dropper for the proxy component. It creates the following files either in %APPDATA% or %ALLUSERSPROFILE%, depending on the operating system.

• HardwareMonitor\hardwaremonitor.dll
  • The proxy component
• HardwareMonitor\hardwaremonitor.ini
  • Contains the Pinkslipbot BOTID stored under the field “n”
  • Contains available ports for mapping stored under the field “prt”

The file hardwaremonitor.dll (originally created as supernode_con.dll by the malware authors) is created as a new “hwmon” service launched via calling an export function (HwmonServerMainNT or HwmonServerMain) using rundll32.exe. A firewall rule is also created for rundll32.exe.

When launched as a service, the proxy component creates port-forwarding rules (using the description “NAT-PMP {port} tcp”) just as with the original Pinkslipbot sample but it does not remove them this time. The infected machine can now be used as a control server over HTTPS. The proxy component at this stage will contact the real control server via one of its hardcoded proxy servers with the following HTTPS POST request:

URL: https://{proxy-IP}/gwsup
POST-DATA:n={BOTID}&rt={IsWinNT}&prt={UPnP-Forwarded-Port}&os={OS-Version}&ver={MajVer}.{MinVer} &upnp_stat={UPnP-Status}&upnp_descr={UPnP-Port-Forward-Description}

Once the infected machine receives a control server request from a new Pinkslipbot infection, it routes all traffic to the real control servers via an additional proxy using the popular libcurl URL transfer library. As with the original malware, the responses from the real control servers are parsed and digital signatures verified using a hardcoded RSA public key (using the MatrixSSL library). To mask its presence to the outside world, responses from the real control servers (which run Apache) are modified to look like they were hosted on a server running nginx Version 1.9.12.

Figure 4: A fake server name used by Pinkslipbot.

This step agrees with our previous findings from the VB2016 paper, in which we saw an nginx server responding with a specific error message (see Page 6) during control server communication that indicated the presence of a curl-based proxy server residing on Pinkslipbot control servers. However, at the time we were not sure how this was implemented or where the curl component resided. The presence of the same error message in the proxy component DLL confirms its purpose for responding to control server requests.

Figure 5: The missing component from 2016 has been identified based on the error message.

Two custom HTTP headers are also passed to the hardcoded proxy servers to indicate the IP address of the infected machine making the request and the Pinkslipbot BOTID of the infected machine serving as the proxy server.

Because the Pinkslipbot control server protocol is based on HTTPS, it needs a server-side certificate to operate. It gains this on the fly by generating new self-signed certificates for every new connection using the OpenSSL library built with libcurl. The generated certificates are issued random values for the following certificate attributes:

Figure 6: Server certificate generation code from Pinkslipbot.

The malware authors take some extra effort to make the generated certificates appear legitimate by ensuring that:

• The organization attribute ends with either Inc. or LLC.
• The common name attribute uses one of the following top-level domains:
  • .com
  • .net
  • .org
  • .biz
  • .us
  • .info
  • .mobi

User recommendations

As UPnP assumes local applications and devices are trustworthy, it offers no security protections and is prone to abuse by any infected machine on the network. We have observed multiple Pinkslipbot control server proxies hosted on separate computers on the same home network as well as what appears to be a public Wi-Fi hotspot. The port-forwarding rules created by Pinkslipbot are too generic to remove automatically without risking accidental network misconfigurations. And as most malware do not interfere with port-forwarding, antimalware solutions may not revert such changes. Unfortunately, this means that your computer may still be vulnerable to outside attacks even if your antimalware product has successfully removed all Pinkslipbot binaries from your system. To ensure your computers are not unintentionally accessible from the Internet, we encourage you to download our free utility listed in the next section to look for Pinkslipbot control server proxy infections and remove malicious port mappings. Even without the UPnP elements, Pinkslipbot is still a dangerous Trojan capable of causing a lot of damage. A few years ago it gained attention for locking Active Directory while spreading over the network by brute-forcing network credentials. We recommend following the recommendations published in the McAfee Threat Advisory for W32/Pinkslipbot.

From a general cybersecurity perspective, we were surprised to see a banking Trojan use a complicated multistage proxy for HTTPS-based control server communication, especially considering that it uses UPnP to repurpose home user infections as control servers. Aside from a 2008 proof of concept created by security researchers and the W32/Conficker worm in 2009, information about malicious use of UPnP by malware is scarce. We expect this to change soon as more people use routers with built-in UPnP capabilities (enabled by default) than in 2008. Many Internet of Things devices work over UPnP and are steadily being installed and used by more people every day. As they become more ubiquitous, cybercriminals will see opportunities to use UPnP maliciously. We recommend that users keep tabs on their local port-forwarding rules and disable UPnP on their home routers unless they need it.

Pinkslipbot Control Server Proxy Detection and Port-Forwarding Removal Tool

If your system has been infected with W32/PinkSlipbot (Qakbot/QBot), your machine may still be serving as a control server proxy for the malware. Even if all malicious components have been removed by your security product, your computer may be vulnerable to attacks if it is accessible over the Internet. To help identify this vulnerability on your computer and network, we have developed a free port-forwarding detection and removal tool specific to this malware. This utility will also detect the Pinkslipbot control server proxy service if found and disable (though not remove) the service.

The tool can be downloaded here. By default, the tool operates in detect mode, in which no changes are made to your system or router configuration if malicious elements are found.

Figure 7: The McAfee Pinkslipbot Control Server Proxy Detection and Port-Forwarding Removal Tool operating in its default “detect only” mode.

If the tool finds malicious port-forwarding rules and malicious services, you may pass the “/del” command line argument to the tool to disable the malicious service and remove the port-forwarding rule.

Figure 8: McAfee Pinkslipbot Control Server Proxy Detection and Port-Forwarding Removal Tool operating in “detect and disable” mode.

Indicators of compromise

• One or more of these files:
  • %APPDATA%\HardwareMonitor\hardwaremonitor.dll
  • %ALLUSERSPROFILE%\HardwareMonitor\hardwaremonitor.dll
  • %APPDATA%\HardwareMonitor\hardwaremonitor.ini
  • %ALLUSERSPROFILE%\HardwareMonitor\hardwaremonitor.ini
• A service created with the name “hwmon” and binary path containing “rundll32.exe.”
• TCP port forwards enabled for one of these ports using description “NAT-PMP {port} tcp” and no expiration time:
  • 443, 465, 990, 993, 995, 1194, 2078, 2083, 2087, 2222, 3389, 6881, 6882, 6883, 8443, 32100, 32101, 32102, 32103, 50000, 50001, 50002, 50003, 50010, 61200, 61201, 61202
• Connections from and to these IP addresses:
  • 158.255.2.138
  • 185.162.8.190
  • 185.169.229.168

Sample hashes

• Proxy component droppers
  • 22cf76f92aad53db1304dec026b834ad77d2272c7f2eaaabf299e953b98d570e
  • c23fe9f3a3035edb6fa306c7545cfd05bb310d85983dda5914cd9650c13b41d3
• Proxy component DLL (internal name: supernode_con.dll)
  • 730e9864795ed8d6538064551ab95505dff3e92dd67888bee323cb341b2420c6
  • af25c5bed96e046ba1e25749ff51f0d8437a1ef66e469b4fd0348e372abc2f7f
  • 6d174dd4f29da814170e8f7c40ecd80794e1c27d8d94741a79bd1bd6eb75ea62

The post McAfee Discovers Pinkslipbot Exploiting Infected Machines as Control Servers; Releases Free Tool to Detect, Disable Trojan appeared first on McAfee Blogs.

This blog was written by Krishs Patil.

A memory corruption bug in UDP fragmentation offload (UFO) code inside the Linux kernel can lead to local privilege escalation. In this post we will examine this vulnerability and its accompanying exploit. Although this bug affects both IPv4 and IPv6 code paths, we analyzed only IPv4 code running on vulnerable kernel version 4.8.0 of Ubuntu xenial. The bug was fixed in Commit 85f1bd9.

Andrey Konovalov recently disclosed local privilege escalation exploits for vulnerabilities he found inside the Linux network subsystem while “fuzzing” with the tool syzcaller. In an oss-sec mailing thread, Konovalov wrote “When building a UFO packet with MSG_MORE __ip_append_data() calls ip_ufo_append_data() to append. However in between two send() calls, the append path can be switched from UFO to non-UFO one, which leads to a memory corruption.”

NIC Offloads and UFOs  

Network interface card (NIC) offload allows the protocol stack to transmit packets that are larger than the Ethernet maximum transmission unit (MTU), which by default is 1,500 bytes. When NIC offload is enabled, the kernel will assemble multiple packets into a single large packet and pass it to the hardware, which handles IP fragmentation and segmentation into MTU-sized packets. This offload is often used with high-speed network interfaces for increased throughput because UFO can send large UDP packets.

The Linux kernel can take advantage of the segmentation-offload capabilities of various NICs.

Triggering a POC

The following is a simple proof of concept that will trigger kernel panic:

To build UFO packets inside the kernel we can take one of two steps:

• Use the UDP_CORK socket option, which tells the kernel to accumulate all data on this socket into a single diagram to be transmitted when the option is disabled.
• Use the MSG_MORE flag when calling send/sendto/sendmsg, which tells the kernel to accumulate all data on this socket into single diagram to be transmitted when a call is performed that does not specify this flag. This method triggers the vulnerability.

Inside the kernel, the udp_sendmsg function is responsible for constructing UDP packets and sending them to the next layer. The following code shows a stripped implementation of UDP cork functionality enabled by the user program using the UDP_CORK socket option or the MSG_MORE flag when calling send/sendto/sendmsg. When UDP corking is enabled, the ip_append_data function is called to accumulate multiple packets into single large packet.

The function ip_append_data is a wrapper around __ip_append_data, which is responsible for socket buffer management by allocating a new socket buffer to store the data passed to it or by appending the data to existing data when the socket is corked. One important task performed by this function is the handling of UFO. Socket buffers are managed in the socket’s send queue. In the case of corked sockets, the queue has an entry in which additional data can be appended. The data sits on the send queue until udp_sendmsg determines it is time to call udp_push_pending_frames, which finalizes the socket buffer and calls udp_send_skb.

The Linux kernel stores packets in the structure sk_buff (socket buffer), which is used by all network layers to store their headers, information about user data (payload), and other internal information.

The socket buffer inside the kernel.

In the preceding diagram, the head, data, tail, and end members of sk_buff point to the boundaries of the memory region in which protocol headers and the user payload is stored. The head and end point to the beginning and end of space allocated to the buffer. Data and tail point to the beginning and end of user data within the entire space. Immediately following the end boundary, the structure skb_shared_info holds important information for IP fragmentation.

Memory Corruption

When the first call to “send” is made with the MSG_MORE flag, as shown in the earlier POC, __ip_append_data takes creates a new socket buffer by calling ip_ufo_append_data, as we see in the following code:

When this call is finished, and the new socket buffer is created, user data is copied to the fragment and the shared info structure is updated with fragment information, as shown in the next image. The newly created sk_buff is then placed in the queue.

In the next step, the PoC updates the socket to not calculate a checksum on the UDP by setting the option SO_NO_CHECK ; this overrides the sk->sk_no_check_tx member of the socket structure. Inside __ip_append_data this variable is checked as one of the conditions prior to calling ip_ufo_append_data.

During the POC’s second call to “send,” a non-UFO path is taken inside __ip_append_data, which proceeds to a fragment length calculation loop. During the first iteration of the loop, the value of copy becomes negative, which triggers a new socket buffer allocation. Plus the fraggap calculation exceeds the MTU and triggers fragmentation. This leads to copying the user payload from sk_buff, created by the first send call, to the newly allocated sk_buff using the skb_copy_and_csum_bits function. This copies a specified number of bytes from the source buffer to the destination sk_buff and computes a checksum. Calling skb_copy_and_csum_bits with a length greater than the newly created sk_buff boundary end limit overwrites the data beyond the socket buffer and corrupts the skb_shared_info structure that is immediately preceded by sk_buff.

The corrupted skb_shared_info structure follows. The memory at address 0xffff88003a4ca900 is the newly created sk_buff with end=1728, where the fragmentation is triggered.

Exploitation

This bug can be exploited by an unprivileged user when unprivileged user namespaces are allowed on most default Ubuntu desktop systems. Users should be able to do two things:

• Set up an interface with UFO enabled (possible from the user namespace) or use that interface if it is already present. (The “lo” interface enables UFO by default.)
• Disable the NETIF_F_UFO interface feature or set the SO_NO_CHECK socket option.

Code execution can be diverted to user-mode shellcode by simply crafting a fake skb_shared_info structure at the end of a large buffer and setting the callback member to shellcode. The second “send” triggers an out-of-bounds condition on the socket buffer, overwriting skb_shared_info->destructor_arg with the user-mode shellcode address, which is invoked before sk_buff is released from kernel memory.

The Linux kernel offers a big attack surface when exposed to unprivileged users. All users should keep their systems patched with the latest updates.

Stay up to date on this vulnerability and more by following @McAfee_Labs.

The post Linux Kernel Vulnerability Can Lead to Privilege Escalation: Analyzing CVE-2017-1000112 appeared first on McAfee Blogs.

This blog post was written by Kumaraguru Velmurugan.

Point of sale (POS) attacks appear to have gained in popularity during the past year or so. We have seen major retail chains targeted by different strains of POS malware. Equipped with memory-scraping functionality, POS malware steals credit or debit card information from shoppers who use their cards for payments.

The following illustration shows the similarity of a recent variant we have captured against previous samples we’ve seen. The code has undergone minimal changes since its inception.

Black POS malware is one of the most prevalent POS families in the wild. Recently we noticed new variants of Black POS that exhibit no behavior when executed in a synthetic environment. This inactivity in a sandbox promptly captured our attention. This new variant of Black POS checks the system time on the infected machine against the hardcoded time stamp on the executable. (Malware has long used this technique to be active only during certain periods, while remaining dormant the rest of the time.)

This variant of Black POS was compiled with Borland C++. Next we see one sample’s main function, in which time is checked against a preset value.

Looking at the malware’s time stamp, Wed 14 Jan 2015 18:14:29 GMT, we see the malware is designed to exhibit its behavior for one month from the time it was compiled.

The key functions of this sample include memory dumping and enumerating modules loaded in process memory.

The sample also scans for credit card information in memory by employing a Perl Compatible Regular Expressions engine, as shown in the following image.

McAfee Advanced Threat Defense detects the samples involved in this attack. The sample is detected via static code analysis, the Family Classification module.

The post POS Malware Uses Time-Stamp Check to Evade Detection appeared first on McAfee Blogs.

This blog post was written by Sudhanshu Dubey.

McAfee Labs has recently analyzed Version 2 of Cerber, one of the leading ransomware programs. Cerber infects systems via social media tricks such as spam email with malicious links or documents, malvertising campaigns, exploits of vulnerable websites, and also takes advantages of exploit kits like Angler, Nuclear, and others.

During our analysis of the new version, we found some new fields in the configuration file. In this post, we highlight the changes in the configuration files of Cerber Versions 1 and 2.
This snapshot shows a machine infected with Cerber 2.

Machine infected with Cerber Version 2.

The extensions of encrypted files has changed from .cerber to .cerber2.

Partial lists of files infected with Cerber 1 and 2.

Why an update?
The ransomware author may have upgraded the malware because of the release of a decryption tool. The ransomware’s detection rate may have also increased; this version has a new packer (wrapper) to make it harder for security products and analysts to find and examine the malware.

Our analysis did not find many significant changes. This version likes to keep its component files (containing the public key and other data) on disk after the encryption process, whereas the previous version kept the component files only in the registry entries. Files and registry entries have the same content.

Version 2’s component files in %appdata% and registry entries.

The location of the encrypted configuration file is updated from the resource section to the last section. We will discuss this further in a future post.

The configuration file
We observed some changes in the configuration files of the two versions. Most are related to encryption tags and antimalware products.

The first change that caught our eye is the addition of rc4_key_size in the encrypt tag. This value was previously calculated at runtime but now is included in the file. The author also updated the infected-files extension to .cerber2 and also modified the value of the rsa_key_size field. The following snippets show some of the changes.

Version 1 (left) and Version 2 encryption tags.

Version 2 includes a blacklist to fight against the security products. The av_blacklist tag in the configuration file contains a list of several vendors’ names.

Version 2’s av_blacklist tag.

The new av_blacklist tag is reflected in the check tag as a flag in the configuration file.

Check tag in Version 1.

Check tag in Version 2.

Close_process list enhancements
Some applications use a locking mechanism to prevent other application from accessing or making changes in the files they access to maintain data integrity. Word for Windows does this, for example. To stop a locking mechanism from preventing the encryption of files, Cerber terminates such processes. The list of these processes is kept under the close_process list tag. In this version, Cerber enhances this list significantly, as shown below:

The close_process tag in Version 1.

The close_process tag in Version 2.

Wallpaper template
Version 2 adds a wallpaper tag, which is a template to create the desktop background on the victim’s machine. The variable fields—including TOR, SITE_N, and PC_ID—is updated at runtime.

The wallpaper tag in Version 2.

Anti-VM techniques
Cerber is one of the most comprehensive malware in fighting virtual machines. Cerber detects popular VMs such as Parallel, QEMU, VMware, and VBox. One of the most interesting techniques (in both versions) is Cerber’s enumeration of the registry key “HKLM\\SYSTEM\\CurrentControlSet\\Enum\\PCI”:

Accessing the registry: HKLM\\SYSTEM\\CurrentControlSet\\Enum\\PCI.

Each subkey of HKLM\\SYSTEM\\CurrentControlSet\\Enum\\PCI represents a PCI-bus connected device with the following format:

• VEN_XXXX&DEV_XXXX&SUBSYS_XXXXXXXXX&REV_XX
  where VEN stands for Vendor ID in hexadecimal view and DEV stands for Device ID in hexadecimal view.

A table of virtual machines with known hardware vendor IDs:

The following code snippet compares the subkey name with the VBox vendor ID.

Checking the VBox vendor ID.

If Cerber finds any of the vendor IDs among registry key names, it stops and terminates itself.

Summary
Cerber is a popular form of ransomware. Given the changes we have observed in the configuration file, we also expect to see change in Cerber’s encryption techniques. We’ll discuss those soon in a further analysis.

McAfee products detect Cerber under generic names such as Generic.* and BehavesLike.Win32.*.

The post Cerber Ransomware Updates Configuration File appeared first on McAfee Blogs.

This blog post was written by Sudhanshu Dubey.

In an earlier blog, we discussed the evolution of the popular Cerber ransomware from Version 1 to 2. Recently we came across two newer versions of Cerber (we’ll call them Versions 3 and X). Cerber 3 has few changes but Version X has some new behavior that caught our attention. (We call this version X, not 4, because this version does not follow Cerber’s usual encryption extension prototype, .cerberN, and instead uses a random extension.) In this post, we will dig into this new version and will uncover the mystery behind the random extension.

Cerber infects systems via social media tricks such as spam email with malicious links or documents, malvertising campaigns, exploits of vulnerable websites, and it also takes advantage of exploit kits such as Angler, Nuclear, and others.

Machine infected with Cerber X.

Extensions of files encrypted by Cerber Versions 2, 3, and X:

Analysis of Cerber X

In contrast to Version 2, Cerber X uses the Nullsoft Scriptable Install System (NSIS) to hide itself. The installer contains the encrypted Cerber executable (.ch) and a shellcode file (.caz) that contains code to decrypt the Cerber file. A component of NSIS follows:

The file .ch is the encrypted Cerber file. The first DWORD of the file is the file size of the Cerber core file followed by encrypted data. A snippet of the encrypted core file follows:

The file .caz contains shellcode used to decrypt itself as well as the encrypted Cerber file (.ch) and execute it. A snippet of the shellcode file:

Configuration file of Cerber 2 versus X

We observed few changes in the configuration files of Versions 2, 3, and X. They are related in Base64 encoding, self-deletion, encryption message file, and other elements. Here are some of the changes.

• Base64 encoding: In Version 2, the configuration file has all contents in plaintext format. Version X has some fields encoded with Base64-like encryption messages. This change might be used to reduce the in-memory detection of the file because encryption messages have many suspicious strings that help analysts catch the malware in memory. So this will reduce the time suspicious strings spend in memory.
• Encryption message file: In contrast to previous versions in which Cerber drops files such as # DECRYPT MY FILES .htm#, this version drops only one, README.hta (an HTML application) file. Similar to its predecessors, the name and content of the message file are kept in the configuration file but with Base64 encoding.
• bytes_skip tag: Skips a number of bytes from the start of file during encryption.
• self_deleting tag: Deletes itself after encryption.
• remove_shadows tag: Removes shadow copy backups.

How Cerber gets its random extension

This version has unique behavior from its predecessors. It does not follow the .cerberN (where N is a number) extension rule but rather uses system information to get an encrypted file extension. This version also has different component filenames and locations that are also derived using system information.

Cerber X uses the following registry entry to get its component filename and extension for an encrypted file.

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid

MachineGuid has the following format:

• XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

This code snippet shows Cerber accessing the preceding registry key:

Cerber X tokenizes the Guid using a hyphen and other elements:

• Part 1 (8 characters): Used as a folder name for the Cerber component in %TEMP% directory.
• Part 2, Part 3 (4 characters each): Used as filenames for Cerber’s component files.
• Part 4 (4 characters): Used as the extension of the encrypted file.

So the mystery behind the random extensions is MachineGUID, whose fourth token becomes the extension for the encrypted file. We can use this behavior of getting file and folder names from MachineGUID as a heuristic detection for Cerber X because only after dropping the components does the malware start its encryption process. Thus if we could detect this behavior of using MachineGUID, we could prevent the encryption of a victim’s files.

Network communications

Network communications are basically similar in all versions. But this version has some minor changes in gathering data to send. Server information is kept in configuration file:

Cerber uses the sendto API to send info to the IP address mentioned in the server tag of the configuration file. The initial information sent to server is 9 bytes, and the data prototype is stored in the knock tag of configuration file with Base64 encoding. The format of data:

• hi{PARTNER_ID}

PARTNER_ID is generated at runtime. In this version the method to get it is different. PARTNER_ID, which is 7 characters long, is generated in two parts. The first part has 5 characters and second part has 2. In Version 2, the first part is generated with the help of a checksum of the file; in Version X it is taken from a hardcoded address in the .data section of the file.

Code snippets from both versions:

Anti-VM blooper

As we mentioned in our previous blog, irrespective of the version Cerber is one of the most comprehensive malware. Cerber exhibits anti–virtual machine techniques that detect popular VMs including Parallel, QEMU, VMware, and VBox. While analyzing we observed a curious thing: In one of the anti-VM techniques, Cerber accesses the following registry key:

• HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\SystemBiosVersion

After accessing the key, it tries to locate the substring “WMWare” instead of “VMWare” in the value, as shown:

Looks like even ransomware developers have trouble with typos.

McAfee products detect Cerber as NSIS/Ransom-Cerber.a

The post Unfolding the Mystery of Cerber Ransomware’s Random File Extension appeared first on McAfee Blogs.

This blog post was written by Rock Liu.

Recently the OpenSSL security library gained a fix for a critical security issue (CVE-2016-6309) that affects OpenSSL Version 1.1.0a. The remote attackers can cause the OpenSSL server to crash, or execute arbitrary code on it, by simply sending a handshake packet with a message larger than 16KB. To defend against these attacks we analyzed the code, wrote a proof of concept, and prepared a signature for our customers.

OpenSSL offers the following description:

“The buffer to receive messages is initialized to 16KB. If a message is received that is larger than that, then the buffer is ‘realloc’d.’ This can cause the location of the underlying buffer to change. Anything that is referring to the old location will be referring to free’d data.”

From the OpenSSL source code, we know it uses the structure “ssl_st” to store the SSL session information. Both init_msg and init_buf are members of the structure of ssl_st. Init_msg points to the handshake message body, which is contained in the buffer pointed to by init_buf. The variable “s” (s->init_msg) is a pointer to the structure of ssl_st.

From this information, we suspect a single handshake message might trigger this vulnerability.

This is the format of a handshake packet in the TLS protocol:

———+———–+———–+———–+———–+——————————

| 0x16 | 0x0301 | 0x4000 | 0x0100 | 0x5560 | DATA(length=0x5560) |

———+———–+————+———–+———–+——————————

|       |       |               |————–Length of challenge

|       |       |

|       |       |—————————————-Length handshake message

|       |—————————————————–Version

|——————————————————————Content type：Handshake

We manually constructed a handshake packet of more than 16KB (0x5560).

Figure 1: The TLS handshake packet.

We sent the oversized handshake to a vulnerable OpenSSL server, and it crashed.

Figure 2: Crash information from the vulnerable OpenSSL server.

Now for more details. First, let’s take a look at how the issue was fixed. The patch is available here.

if (!SSL_IS_DTLS(s)

&& s->s3->tmp.message_size > 0

–                    && !BUF_MEM_grow_clean(s->init_buf,

–                                           (int)s->s3->tmp.message_size

–                                           + SSL3_HM_HEADER_LENGTH)) {

+                    && !grow_init_buf(s, s->s3->tmp.message_size

+                                         + SSL3_HM_HEADER_LENGTH)) {

ssl3_send_alert(s, SSL3_AL_FATAL, SSL_AD_INTERNAL_ERROR);

SSLerr(SSL_F_READ_STATE_MACHINE, ERR_R_BUF_LIB);

return SUB_STATE_ERROR;

The lines preceded by “-” are the old code, while the “+” lines are the patch. The patch introduced a new function, grow_init_buf, to replace the function BUF_MEM_grow_clean. This new function handles the chores of buffer reallocation to make sure the buffer is big enough to hold the handshake message.

Now let’s check out the new function: grow_init_buf:

static int grow_init_buf(SSL *s, size_t size) {

size_t msg_offset = (char *)s->init_msg – s->init_buf->data;

if (!BUF_MEM_grow_clean(s->init_buf, (int)size))

return 0;

if (size < msg_offset)

return 0;

s->init_msg = s->init_buf->data + msg_offset;   <——————reset the init_msg

return 1;

}

This newly introduced function internally will still call the old function BUF_MEM_grow_clean; after that it resets the init_msg (marked above).

Next, let’s look into this piece of vulnerable code with a debugger.

Figure 3: The unpatched code before the control flow reaches the function BUF_MEM_grow_clean.

Figure 3 gives us the following status information:

• s->init_msg=0x6c3184
• s->init_buf.data=0x6c3180
• length=0x4000 and is controllable by the attacker through the handshake message

Now s->init_msg points to our handshake message, and is contained in the buffer pointed to by s->init_buf.data.

Figure 4: The scenario in which the control flow returns only from the function BUF_MEM_grow_clean.

At this point, apparently init_buf.data has been changed, but init_msg still points to 0x6c3184.

• s->init_msg=0x6c3184
• s->init_buf.data=0x6ce7c0

Now let’s step into the function BUF_MEM_grow_clean to find out why s->init_buf.data has changed:

size_t BUF_MEM_grow_clean(BUF_MEM *str, size_t len)

{

char *ret;

size_t n;

if (str->length >= len) {

if (str->data != NULL)

memset(&str->data[len], 0, str->length – len);

str->length = len;

return (len);

}

if (str->max >= len) {

memset(&str->data[str->length], 0, len – str->length);

str->length = len;

return (len);

}

if (len > LIMIT_BEFORE_EXPANSION) {

BUFerr(BUF_F_BUF_MEM_GROW_CLEAN, ERR_R_MALLOC_FAILURE);

return 0;

}

n = (len + 3) / 3 * 4;

if ((str->flags & BUF_MEM_FLAG_SECURE))

ret = sec_alloc_realloc(str, n);       <—–realloc a new memory for init_buf

else

ret = OPENSSL_clear_realloc(str->data, str->max, n);

if (ret == NULL) {

BUFerr(BUF_F_BUF_MEM_GROW_CLEAN, ERR_R_MALLOC_FAILURE);

len = 0;

} else {

str->data = ret;

str->max = n;

memset(&str->data[str->length], 0, len – str->length);

str->length = len;

}

return (len);

}

In the preceding code, we have marked the place where memory reallocation occurs. If we can pass all three checks (“str->length >= len,” “str->max >= len,” and “len > LIMIT_BEFORE_EXPANSION”), the function would eventually change s->init_buf.data (str->data) with the memory allocated by sec_alloc_realloc (marked).

Figure 5: The values of variables str->length, len, and str->max. All three variables can be controlled by the attacker.

From Figure 5, we can clearly see the values of variables when the program is executing inside the BUF_MEM_grow_clean:

• len=0x5564 (the packet’s real length)
• str->length=0x4000 (the length of the handshake message)
• str->max=0x5558 (the length of challenge)

Because we can control the value of all three variables, it is trivial to bypass all the checks and hit the sec_alloc_realloc function.

Finally, let’s see what happens inside the function sec_alloc_realloc:

static char *sec_alloc_realloc(BUF_MEM *str, size_t len)

{

char *ret;

ret = OPENSSL_secure_malloc(len);          <———realloc memory

if (str->data != NULL) {

if (ret != NULL)

memcpy(ret, str->data, str->length);

OPENSSL_secure_free(str->data);       <———free old memory

}

return (ret);

}

The function sec_alloc_realloc reallocates new memory, and then frees the old memory (marked). At this point, however, s->init_msg is still pointing to the old memory that has been freed by sec_alloc_realloc. Thus later when s->init_msg is referenced, the program will either crash, or in some cases be forced to access the attacker-controlled memory, which may lead to code execution.

The patch added the new function grow_init_buf to replace the function BUF_MEM_grow_clean, and the new function will update init_msg when OpenSSL reallocates new memory to make sure it points to valid memory. For better visualization, we prepared a video to demonstrate the attack in action. (In the video, the right window shows an OpenSSL server on port 443 with standard parameters. In the left window, we send an oversized handshake to the vulnerable server, which crashes.)

Impact

More than 60% of active websites use OpenSSL to transfer data. More and more sites now use OpenSSL to protect the sensitive user information, such as passwords, card IDs, and usernames. Amazon, the world’s largest cloud vendor, recommend OpenSSL to its customers, and offers many advisories.

Many of us remember the notorious OpenSSL Heartbleed attack, which occurred in April 2014. At that time it was considered the Internet’s worst nightmare. “A survey of American adults conducted in April 2014 showed that 60% had heard about Heartbleed. Among those using the Internet, 39% had protected their online accounts, for example by changing passwords or canceling accounts; 29% believed their personal information was put at risk because of the Heartbleed bug; and 6% believed their personal information had been stolen,” according to Wikipedia. From the attack and these survey results, we can see that a single critical OpenSSL issue can cause a significant impact on the Internet due to OpenSSL’s wide deployment. The vulnerability, CVE-2016-6309, that we discuss in this post is different from other OpenSSL vulnerabilities. In this case, the flaw occurs when the OpenSSL server handles the handshake message, the first packet of the TLS protocol. This makes the attack easy to carry out because the attacker can send just one packet to deny access to the server without the need for authentication.

The update is available here.

For McAfee Network Security Platform customers, we have released the signature 0x45c08f00 “SSL: Possible OpenSSL Use-After-Free Vulnerability (CVE-2016-6309)” to prevent this attack.

The post How to Protect Against OpenSSL 1.1.0a Vulnerability CVE-2016-6309 appeared first on McAfee Blogs.

This blog post was written by Sudhanshu Dubey.

At McAfee Labs we recently analyzed the ransomware KillDisk. We will share our analysis in two parts: the first, this article, contains general information about the malware and its whitelisting technique; the second part will appear soon with an analysis of its variants and techniques, including how to unlock the locked screen in an infected system (with a demo video).

KillDisk demands a pretty high ransom: 222 Bitcoins (around US$170,000).

The KillDisk ransom note. 

KillDisk is data-wiping malware, and is generally used by other malware to hide their artifacts from an infected system. BlackEnergy is one brand of malware that uses KillDisk.

Recently, the author of KillDisk enhanced the malware by adding the ransomware capability. This ransomware targets both Windows and Linux systems. It encrypts files, blocks the screen, and demands an unusually high ransom. We analyzed the Windows variant and found some interesting things.

Analysis

During our analysis of KillDisk, we saw little file system activity. To remove its(or its component’s) execution traces from the infected system, KillDisk uses the Windows event utility (wevtutil). One statement from Microsoft about wevtutil:

“Wevtutil enables you to retrieve information about event logs and publishers. You can also use this command to install and uninstall event manifests, to run queries, and to export, archive, and clear logs.”

KillDisk executes these commands before starting its encryption process:

• wevtutil clear-log application
• wevtutil clear-log security
• wevtutil clear-log setup
• wevtutil clear-log system

This malware has a complex routine that decrypts the DLL names, API names, file extensions, process names, and other strings including the preceding commands. This screenshot illustrates:

Decryption routine.

KillDisk targets the following files:

.pdb .vbm .vbk .dat .crt .key .kdbx .bak .back .dr .bkf .cfg .fdb .mdb .accdb .gdb .wdb .csv .sdf .myd .dbf .sql .edb .mdf .ib .db3 .db4 .accdc .mdbx .sl3 .sqlite3 .nsn .dbc .dbx .sdb .ibz .sqlite .ova .vmdk .vhd .vmem .vdi .vhdx .vmx .ovf .vmc .vmfx .vmxf .hdd .vbox .vcb .vmsd .vfd .pvi .hdd .bin .avhd .vsv  .iso .nrg .disk .hdd .pmf .vmdk .xvd .dev .pem .jrs .cer .pvk .pfx .pd .pio .csr .crl .p7c .piz .p7b .spc .p7r .io .pyc .dwg .max .dxf .3ds .ai .conf .my .ost .pst .mkv .mp3 .wav .oda .sh .py .ps .ps1 .php .aspx .asp .rb .js .git .mdf .pdf .djvu .doc .docx .xls .xlsx .jar .ppt .pptx .rtf .vsd .vsdx .jpeg .jpg .png . tiff .msi .zip .rar  .7z .tar .gz .eml .mail .ml

After encryption, the files have the same extensions but the data is encrypted, with the addition of 0x98 bytes at the end of each file. The first 0x80 bytes are related to the key and the next 0x18 bytes are the ransomware message, shown below

           DoN0t0uch7h!$CrYpteDfilE

KillDisk also uses these 0x18 bytes as an infection marker, to avoid multiple encryptions of already locked files. The following screenshot shows the appended data in an encrypted file:

The appended data/signature in an encrypted file.

Whitelisting to avoid analysis

We have observed some malware use blacklisting methods to kill analysis tools: If they find antimalware or related applications, they will terminate that process. But this malware uses the opposite technique of whitelisting: It maintains a list of benign processes, checks the system for them, and stores their process IDs (PIDs) along with its PID. After generating the PID list, the malware again enumerates the running processes and terminates those that are not on its generated PID list.

The following chart illustrates both blacklist and whitelist techniques:

                  Blacklist flowchart.                                                             Whitelist flowchart.

The whitelist technique works pretty well under automation environments such as the Cuckoo sandbox, etc.

Debugger evasion via whitelist

The malware retrieves its PID using the GetCurrentProcessId function so that while debugging the process in any debugger—OLLY, IDA, etc.—the function will return the malware’s PID and not the debugger’s. Thus, the PID whitelist created by the malware will not contain the debugger’s PID. When the malware executes its termination routine using TerminateProcess API, the debugger’s process will be killed.

The following screenshot shows disassembly of the code that terminates calc.exe because the process name is not on malware’s whitelist.

Terminating calc.exe.

However, we see not only the termination of the debugger process, but also of the child-sample process. We did not expect this behavior because the malware is using the TerminateProcess() API, which kills only the specified process not child processes.

Why are the child processes also terminated? It’s because of how the debugger creates its child processes. The debugger creates its child processes using specific creation flags related to debugging. The debugger uses the DEBUG_ONLY_THIS_PROCESS/DEBUG_PROCESS flag while calling the CreateProcess() API. Due to this flag, when the parent process gets terminated, the child processes die as well.

KillDisk’s whitelist consists of Windows and antimalware process names, including McAfee products.

Why are antimalware process names part of the malware’s whitelist? It may be because AV products generally use protection techniques so that other processes can’t kill their processes, and they may check on any process that wants to kill their processes. We think the malware author does not want to give the AV processes any indication of the malware’s existence.

The whitelisted process names:

smss.exe, csrss.exe, wininit.exe, services.exe, lsass.exe, lsm.exe, svchost.exe, winlogon.exe, explorer.exe, dwm.exe, wuauclt.exe,spoolss.exe, spoolsv.exe, taskhost.exe, conhost.exe, shutdown.exe, avp.exe, avpui.exe, ekrn.exe, egui.exe, mfemmc.exe, mfefire.exe, mfevtps.exe, pefservice.exe, mcsvhost.exe, msascui.exe, msmpeng.exe, mpcmdrun.exe

There is a typo in this list related to one McAfee process name. Our mfemms.exe is part of the McAfee Management service, but the malware looks for the process name mfemmc.exe.

Conclusion

KillDisk is new to the world of ransomware. It has implemented a whitelisting technique to protect itself, although it looks unstable because it kills all the other processes in the system. This malware has some coding bugs but can still badly harm its victims by encrypting files and demanding a huge ransom. This might be a beta version of this malware; we could see an updated version in the near future.

The second part of this post will contain our analysis of the malware’s other variants, along with some techniques including how to unlock the locked screen on an infected system (with a demo video).

McAfee products detect all known variants of this malware.

Thanks to Vikas Taneja for his valuable input.

The post Analyzing KillDisk Ransomware, Part 1: Whitelisting appeared first on McAfee Blogs.

This blog post was written by Sudhanshu Dubey.

At McAfee Labs we recently analyzed the ransomware KillDisk. In part 1 of this analysis, we discussed the basics of the malware and its whitelisting to protect itself. In this part, we will provide more information about the malware’s internals, this variant, and steps to unlock the ransomware lock screen.

Variant 1. This variant seems to be inspired by the TV series “Mr. Robot.” The lock screen uses the string “We are fSociety”:

The KillDisk ransom note.

While analyzing the encryption process of this variant, we observed some strange behavior. In contrast to Variant 2, this one behaved more like a destroyer, overwriting all the files with specific bytes. This step makes the data irrecoverable. Hence this variant’s block screen has no payment information. Instead, it appeals to victims to join them.

Variant 2. This variant works like normal ransomware, encrypting data files. It keeps the encrypted data in each locked file along with some more bytes including an infection marker. For more information about this variant, refer to Part 1 of this post.

Analysis

Although the encryption of both the variants is different, they show the same arguments and behavior based on those arguments. We found three arguments, which we shall discuss.

• -set
• -est
• -opt

KillDisk uses these arguments in key-value pairs and checks the values for the given key.

-est. The value of this argument is in minutes. This argument is used to store the “current time + minutes” in the registry.

-set. This argument is used to create service and registry entries. It receives the value in Date#Time format (for example, “-set=20.12.2016#05:00”) to fill the registry entry it creates. Before proceeding, it tries to get the handle of the event using OpenEvent() API, to check whether the malware is already executed. The event name has the following format:

                Global\{CLSID}

If the malware finds the event, it first cleans up the registry and deletes the service. It then recreates the service and the registry with updated values.

The malware uses the WinExec() API to execute the sc command, which creates a service whose binary path is set to itself, along with argument -opt=svc. (We will explain later.)

Calling WinExec() to create a service.

Both variants have different service names. The following screenshots show the services created by the variants.

Services installed by KillDisk (both variants).

Comparing the registry keys created by the variants, we infer that they have different names and paths. But the data in the registry values are the same and have been filled using the same method. KillDisk uses –set and –est argument values passed to the executable. It creates three registry values that store time, in TimeStamp format, that is, seconds since 1/1/1970. Here is more information about registry values:

First registry value             :            Current time

Second registry value        :            Time given with -set argument

Third registry value           :            Current time + minutes given in -est argument

The following screenshot shows the registry entries created by the malware when executing with the arguments -set=20.12.2016#05:00 -est=1440:

Registry entries.

Both the variants use different registry path, key and value names.

-opt. This argument has five values:

• frc
• chk
• cnc
• svc
• pic

The malware’s behavior depends on the values of this argument, which the malware keeps in encrypted form. Before comparing the argument values, KillDisk first decrypts them. The following code snippet shows the decryption and comparison of argument values:

Decrypting and comparing -opt argument values.

Let’s see how the malware behaves with different argument values.

-opt=pic. This value leads to the creation of the ransom note and locking the screen. The malware imports functions from GDI32.dll and User32.dll to design the image. It opens a window using the CreateWindow() API and then creates the image over it. The following code snippet from Variant 2 draws the ransom message on the screen:

Ransom note creation code in Variant 2. RGB (255, 83, 0) is a shade of orange.

After creating the ransom note, KillDisk starts a thread that keeps the window always on top by using the SetWindowPos() and SetForegroundWindow() APIs with specific arguments. The following code keeps the ransom note on top:

The HWND_TOPMOST flag places the window above all non-topmost windows, even after the window is deactivated.

-opt=frc. This value triggers the encryption process. Variant 1, the destroyer malware, overrides the files with 0x100 bytes that contain either the string “mrR0b07” or “fS0cie7y,” both inspired by the TV series “Mr. Robot.” The following screenshot shows the infected files:

Files infected files by Variant 2.

Before overwriting the files, the malware ensures that it has full access to the file. To get the access rights, it uses the Windows tool icacls.exe to modify the Access Control Lists for files and folders:

Modifying the Access Control List for all files from C drive.

• /T  =>  Traverse all subfolders
• /C  =>  Continue on file errors
• /Q =>  Quiet, suppress success messages
• /grant user: permission =>  Grant access rights to the user, F: Full access

This variant also creates 50MB garbage files (filled with null) on the Windows drive, to fill up the disk space. To keep the garbage files, it creates a folder at the root of the Windows drive with a CLSID name. To hide them from victims, the malware keeps the folder attribute to system hidden.

-opt=cnc. This value is used to clean the malware from the system. It uses the ControlService() API to send a stop signal to the service and the QueryServiceConfigA() API to get the file path from the service properties. The malware then deletes the registry entries and service from the system and also deletes the file.

-opt=chk. This value is likely to be used during debugging. It checks for the service and registry entries, and then prints accordingly.

-opt=svc. This value is given to the application while installing the service. It leads to the execution of the service handler function, registered through the RegisterServiceCtrlHandler() API. While debugging the code, we can see the code that executes commands to ping the local host and then delete itself with the help of the WinExec() API:

WinExec() executes commands to ping and delete itself.

On restarting, this malware deletes itself but it does not remove the service and remains installed.

Unlocking the screen

We successfully bypassed the ransom note block screen with the help of “Windows key + tab” feature, which is available in Windows 7 and later versions.

To use this technique, you’ll need Window 7 or later infected with KillDisk, a keyboard connected to the system, and good eyes. (You have to look carefully.) See our demo video.

Here are the steps to unlock the blocking screen of KillDisk:

Step 1: Press Windows Key + Tab. You will be prompted with the open applications window.

Step 2: Press “Windows Key + D” or switch to the desktop using Step 1.

Step 3: Open “run” using “Windows key + R” and check whether you have the run window using Step 1.

Step 4: Type “cmd” and hit enter. You will get the command prompt; confirm using Step 1.

Step 5: Type “tasklist” and Hit enter.

Step 6: Using “Windows Key + Tab,” check the process name on the list. (Good eyes needed.)

Because the malware killed all the other processes, it is likely all the processes will appear in a single command window. If not, change the command prompt size using the following command:

               mode con: cols=Value lines=Value                   // Update “Value” to fit your display

Step 7: After getting the process list, identify the malware process from the output of tasklist. If you know the malware process name, good. Otherwise you have to check the running processes from the whitelist previously mentioned and select the process that is not on the list. (That will likely be the malware process.)

Step 8: Get the PID of the malware process from the second column of the tasklist output.

Step 9: After getting the malware PID, kill the process using the following command:

               Taskkill /PID Malware_PID /F

After following these steps successfully, you will get your system back but the files will still be encrypted. This technique might work on other ransomware.

Conclusion

KillDisk is new to the world of ransomware. It has implemented a whitelisting technique to protect itself. We have discussed its internal working and a way to unlock the screen locked by ransomware.

McAfee products detect all known variants of this malware.

The post Analyzing KillDisk Ransomware, Part 2: Variants and Screen Unlocking appeared first on McAfee Blogs.

This blog post was written by Sudhanshu Dubey.

At McAfee Labs, we have recently observed a new variant of the Dorkbot botnet. Dorkbot is a well-known bot, famous for its various capabilities including backdoor, password stealing, and other malicious behavior. Dorkbot relies on social networking as its infection vector. In this post, we offer our analysis of this new variant.

The malware downloads the file from api[.]wipmania[.]net, a site that provides geolocalization services. The following screen shows the network traffic of the downloader file.

Downloader network communications.

The downloaded file is a wrapper compiled using Microsoft Visual C/C++ (2008 version). During our analysis we studied the wrapper file and extracted the inner file from the malware.

Analyzing the core

The inner file is also complied with a Microsoft Visual C++. The core is 48KB and has strings related to virtual machine names, registry entries, encrypted URLs, etc. as shown in the following:

Strings and encrypted URLs in the core file.

Anti-VM

Before performing any malicious activity, the malware executes code that checks for a virtual environment. It uses the SetupDiGetDeviceRegistryPropertyA() API, which helps in retrieving specified Universal Plug and Play device properties. A code snippet:

Searching for virtual machines using SetupDiGetDeviceRegistryPropertyA ().

As we see in the preceding snapshot, the malware passes the third argument as 0xC (SPDRP_FRIENDLYNAME), which retrieves the friendly name of the device. It then checks the device name with the strings related to virtual machines, for example, vbox, qemu, vmware, and virtual hd. If the malware finds any of these strings, indicating the presence of a virtual environment, it will terminate itself.

After passing the VM check, the malware checks the current working directory. It compares the file path with the desired path from %appdata% with the folder name in GUID format, for example, %appdata%/{GUID}. The following assembly code shows the malware code that checks the file path.

File execution path check.

If the file is executed from a different path, the malware considers the event as its first execution. In the first execution, the malware sets up its environment: file drop, registry entries, etc. The malware creates a directory in %appdata% and copies itself. It uses a custom function and the StringFromGUID2() API to get the folder name in GUID format. The dropped file and path is shown in the following:

The malware copies itself to %appdata%.

Dorkbot also creates a Run registry entry and task to persist on the system, setting the execution file path with the dropped file mentioned above. The registry entry created by the malware:

Dorkbot’s registry entry.

The malware also creates a task that triggers when the user logs on, executing the malware file.

After successful installation of registry and schedule tasks, the malware uses process hollowing to execute its code as svchost.exe and bypass application-level whitelists.

The malware creates svchost.exe.

After injecting itself into svchost.exe, Dorkbot calls ZwQueueApcThread(),an undocumented API used to queue an asynchronous procedure call (APC) routine (the malware’s remote code) on a current remote thread. (APCs are functions that execute asynchronously in the context of a particular thread.) ZwQueueApcThread allows the caller to specify three arguments that will be passed to the thread, including the thread routine. The malware sends a routine address different from the address of the entry point of the file, resulting in communication with the control server.

The injected code first executes the relocation code, making the injected code compatible with the new base address. After relocating the code, the malware ensures it is kept active in the system—even after being killed manually—by injecting a watchdog code in already running processes. One strange thing we observed is that before injecting the watchdog code, the malware checks for the process names TeamViewer and tv_w32.exe. If the malware finds either of them, it does not inject its code into that process.

Process enumeration and watchdog code injection.

Dorkbot enumerates the running processes and tries to open them with 0x10047A flag/permissions related to remote memory creation, reading and writing to memory. Definitions of the flags:

0x100000    => Synchronize
0x400     => QueryInformation
0x70     => VirtualMemoryRead + VirtualMemoryWrite + DuplicateHandle
0xA     => VirtualMemoryOperation + CreateThread

The watchdog code has some API calls that Dorkbot needs to update to make its code compatible with the remote process. Dorkbot updates the placeholders in the code that are related to API addresses and the malware’s process ID. Along with the watchdog code, the malware also inject its file path, referenced by the code, to restart the process. The following screen shows the watchdog code before and after modification:

Injected watchdog code: before and after modification.

The injected code uses the WaitForSingleObject() API to wait infinitely for malware process. It provides the malware’s process ID as the first argument and infinite time as the second argument. If the malware process is killed, Dorkbot signals to WaitForSingleObject () and the injected code proceeds. After getting the signal, the injected code executes CreateProcessW () API and again creates the malware process.

As we mentioned, the malware also injects the malware’s file path to the remote process to restart its execution if it is killed manually. But as we see in the preceding screen, we cannot find any address referencing the malware file path. This is because the malware passes the file path’s address as an argument to the CreateRemoteThread() API and in the code is referenced with the help of the EBP register ([EBP + 8]).

CreateRemoteThread arguments.

Network communications

For communications, the malware contains a list of encrypted URLs. The malware decrypts this list and generates a list of URLs in the format %s%u.%s, which is also present in the malware itself. Here the first “%s” signifies the string “con,” “%u” signifies integers 1 and 2, and the subsequent “%s” signifies the decrypted URL. Thus the malware adds the prefixes con1. and con2. to each of the decrypted URLs.

Decrypted URL: abcxyz.com
Generated URLs: con1. abcxyz.com, con2. abcxyz.com

Data sent by the malware to its control server.

The first 4 bytes of the data is the fixed dword value hardcoded in the malware. These 4 bytes are also used while checking the received data from the server. The fifth byte of the data represents operating system major and minor versions. The sixth byte defines whether the OS is 32- or 64-bit. The value for this byte is either 0x20 or 0x40, the hex representations of 32 and 64, respectively.

The next part is the hex data, defined as a character, for example, 0x41 stands for for “A” and is represented as 4 and 1. This part of the data is the union of the computer name and the calculated hash data separated by #. The malware uses the format specifier “%s#%s,” in which the first part is the computer name and the latter the hash value. Following this data is the word value (0x444E in this case), which is taken from the particular offset in the file. The last part of the data is derived from the current time and the output of the GetTickCount () API.

After sending the data to the server, the malware is ready to receive data. Because the URLs are not currently active, we did not receive any data from the server during our analysis. However, from the assembly code, we can see that the malware expects the data from the server in a particular format. The following assembly code snippet shows the checks performed by the malware on the received data.

Received data checks.

The WS2_32.recv () API receives data from a connected socket and returns the number of bytes received. The malware checks the return value of the API, which is the length of bytes received from server with the value 205; that is, the malware expects the data from control server to be 205 bytes in length. After checking the number of bytes, it evaluates the first 6 bytes of the data. It compares the first 4 bytes with the fixed dword value (18273645 in this case), which it used while sending the data. (See the screen of data sent to the control server.) The malware expects the fifth and sixth bytes to be 1 and 0, respectively.

The inactive URLs prevented us from going further with our analysis. We shall post new information when available.

McAfee products detect this variant of the malware.

The post Analyzing a Fresh Variant of the Dorkbot Botnet appeared first on McAfee Blogs.

Cedric Cochin teamed with Brook Schoenfield on this article

Updated March 29, 2017

McAfee has been investigating the impact of the so-called “DoubleAgent zero-day” technique of Windows debugging capabilities announced on 22 March 2017.

This injection technique uses a Microsoft Windows debugging feature that requires administrative privileges.  On the fly debugging is designed to be used with all Microsoft Windows executables. It is not specific to Anti-virus products in general, nor McAfee products in particular.

Techniques using IFEO (Image File Execution Options) have been known for a number of years, as part of a continuing process to research and evaluate security related techniques against software and hardware that we all depend upon.  For example, similar techniques manipulating the Windows process debugging registry key have been publicly discussed for a number of years.

This blog is not about the validity of any form of IFEO attack. Nor are we discussing the advantages of this attack over the myriads of approaches that would allow for the attacker to misuse a Windows device. Once an attacker gains administrative privileges on a Windows machine through whatever means, which attacks the attacker may choose lies outside of this analysis.

Rather, this analysis attempts to establish the resilience of McAfee endpoint solutions to this type of injection attack, to enumerate the mechanisms that are available to McAfee’s customers to mitigate or negate such attacks, and the ability of our solutions to expose such attack attempts.

McAfee software fundamentally must rely on the underlying operating system. Where techniques are identified that could impact the integrity of software through operating system mechanisms such as IFEO, McAfee software must implement detective and protective mechanisms.   In this particular technique for example, we have implemented measures into our most up-to-date consumer and enterprise products that would prevent execution of injected McAfee binaries from malicious parties.

When it comes to our endpoint protection solutions and their ability to protect their own processes, there are multiple layers of protection at play.

For the most recent Endpoint Security Solution (ENS), McAfee offers three mechanisms:

1. Self-protection rules to prevent the creation of IFEO registry keys
2. Self-protection rules to prevent process injection from untrusted processes
3. Module sanitization to validate that a module (DLL) is validly signed by a trusted authority before loading the DLL (irrespective of the load mechanism, including injection)

You can find details about process injection self-protection (#2) and module sanitization (#3) in the following KB https://kc.mcafee.com/corporate/index?page=content&id=KB88085

Module sanitization (#3) is enforced by default in our ENS (Endpoint Security Solution).

Self-protection rules for registry (#1) come in different flavors depending on the McAfee product installed. The default rules shipped with the product protect core McAfee services from allowing IFEO keys to be created. Since the current shipping rules focus on core services, we pushed an update to add exhaustive coverage of all product binaries for each product that uses McAfee’s Anti-Malware Core (AMCore) technologies, which includes ENS 10.2. We suggest that customer ensure that they have upgraded to DAT 2932.0.

For products using VirusScan Core (VSCore), rules can be manually added.

The manual rules for Virus Scan Enterprise (VSE) can be found in the following KB https://kc.mcafee.com/corporate/index?page=content&id=KB89030

The manual rules for Host Intrusion Prevention (HIPS) can be found in the following KB https://kc.mcafee.com/corporate/index?page=content&id=KB89032

In addition to covering an exhaustive list of McAfee binaries, the update for the self-protection registry rules (#1), will also include coverage against a technique variant in which a malicious IFEO key has been constructed elsewhere and then renamed (IFEO rename vector).

Depending of the IFEO (Image File Execution Options) injection target, the mechanism blocking the attack may differ. If the target is protected by self-protection registry rules the attack will be mitigated. If the target is not protected by self-protection registry rules, then the injection will occur but then McAfee’s module sanitization, where enforced, will block the attempted load and revoke trust for the injected process.

In the worst-case scenario for ENS, if the registry entry is created and the injection occurs, the process will fail to launch because the load of the malicious DLL will be denied. The McAfee ENS processes will not allow the malicious module to execute.

McAfee products also offer generic protection that would prevent such attack on other non-McAfee processes.In the context of ENS, customers can enforce the “Hijacking .EXE or other executable extensions” rule, which would prevent the creation of any [program].exe key under IFEO. Dynamic Application Containment (DAC) would also restrict contained processes from creating IEFO keys.

It is important for customers to note that before the IFEO keys may be manipulated, an attacker must first gain entrance to a Windows system. If the user account has not been given administrative privileges, then an additional step must be taken by the attacker to achieve these privileges. There are numerous techniques for achieving each of these steps.

Both VSE and ENS have been designed to identify and prevent techniques used by attackers to gain a presence under Windows and to stop attacker elevation of privileges to System Administrator. Customers are always advised to keep their McAfee DAT file updated to the latest version, to use the latest versions of McAfee products, and to patch Windows swiftly whenever Microsoft issues a security update. The vast majority of the entrances to intrusion (Windows and otherwise) has typically been through issues where an available fix has not been applied (patched).

We will continue research into those techniques that target hardware and software that we rely upon.  This is crucial into providing customers the confidence to rely upon systems that their businesses, and homes have grown to depend upon.

References:

https://kc.mcafee.com/corporate/index?page=content&id=KB88085

https://kc.mcafee.com/corporate/index?page=content&id=KB89030

https://kc.mcafee.com/corporate/index?page=content&id=KB89032

The post Update: Technical McAfee Detail On DoubleAgent appeared first on McAfee Blogs.

This post was written by Brook Schoenfield and the Advanced Threat Research Team.

A series of exploitable conditions have been uncovered in Apache Struts. One of these, CVE-2017-9805, allows unauthenticated execution of attacker code (aka remote code execution). This issue has already been weaponized into attack kits such as Metasploit and exploitation has been seen “in the wild”; that is, attackers are attempting to take advantage of the flaw.

Apache Struts is a popular open-source component that is used in numerous websites across the Internet, which makes a remote code execution vulnerability very concerning. Speculation is widespread about this issue’s exploitation.

CVE-2017-9805 describes a vulnerability in Apache Struts 2.5.12 that could be subject to a malware attack or other vector of attack designed to take advantage of the vulnerability. To our knowledge, Apache Struts 2.5.12 is not used in McAfee enterprise products as delivered by McAfee.

To demonstrate how easy it is to exploit the vulnerability, we created a little demo in which we take ownership of a vulnerable system. You can watch the video here.

To have an indication of the volume of attacks, the Advanced Threat Research (ATR) team set up a “honeypot” system to attract attack attempts. After less than two hours online, the ATR honeypot system recorded two attacks. One of the attackers attempted to run the Windows command line (cmd.exe) on our Linux box; the other attacker attempted to create a reverse shell toward his machine. If that had been successful, he could have gained full control of our system. Of course, our honeypot setup does not allow a compromise.

McAfee handles reported vulnerabilities in accordance with our product security practices. McAfee adheres to international product incident practices, including CVSS Version 3.0 calculation and CVE assignment.

McAfee actively encourages customer engagement and welcomes specific requests for clarification about our software security process.  There are some things we do not disclose, such as lists of vulnerabilities found through internal investigations or automated testing tools.

For external communications, we publish a security bulletin to all customers of an affected McAfee product as soon as McAfee’s security vulnerability team has confirmed that the vulnerability is critical, and after McAfee has determined appropriate mitigation for the vulnerability. (“Critical” means greater than or equal to CVSS 8.5.) The bulletin may address mitigations, workarounds, and updates. Please see McAfee’s Product Security Bulletins for more information.

The post McAfee Demos Ease of Exploiting Recent Apache Struts Vulnerability appeared first on McAfee Blogs.

The post KRACKs Against Wi-Fi Serious But Not End of the World appeared first on McAfee Blogs.