Attackers looking to add IoT devices to their botnets are increasingly adding vulnerability exploitation to their attack arsenal, Netscout researchers warn. Instead on just relying on a list of common or default passwords or brute-forcing attacks, they are taking advantage of the fact that IoT devices are rarely updated and manufacturers take a lot of time to push out fixes for known flaws. Currently under exploitation In November 2018, the company detected many exploitation attempts … More →
Adobe has released an out-of-band security update for Flash Player that fixes two vulnerabilities, one of which is a zero-day (CVE-2018-15982) that has been spotted being exploited in the wild. About the vulnerability (CVE-2018-15982) CVE-2018-15982 is a use-after-free in the Flash’s file package com.adobe.tvsdk.mediacore.metadata that can be exploited to deliver and execute malicious code on a victim’s computer. It was flagged on November 29 by researchers with Gigamon Applied Threat Research (ATR) and Qihoo 360 … More →
For the past couple of years, Office documents have largely replaced exploit kits as the primary malware delivery vector, giving threat actors the choice between social engineering lures and exploits or a combination of both.
While today’s malicious spam (malspam) heavily relies on macros and popular vulnerabilities (i.e. CVE-2017-11882), attackers can also resort to zero-days when trying to compromise a target of interest.
In separate blog posts, Gigamon and 360 Core Security reveal how a new zero-day (CVE-2018-15982) for the Flash Player (version 22.214.171.124 and earlier) was recently used in targeted attacks. Despite being a brand new vulnerability, Malwarebytes users were already protected against it thanks to our Anti-Exploit technology.
The Flash object is embedded into an Office document disguised as a questionnaire from a Moscow-based clinic.
A dot reveals an embedded (and hidden) ActiveX object
Since Flash usage in web browsers has been declining over the past few years, the preferred scenario is one where a Flash ActiveX control is embedded in an Office file. This is something we saw earlier this year with CVE-2018-4878 against South Korea.
Victims open the booby-trapped document from a WinRAR archive that also contains a bogus jpeg file (shellcode) that will be used as part of the exploitation process that eventually loads a backdoor.
As Qihoo 360 security researchers noted, the timing with this zero-day attack is close to a recent real-world incident between Russia and Ukraine. Cyberattacks between the two countries have been going on for years and have affected major infrastructure, such as the power grid.
Malwarebytes users were already protected against this zero-day without the need to update any signatures. We detect the malware payload as Trojan.CrisisHT.APT.
Adobe has patched this vulnerability (security bulletin APSB18-42) and it is highly recommended to apply this patch if you are still using Flash Player. Following the typical exploit-patch cycle, zero-days often become mainstream once other attackers get their hands on the code. For this reason, we can expect to see this exploit integrated into document exploit kits as well as web exploit kits in the near future.
Over the course of this week, some printers have been printing out a strange message asking people to subscribe to PewDiePie's YouTube channel. The message appears to be the result of a simple exploit that allows printers to receive data over the internet, including print commands. A person with the online handle TheHackerGiraffe has claimed responsibility for the attack.
More than 100,000 websites were affected by a vulnerability in a WordPress plugin that was designed to help site owners comply with the General Data Protection Regulation (GDPR).
Researchers from Wordfence also reported evidence of attacks in which malicious third parties installed their own administrator accounts on various sites. Though the full scope of how cybercriminals might use this access is unknown, it could enable them to install malware and hijack sites to use in phishing schemes.
The plugin, called WP GDPR Compliance, was initially removed from a plugin repository after the WordPress exploit was discovered. A patched version has since been made available.
WordPress Exploit Enables Attackers to Hijack Websites
WP GDPR Compliance was created to address some requirements in the legislation around requests for data access and how data is deleted from WordPress-hosted sites. A bug in the system that registers new users, however, enables threat actors to create their own accounts. This gives them full privileges to control what happens on the site and lets them cover their tracks by disabling the same feature and locking out legitimate site owners.
A second use of the WordPress exploit involves manipulating WP-Cron, the plugin’s task scheduler, which enables attackers to create other entry points through which to take control of a site.
This WordPress exploit affects WP GDPR Compliance versions up to and including 1.4.2. The patched version, 1.4.3, is now available within the WordPress plugin repository.
How Can Site Owners Protect Their Accounts?
Along with theme directories, plugins are a highly popular avenue for attack on WordPress sites. According to IBM X-Force, for example, directory references to “plugins” were found in close to 40 percent of the WordPress URLs where malware or other files had been discovered.
The risks associated with the WP GDPR Compliance plugin reinforce the importance of proactive patching. However, security experts also suggest proactively scanning such sites for potential anomalies, which could include changes in files or, in this case, new admin accounts.
Marcin Noga of Cisco Talos discovered this vulnerability.
Sophos patched two vulnerabilities in Sophos HitmanPro.Alert in version 126.96.36.1999. We publicly disclosed these issues last week here, Cisco Talos will show you the process of developing an exploit for one of these bugs. We will take a deep dive into TALOS-2018-0636/CVE-2018-3971 to show you the exploitation process.
Sophos HitmanPro.Alert is a threat-protection solution based on heuristic algorithms that detect and block malicious activity. Some of these algorithms need kernel-level access to gather the appropriate information they need. The software's core functionality has been implemented in the `hmpalert.sys` kernel driver by Sophos. This blog will show how an attacker could leverage TALOS-2018-0636 to build a stable exploit to gain SYSTEM rights on the local machine.
During our research, we found two vulnerabilities in the `hmpalert.sys` driver's IO control handler. For the purposes of this post, we will focus only on TALOS-2018-0636/CVE-2018-3971, an escalation of privilege vulnerability in Sophos HitmanPro.Alert. First, we will turn it into a reliable write-what-where vulnerability and then later into a fully working exploit.
First, we use the `OSR Device Tree` tool (Figure 1) to analyse the `hmpalert.sys` driver's access rights.
Figure 1. Device Tree application showing hmpalert device privilege settings
We can see that any user logged into the system can obtain a handler to the `hmpalert` device and send an I/O request to it. Keep in mind for building this exploit, as we mentioned in the original vulnerability blog post, the I/O handler related to this vulnerability is triggered by the IOCTL code `0x2222CC.` The vulnerable code looks similar to the one below.
Figure 2. Body of a vulnerable function
The nice thing is that we fully control the first three parameters of this function, but we do not control the source data completely (e.g. the `srcAddress` needs to point to some memory area related to the lsass.exe process) (line 12).
Additionally, data read from the lsass.exe process (line 23) is copied to the destination address the `dstAddress` parameter is pointing to (line 33).
With this basic information, we can construct the first proof of concept exploit to trigger the vulnerability:
Figure 3. Minimal proof of concept to trigger the vulnerability
This looks like it could work, but it's not enough to create a fully working exploit. We need to dig into the `inLsassRegions` function and see how exactly the `srcAddress` parameter is tested. We have to check if we will be able to predict this memory content and turn our limited `arbitrary write` access into a fully working `write-what-where` vulnerability.
Controlling the source
We need to dive into the `inLsassRegions` function to get more information about the `srcAddress` parameter:
Figure 4. The function responsible for checking if the `srcAddress` variable fits in one of the defined memory regions.
We can see that there is an iteration over the `memoryRegionsList` list elements, which are represented by the `memRegion` structure. The `memRegion` structure is quite simple — it contains a field pointing to the beginning of the region and a second field that's the size of the region. The `srcAddress` value needs to fit into one of the `memoryRegionsList` elements boundaries. If this is the case, the function returns 'true' and the data is copied.
The function will return 'true' even if only the `srcAddress` value fits between the boundaries (line 21). If the `srcSize` value is larger than an available region space, the `srcSize` variable is updated with the available size line 26. The question is: What do these memory regions represent, exactly? The `initMemoryRegionList` function will give us an idea.
Figure 5. Initialization of memory regions list.
We can see that the context of a current thread is switched to the `lsass.exe` process address space and then the `createLsaRegionList` function is called:
Figure 6. Various memory elements of the lsass.exe processes are added to the memory regions list.
Now we can see that the memory regions list is filled with elements from the `lsass.exe` PEB structure. There are ImageBase addresses regarding loaded and mapped DLLs added to the list, including the SizeOfImage (line 31), along with other information. Unfortunately, the `Lsass.exe` process is running as a service. This means with normal user access rights, we won't be able to read its PEB structure, but we can leverage the knowledge about the mapped DLLs in the exploit in the following way: System DLLs like `ntdll.dll` are mapped into each process under the same address, so we can copy bytes from the `lsass.exe` process memory region from these system DLLs into the memory location pointed to by the `dstAddress` parameter. With that in mind, we can start creating our exploit.
This is not a typical `write-what-where` vulnerability like you see in the common exploitation training class, but nevertheless, we don't need to be too creative to exploit it. The presented exploitation process is based on the research presented by Morten Schenk during his presentation at the BlackHat USA 2017 conference. It also includes modifications from Mateusz "j00ru" Jurczyk, which he included in his paper "Exploiting a Windows 10 PagedPool off-by-one overflow (WCTF 2018)." With a few changes, we can use j00ru`s code, WCTF_2018_searchme_exploit.cpp, as a template for our exploit. These changes include:
Removing entire codes related to pool feng-shui.
Writing a class for memory operations using the found primitives in the hmpalert.sys driver.
Updating the important exploit offsets based on the ntoskrnl.exe and the win32kbase.sys versions.
Then, we will be able to use the mentioned strategy from Morten and Mateusz:
Leak addresses of certain kernel modules using the NtQuerySystemInformation API — We assume that our user operates at the `Medium IL` level.
Overwrite the function pointer inside `NtGdiDdDDIGetContextSchedulingPriority` with the address of `nt!ExAllocatePoolWithTag.`
Call the `NtGdiDdDDIGetContextSchedulingPriority`(`=ExAllocatePoolWithTag`) with the `NonPagedPool` parameter to allocate writable/executable memory.
Write the ring-0 shellcode to the allocated memory buffer.
Overwrite the function pointer inside `NtGdiDdDDIGetContextSchedulingPriority` with the address of the shellcode.
Call the `NtGdiDdDDIGetContextSchedulingPriority`(`= shellcode`).
The shellcode will escalate our privileges to SYSTEM access rights after copying a security TOKEN from the system process to our process.
Tested on Windows: Build 17134.rs4_release.180410-1804 x64 Windows 10
To simplify memory operations, we wrote a class using the found memory operation primitives in the hmpalert.sys driver.
Figure 7. The memory class implementation
The core `copy_mem` method is implemented like this:
Figure 8. The Memory::copy_mem method implementation
We initialize a couple of important elements inside the class constructor:
Figure 9. The memory class constructor implementation
We can use the `write_mem` method to write a certain value to a specific address:
Figure 10. The memory class write_mem method implementation
We can not directly copy bytes defined in the `data` argument. Therefore, we need to search for each byte from the `data` argument in the `ntdll.dll` mapped image and then pass the address of the byte to the hmpalert driver via the `srcAddress` parameter. That way, byte by byte, will overwrite the data at the destination address `dstAddress` with bytes defined in the `data` argument. We can easily overwrite necessary kernel pointers and copy our shellcode to the allocated page by using this class:
Figure 11. Shellcode copy operation to an allocated page.
The rest of the exploit is straightforward, so we can leave the implementation as a task for the interested reader.
Fail — Zero-day protection really works!
Armed with a fully working exploit, we are ready to test it. If it works, we should get SYSTEM level privileges.
Figure 12. The elevated console is detected and terminated by the HitmanPro.Alert.
It looks like our exploit has been detected by the `HitmanAlert.Pro's` anti-zero-day detection engine. Looking at the exploit log, it seems that its entire code was executed, but the spawned elevated console has been terminated.
Figure 13. At the end of the exploit, the console with elevated rights is executed.
We can see in the system event log that HitmanAlert.Pro logged an exploitation attempt and classified it as a local privilege escalation:
Figure 13. Event log showing that it was logged by HitmanAlert.Pro as an attempted privilege escalation.
Using a zero-day to bypass anti-zero-day detection
We know that our exploit works correctly, but the problem is that it's terminated by the anti-exploitation engine during an attempt to spawn the elevated shell.
We can look at HitmanAlert.Pro's engine to find out where this function is implemented. The Microsoft Windows API provides the `PsSetCreateProcessNotifyRoutine,` which can be used to monitor process creation in the OS. Searching for this API call in the `hmpalert.sys` driver, IDA shows a couple of calls.
Figure 14. Registration of `ProcessNotifyRoutine` via `PsSetCreateProcessNotifyRoutine` API.
We do see some places where it registers the callback routine. Let's look into the implementation of the `ProcessNotifyRoutine`. While stepping through it, we found the following code:
Figure 15. An implementation of `ProcessesKiller` function, responsible for the termination of potentially malicious processes.
At line 44, you can see a call to the routine that's responsible for killing "dangerous/malicious" processes. As we can see at line 5, there is a condition checking whether a global variable `dword_FFFFF807A4FA0FA4` is set. If it is not set, the rest of the function code will not be executed. All we need to do is to overwrite the value of this global variable with a value of zero to avoid termination of our elevated console. The final portion of the exploit looks like this:
Figure 16. Overwriting a global variable in the `hmpalert.sys` driver to trick the `ProcessesKiller` function, allowing our spawned elevated console to execute.
Time to test our exploit in action.
Final exploit - LPE Windows 10 x64 / SMEP bypass
Due to the many anti-exploitation features in today's operating systems, weaponizing vulnerabilities can often be arduous, but this particular vulnerability shows that we can still use some Windows kernel-level flaws to easily exploit bugs in modern Windows systems. This deep dive showed how an attacker could take a vulnerability and weaponize it into a stable, usable exploit. Talos will continue to discover and responsibly disclose vulnerabilities on a regular basis and provide additional deep-dive analysis when necessary. Check out or original disclosure here to find out how you can keep your system protected from this vulnerability.
This report focuses on a threat group that we have designated as
APT28. While APT28’s malware is fairly well known in the cybersecurity
community, our report details additional information exposing ongoing,
focused operations that we believe indicate a government sponsor based
In contrast with the China-based threat actors that FireEye tracks,
APT28 does not appear to conduct widespread intellectual property
theft for economic gain. Instead, APT28 focuses on collecting
intelligence that would be most useful to a government. Specifically,
FireEye found that since at least 2007, APT28 has been targeting
privileged information related to governments, militaries and security
organizations that would likely benefit the Russian government.
In our report, we also describe several malware samples containing
details that indicate that the developers are Russian language
speakers operating during business hours that are consistent with the
time zone of Russia’s major cities, including Moscow and St.
Petersburg. FireEye analysts also found that APT28 has systematically
evolved its malware since 2007, using flexible and lasting platforms
indicative of plans for long-term use and sophisticated coding
practices that suggest an interest in complicating reverse engineering efforts.
We assess that APT28 is most likely sponsored by the Russian
government based on numerous factors summarized below:
As with the APT1 report, we recognize that no single entity
completely understands the entire complex picture of intense cyber
espionage over many years. Our goal by releasing this report is to
offer an assessment that informs and educates the community about
attacks originating from Russia. The complete report can be downloaded
Joomla has been one of the most popular CMS for a long time. It powers a huge number of sites. That’s great! The flip side of this fact is Joomla has been very popular for a long time and there are still very many sites that use older versions of Joomla as well as older version of Joomla components. For example, the 1.5.x branch of Joomla (2008-2010) still has a noticeable share in live Joomla sites.
Old versions may work well for your site but they have multiple well known security holes, so they are the low hanging fruit for hackers. Let me show this using a real world example.
There is a JCE component — a fancy content editor that can be found almost on every Joomla site. It has a well known security hole that allows anyone to upload arbitrary files to a server.
You can easily find a working exploit code for this vulnerability. What it does is:
Checks whether a vulnerable version of JCE is installed (2.0.11, 2.0.12, 2.0.13, 2.0.14, 2.0.15, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124)
Exploits the bug in the JCE image manager to upload a PHP file with a .gif extenstion to the images/stories directory
Then uses a JSON command to rename the .gif file to *.php.
Now you have a backdoor on a server and can do whatever you want with the site.
This is how this attack looks in logs (real example):
As I mentioned, JCE is a very popular component and there are still many sites that use old versions of this component. No wonder, hackers are scanning the Internet for such vulnerable sites. They reworked the exploit code for use in their automated tools that relentlessly test millions of sites, one by another. These days, I can find multiple requests with the “BOT/0.1 (BOT for JCE)” User-Agent string in logs of almost every site that I check, even in logs of sites that have never had Joomla installed.
I’d like to share some interesting statistics of a real site that had been hacked using this JCE hole and then was being routinely reinfected every day.
7,409 requests with the User-Agent “BOT/0.1 (BOT for JCE)” that came from 785 different IPs during the period of Dec 24th – Jan 24th (one month)
239 requests from 51 unique IP addresses during the last 24 hours
4 independent (uploaded different types of backdoors) successful infections during one day.
plus, multiple tests for other vulnerabilities.
As you can see, this is something that you can’t neglect or consider an insignificant threat. It’s silly to hope that hackers won’t find your site. Today hackers have resources to spider the Internet almost as efficiently as Google just about 10 years ago, so there is almost no chance your site will stay unnoticed. The only way to prevent the hacks is to be proactive: keep all software up-to-date and harden your sites.
In case of this particular JCE attack:
Make sure to upgrade your Joomla site to the most current version.
Upgrade JCE to the latest version. You can find download packages for all the three branches of Joomla here.
Protect all file upload directories and all directories that shouldn’t contain .php files. For example, place the following .htaccess file there to prevent execution of PHP files: <Files *.php>
deny from all
Try blocking requests with the “BOT/0.1 (BOT for JCE)” User-Agent string. Of course, this shouldn’t be considered as a real protection. Hackers can change the User-Agent string to whatever they want. But it can help keep some dumb annoying bots away from your site.
If, for some reason, you can’t upgrade your site at this moment, consider placing it behind a website firewall that will block any malicious traffic before it reaches your server. This is something that we call virtual patching in Sucuri CloudProxy.