Pwn2Own 2019 hacking competition is started and participants hacked Apple Safari browser, Oracle VirtualBox and VMware Workstation on the first day.
As you know I always cover results obtained by white hat hackers at hacking competitions, for this reason, today I’ll share with you the results of the first day of the Pwn2Own 2019.
Pwn2Own 2019 is the hacking competition organized by Trend Micro’s Zero Day Initiative (ZDI) that is taking place in Vancouver, Canada, alongside the CanSecWest conference.
This edition includes a novelty, for the first time in its history participants have been invited to hack a Tesla Model 3, the organization is offering up to $300,000 and a car for.
The overall prize pool is greater than $1 million and participants are very enthusiastic to take part in the competition.
On the first day, they were able to hack into Apple’s Safari web browser and the Oracle VirtualBox and VMware Workstation virtualization products earning a total of $240,000 in cash.
Amat Cama and Richard Zhu of team Fluoroacetate earned $55,000, and 5 points towards Master of Pwn, for an exploit targeting the Safari web browser. The security duo chained an integer overflow in the browser and a heap overflow that allowed them to escape the sandbox. The experts finally used a brute-force technique to escape the sandbox.
“They successfully exploited the browser and escaped the sandbox by using an integer overflow in the browser and a heap overflow to escape the sandbox. The attempt nearly took the entire allowed time because they used a brute force technique during the sandbox escape.” reads the official page of the Pwn2Own 2019 competition.
“The code would fail then try again until it succeeded. The demonstration earned them $55,000 USD and 5 points towards Master of Pwn.”
The same experts also earned $35,000 for hacking Oracle VirtualBox by triggering on the second attempt an integer underflow and a race condition to escalate privileges and execute arbitrary code.
Amat Cama and Richard Zhu also earned $70,000 for escaping a VMware Workstation virtual machine and executing code on the underlying host operating system.
It was a great day for the Fluoroacetate team that earned a total of $160,000 in just one day.
On the first day, another experts of STAR Labs who uses the handle anhdaden earned $35,000 for hacking Oracle VirtualBox by exploiting an integer underflow to escalate privileges and execute code on the underlying host. The integer overflow issue exploited by the expert is differed than the one discovered by Fluoroacetate.
The day one close with the Phoenhex & Qwerty team that earned $45,000 for a complete system compromise via an Apple Safari exploit with a kernel elevation. In order to exploit the flaw, the attackers need to trick victims into visiting a malicious website.
“By browsing to their website, they triggered a JIT bug followed by a heap out-of-bounds (OOB) read – used twice – then pivoted from root to kernel via a Time-of-Check-Time-of-Use (TOCTOU) bug. Unfortunately, it was only a partial win since Apple already know of one of the bugs used in the demo. Still, they earned themselves $45,000 USD and 4 points towards Master of Pwn.” reads ZDI.
If you want to receive news on the ongoing Pwn2Own 2019 competition stay tuned.
At the time of the public disclosure, Google did not reveal technical information about the Windows zero-day.
The CVE-2019-0808 vulnerability affects the windows Win32k component and could be exploited by an authenticated attacker to elevate privileges and execute arbitrary code in kernel mode. An attacker can chain the flaw with a web browser vulnerability to escape sandboxes.
The vulnerability only affects Windows 7 and Windows Server 2008 because Windows 10 includes implements mitigations that don’t allow its exploitation.
Now the researchers at Qihoo 360 shed the light on the flaw and the way to exploit it, they described the root cause with the following statement:
“After receiving the menu window object returned by the window procedure function, the xxxMNFindWindowFromPoint function does not effectively check the validity of its member tagPOPUPMENU, causing the subsequent MNGetpItemFromIndex function to trigger the NULL pointer deference.”
The experts explained how to trigger the flaw and provided details on how Microsoft has fixed the problem.
The researchers also developed a PoC exploit that have only partially disclosed. Anyway, the analysis published by the researchers includes step-by-step instructions on the main phases of the exploitation process.
Experts believe that the availability of this information could allow other threat actors to exploit the CVE-2019-0808 flaw in more attacks.
“Through the constructed POC, it is found that the vulnerability is triggered when the NtUserMNDragOver function is called under certain circumstances, causing NULL pointer dereference in win32k!MNGetpItemFromIndex.” concludes the experts. “The vulnerability uses the Windows kernel driver module win32k.sys to perform local privilege escalation. Afterwards, it can break through the restrictions of user privilege. In the meanwhile, it can also help attackers to escape sandbox to completely control the victim’s computer. ”
While we were thinking about a way to escalate privileges during a pen-test, we discovered that most Windows installations were vulnerable to binary planting.
A long time ago, while we were thinking about a way to escalate privileges during a pen-test, we discovered that most Windows installations were vulnerable to binary planting. We contacted Microsoft, but they claimed that it was not a product vulnerability since security had been weakened by 3rd party applications that allowed overly permissive file access. On the one hand this was correct, but on the other, those 3rd party applications (the publishers of which were also notified) were not the only ones to blame as the insecure DLL search path is definitively part of the operating system and tries to load another DLL from Microsoft which does not exist.
Anyway, sometime later I continued the research and start developing a tool in order to help detect similar vulnerabilities and exploit them. However, days are too short and I never managed to take the time to finish it. So, I decided to publish the few 0-days I still have on Windows in order to help other pen-testers while they still work.
The initial vulnerability that we discovered in October 2012 was related to the “Internet Key Exchange and Authenticated Internet Protocol Keying Modules”. Those modules are used for authentication and key exchange in Internet Protocol security. The problem was that they try to load a DLL which doesn’t exist. This leaves the operating system vulnerable to various binary planting opportunities that depend on the PATH environment variable.
In fact, the “IKE and AuthIP IPsec Keying Modules” service is started automatically under the “Local System” account and points to “svchost -k netsvcs” which then loads “IKEEXT.DLL”, which in turn attempts to call the missing “wlbsctrl.dll” file by looking in the following directories: the loading directory, %WINDIR%\System32, %WINDIR%\System, %WINDIR%, the current working directory, and %PATH%. If one of the folders from the PATH environment variable is writable, then any authenticated user can plant a nasty DLL file which will be executed as SYSTEM during the next reboot.
This binary planting can be exploited when a program gives too much access (e.g. Create Files / Write Data privilege for anybody) on a local subfolder that is ultimately added to the PATH environment variable. Such a problem is very frequent with the root folder since access permissions for files and subfolders are inherited from the parent directory when a directory is created in “C:\”. Members of the “Authenticated Users” group have the “Create Folders / Append Data” right on all directories created within the root folder, which may then offer an enticing privilege escalation vector. So, any member of the “Authenticated Users” group can escalate his privileges to “SYSTEM” when an application that does not restrict write access to its folder is installed and gets added to the system PATH environment variable. Something which occurs quite frequently. Additionally, many developers and sysadmins also modify the PATH manually to facilitate their daily duties or migration phases. This too will often permit an attacker to trigger the vulnerability.
From Microsoft’s point of view, the 3rd party vendors are to blame because the vendor’s installer didn’t remove the write permission on their application directory before adding it to the PATH. From the perspective of 3rd party vendors, Microsoft is to blame because Windows tries to search for another Microsoft DLL which doesn’t exist. While, in a sense, both are right, it is the end user who ultimately pays the price. Because neither Microsoft nor the 3rd party developers assumed their own responsibilities, Windows users stayed exposed for many years.
Others have since done a great job of automating the exploitation of the vulnerability, e.g.: “itm4n” created a PowerShell script to trigger the vulnerability by opening a dummy VPN connection with “rasdial” to force the vulnerable service to start. There is also a “ikeext_service” module in MSF thanks to “Meatballs”, which permits one to leverage an insecure path to plant your favorite Meterpreter.
Today the automated trigger is still far from being guaranteed and it often requires a reboot in order to load our malicious DLL as SYSTEM. This presents no issue for a Black Hat, but is quite limiting for a Red Team. So, the time had come to find other binary planting opportunities… This is why I started the Inseminator project, the goals of which were to:
Identify writable directories from the path.
Enumerate binaries involved by services which start as NT AUTHORITY\SYSTEM.
Generate a list of DLLs loaded by those services.
Parse those DLLs to identity other loading of DLLs and update the list accordingly.
Check if each of the DLLs in the list exists in a system directory.
Automate the exploitation by planting an arbitrary DLL in the right place with the right name and offering several payload opportunities.
Unfortunately, this project was put on stand-by for a long time and I couldn’t find the time to finish it. I will therefore publish today some raw findings.
Inseminator’s output sample
The most interesting binary planting opportunities are the ones which are related to system services, since they permit escalation to the highest level of privileges on the target. To identify them, I simply used a logger for the payload and created a bunch of testing DLLs with a command like this one:
for /F "tokens=*" %A in (BinaryPlantingList.txt) do copy poc.dll.logger64 c:\Python27\%A
It turns out that:
Upon startup the “svchost.exe” is executed with the “utcsvc” service group, which starts a single service called “DiagTrack” (i.e., the “Diagnostics Tracking Service”) by loading “C:\WINDOWS\system32\diagtrack.dll”. This library tries to load the missing DLL “diagtrack_wininternal.dll” several times per day.
The “diagtrack.dll” also tries to run the missing “WindowsPerformanceRecorderControl” and “diagtrack_win.dll” libraries from time to time (but less often than “diagtrack_wininternal.dll”).
The library “diagtrack_win.dll” is also called by the “Microsoft Compatibility Appraiser” system task, which is scheduled to run “C:\Windows\System32\CompatTel\diagtrackrunner.exe” at 3am by default (and runs whether a user is logged on or not).
The library “WindowsPerformanceRecorderControl.dll” is also invoked from time to time by other libraries, like from “C:\Windows\system32\TelLib.dll” or through the debugger engine with a call from “dbgeng.dll”.
The “Diagnostics Tracking Service” was initially pushed as an optional Windows 8.1 update (KB3022345) to collect personal data and send it back to Microsoft. However, these days this service is not really an option and is used by Microsoft to collect data about functional issues in most versions of Windows. So, it is maybe its fate to ultimately permit arbitrary code execution. This is yet another reason for end-users to not like this tracker. Moreover, it’s likely possible to trigger the call on demand by generating an error, since logs are collected when a functional problem is detected.
There is also some other insecure DLL loading brought by 3rd party applications. I, for example, have already witnessed McAfee VirusScan Enterprise engine trying to load a missing “mfebopa.dll”. A DLL which was initially intended to provide a behavioral “buffer overflow” protection, but in this case offered a substantial privilege escalation opportunity.
Tracking high-privileges libraries calls with DLL-based loggers
There are also some less interesting binary planting opportunities which still permit the loading of arbitrary libraries, but in the context of the current user. A vulnerability that is not as useful from a local privilege escalation perspective, but which may still open some doors on shared systems and kiosks. Firefox, for example, often tries to load the missing “dcomp.dll” library, and the ClickShare wireless presentation system from Barco always tries to load the Microsoft Direct3D library “d3d8.dll” which is not always present when users plug in the projector’s USB dongle.
Tracking low-privileges libraries calls with DLL-based loggers
Many 3rd party applications do contain a writable sub-folder which is part of the PATH environment variable. For example, I identified issues with Roxio, HP Digital Imaging, ACER eDataSecurity, Micros Systems OPERA, OpenView OmniBack, Novel Groupwise, IBM AppScan, Python, Perl, Ruby, TCL, PHP, MySQL, Zend, and many others. As a rule of thumb, development tools often permit an attacker to leverage these vulnerabilities.
In practice, the easiest way to get local admin rights on many Windows systems is to simply put your favorite DLL in a writable folder that is part of the %PATH% and give it the name of one of those missing system libraries. You then just need to wait and your code will be executed several times by the end of the day as NT AUTHORITY\SYSTEM (even if it’s a production server which is never rebooted).
The DLL will be executed by a system service and will therefore run in session 0, which is non-interactive. Since Vista, services are isolated that way to protect them from malicious code running in a user’s session (starting from session ID 1). However, this does not really present a problem to our exploit. If our payload tries to interact with the desktop (for example, by running a CMD), the “Interactive Services Detection” service will draw a blinking button on the taskbar and prompt the user to “view the message” and enjoy our code in the desktop from session 0. The “UI0Detect.exe” binary invoked by “Interactive Services Detection” has now been removed from Windows 10 v1803 and Windows Server 2019, but those OSes are not our targets here.
The Interactive Services Detection kindly permits us to interact with our payload running in session 0
Our planted DLL is running with the highest level of privileges
When we have our SYSTEM shell in session 0, we can then easily get another shell in the usual session 1, for example, with PSEXEC:
psexec -s -i 1 -d cmd.exe
We can then close our original shell and return to the standard user desktop to keep enjoying a SYSTEM shell.
After removing the DLL calls monitoring, here is what’s left in the payload. This quick and dirty code will permit you to compile a DLL that runs a local shell when it gets loaded:
Obviously, we might prefer opening a shell on a remote system instead of the local target, thus avoiding local interactions with the desktop in session 0.
I advise against directly using a reverse Meterpreter, since it would be caught by any AV. A preferred way is to simply open a socket and spawn a reverse shell to an attacker-controlled system, and then to play with Mimikatz or Meterpreter injection in a second phase. Here is another quick and dirty code example which does just that:
Be careful about your %PATH%! Pay attention to 3rd party applications which may silently add a writable directory to this environment variable (especially if they install on the root drive), and don’t make the same mistake yourself.
Here is another quick and dirty piece of code in Python 2 to help you identify writable folders in your %PATH%, where any missing DLL could be planted by a bad guy:
sysPath = "path"
filetest = "\\inseminator.wperm"
def is_writable(path): # Checking Write Permission
filehandle = open(path, 'w')
print("[+] Searching for writable folders within %PATH%")
require = os.environ[sysPath]
sys.exit(" [-] Unrecoverable error: %" + sysPath.upper() + "% variable is not defined!")
dicPath = os.environ[sysPath].split(";")
WritablePath = 
for item in dicPath:
if is_writable(item + filetest):
print " [-] Directory '" + item + "' is writable"
If any writable directory is found, you should either remove it from the %PATH% or harden ACLs to ensure authenticated users (and any other untrusted accounts) are unable to write inside.
It is also advised to create some dummy DLL files in %WINDIR%, since this directory has a higher priority than PATH folders but is only queried if the searched libraries are not present in either the loading directory or %WINDIR%\System32 and %WINDIR%\System. At a bare minimum, it is advised to create those fake libraries if they do not exist on your system:
To a lesser extent, it is also advised to create these dummy libraries:
That’s all for today. Happy planting!
About the Author: Frédéric BOURLA Frédéric began his career in 2000 as a Systems and Networks Engineer, and has increasingly specialized in IT Security over the years. After managing a Tier 4 PKI Data Center, he transitioned into the fields of Ethical Hacking and Computer Forensics. He ultimately dived into the world of DevSecOps for government solutions, and he is currently a Security Consultant in the Geneva region of Switzerland.
A team of specialists from Kaspersky Lab, an anti-virus company headquartered in Russia, discovered a 0-day vulnerability in Windows systems. Cybercriminals were actively exploiting this security problem in real targeted attacks.
According to Kaspersky Lab experts, they found a previously unknown vulnerability in Windows that was allegedly used to carry out targeted attacks by at least two cyber groups — FruityArmor and the recently discovered SandCat.
Using this vulnerability, an attacker could infiltrate the victim's network or device by attacking Windows 8 and 10. As a result of a successful attack, the cybercriminal got full control over the vulnerable system.
Kaspersky lab promptly notified Microsoft of the problem, which allowed the developers to release a patch that is already available to users.
"The discovery of this exploit shows that such expensive and rare tools are still of great interest to hacker groups. Organizations need to find solutions that can protect against such threats," says Anton Ivanov, Kaspersky Lab anti-virus expert.
While investigating the SiteGround Optimizer and Caldera Forms Pro plugins we have discovered a critical privilege escalation vulnerability.
It was not being abused externally and impacts over 500,000 sites. It’s urgency is defined by the associated DREAD score that looks at damage, reproducibility, exploitability, affected users, and discoverability.
A key contributor to the criticality of these vulnerabilities is that it’s exploitable by any user (it’s not restricted to privileged users – e.g., admins) and is easy to exploit remotely.
Security vulnerabilities are popping up all the time, and can put any business that uses technological assets at risk. In a nutshell, vulnerabilities represent the ideal opportunity for malicious actors to break into systems and wreak all types of havoc. From data theft to information compromise and beyond, vulnerabilities are a particularly pertinent issue for today’s enterprises.
According to current data, more vulnerabilities are coming to light than ever before:
• 2017 represented a record-breaking year for reported exploitable vulnerabilities, reported SecurityWeek. Overall, more than 20,000 security flaws were spotted over the course of the year, a more than 30 percent year-over-year increase. While this can be taken a number of different ways – creating heightened security risks, or more frequent reporting of vulnerabilities on the part of enterprise software users – this level of rising platform flaws is certainly concerning.
• Although numbers are still being tallied for 2018, a report from RiskBased Security noted that by August of last year, more than 10,000 vulnerabilities had been reported. This includes 3,000 potential flaws that many enterprises failed to patch.
“The severity of the vulnerabilities disclosed still remains significant, demanding organizations remain vigilant by implementing a comprehensive software vulnerability assessment and management plan,” stated RiskBased Security.
While it’s becoming more challenging to guard against the rising tide of vulnerabilities – particularly zero-day flaws – there are several key strategies enterprises can incorporate to help bolster their security.
Types of vulnerabilities and how they’re used for malicious activity
Before we delve into those strategies, though, it’s worth taking a look at vulnerabilities in action, and understanding how these software flaws can be leveraged by a malicious actor.
A traditional vulnerability, for example, is a programming error or other type of software issue that hackers can use to sidestep password protection or security measures and gain unauthorized access to legitimate systems. These problems are unfortunately pretty extensive, and new vulnerabilities that can be exploited by cybercriminals are being discovered by security experts all the time.
Where general vulnerabilities typically have security patches or updates available to repair them, this is not the case with zero-day vulnerability. Zero-days are brand new software issues that have only just been identified, and have not yet been patched by vendors. As Trend Micro explained, “that’s because the vendor essentially has zero days to fix the issue, or has chosen not to fix it.”
An undisclosed vulnerability, on the other hand, also represent a considerable threat to enterprise security. These are flaws that have been identified and reported, but are not yet disclosed to public users, giving vendors time to patch the issue.
In any of these cases, vulnerabilities can be leveraged by hackers to support unauthorized access, install malware, exfiltrate compromised data or modify existing files, launch a denial-of-service attack, or maliciously take over control of systems. This only scratches the surface – vulnerabilities provide an entryway for cybercriminals to conduct an array of different kinds of attack, all of which can impact an organization’s productivity, profits, customer relationships, vendor partnerships, and the company’s overall reputation.
Vulnerabilities represent considerable risk to enterprise security.
How to address vulnerabilities in the enterprise
There are several critical approaches today’s businesses and IT teams can take to safeguard their organization from software vulnerabilities.
Pay attention to current security research
Whenever a vulnerability is discovered and reported, security experts like Trend Micro will look to educate users on the software flaw, the potential risk and approaches businesses can use to protect themselves. One of the best ways to support an up-to-date security posture is by paying attention to this key research, and leveraging its insights for the good of the business.
“The threat researchers and data scientists in Trend Micro Research labs around the world identify and disclose new vulnerabilities across a wide range of platforms,” Trend Micro’s ebook explained of its in-house security research. “Using workflows and techniques refined through years of collaboration with our partners, our highly skilled team of researchers can reverse engineer a security threat and provide protection to our clients quickly.”
Trend Micro also supports the world’s largest bug bounty program – the Zero Day Initiative – enabling users and white hat hackers across the globe to report vulnerabilities in an effort to patch the issue as quickly as possible. Best of all, these individuals are rewarded for making reports – Apple, for instance, has offered up a $100,000 bounty for anyone who can successfully extract sensitive data from its Secure Enclave solution.
Be aware of updates and patches – and prioritize accordingly
In addition to reading up on the latest research from security solution providers and other experts, it’s also important that IT leaders be aware of patches and updates released by vendors.
Microsoft, for example, is known for its unofficial “Patch Tuesday,” as many of its software updates and patches are released on Tuesdays. Organizations that rely on Microsoft solutions should check for updates according to the vendor’s regular schedule.
However, as Trend Micro’s ebook pointed out, with so many patches being released by security and software vendors, it’s no longer possible for IT teams to keep up and install them immediately. This means there is potentially time for hackers to exploit identified vulnerabilities before the enterprise has time to apply the patch.
The solution here is to establish a prioritized patching process that takes into account:
• The severity of the patched issue. Microsoft and other vendors will rate vulnerabilities according to how critical they are to overall risk. More critical patches should be applied as soon as possible, whereas less critical updates can represent a lower priority.
• Vulnerabilities impacting your enterprise’s particular key software. Similarly, updates for software systems that are used on a daily basis within the enterprise, and provide essential functionality should be prioritized over other updates. A patch for a software that is only intermittently used, or only impacts a small number of users in a single department of the company, for instance, can be put on the back burner.
• Those currently being exploited. It’s important to prioritize patches for vulnerabilities that hackers are currently using to mount attacks.
“Focus on those vulnerabilities that are present within your operating systems, devices, and applications that are also actively being exploited in the wild,” Trend Micro’s ebook stated. “This significantly reduces the number of vulnerabilities that you need to patch while mitigating risks for your business.”
The IT team at an important company has just installed a vital update on all its corporate devices so that everyone can keep using them properly. The team and the organization’s management have every confidence in this new version. After all, why should they suspect that something could go wrong? Updates are standard procedure, and applying them is safe. What’s more, in many cases, they’re a vital part of cybersecurity.
However, something has caught the IT department off guard, and they send out a warning: a piece of malware has got through all their protections and has infected all the company’s computers. How could this have happened? A preliminary assessment points to that recently installed update. An investigation of the infection uncovers something worrying: the update contained a vulnerability that nobody, not even the software developers, had spotted. No one, that is, except the cyberattacker. This criminal is now well known on the Deep Web: he is the author of a new zero-day attack.
The window of opportunity
Coming across an unpatched vulnerability and using it to carry out an attack is the dream for many cyberattackers. Not only will a discovery of this type boost their standing in the cybercriminal community, but it also means that they will be able to personally benefit from the attack. This is precisely why zero-day attacks are so dangerous.
Time is not on the cyberattackers’ side: their window of opportunity between the discovery of the vulnerability and it being closed by cybersecurity providers or developers is limited. But not all attacks of this type are fixed so quickly. If the cyberattacker is discreet enough, companies can be exposed persistently through a vulnerability that they are unaware of. In previous blog posts we’ve talked about the risks posed by these advanced persistent threats (APT).
Insufficient cybersecurity to tackle the unknown
The fact that the cyberattacker needs to find that small vulnerability and act quickly and discreetly means that they are working in a context that has many limitations. This leads some organizations to the mistaken belief that zero-day attacks are not a very common occurrence. But they have become much more frequent over the last few years, and are now the most common incident registered. A study carried out by the consultancy firm Ponemon Institute shows that 76% of the companies that were surveyed that had suffered a cyberattack in 2018 say the type of attack was a new or unknown zero-day attack.
This percentage also highlights another aspect confirmed by the report: companies tend to prepare their cybersecurity plans to deal with known attacks, but pay less attention to unknown attacks. This goes some way to explaining the fact that, according to the study, 53% of companies dedicate more of their endpoint security investment to known attacks, while 47% spend more resources on unknown attacks.
Protect your company against zero-day attacks
Awareness in companies is vital when it comes to preventing unknown attacks. However, the very nature of zero-day attacks makes protection measures more complex. When faced with known threats, there are times when it could be enough to use traditional cybersecurity solutions that have successfully proven that they can remove threats. But what can companies do to protect against malware that has never been identified? Organizations need to take several measures, bearing in mind three essential aspects:
The right software: windows of opportunity are opened for cyberattackers every time a new piece of software is installed on the company’s computers and systems. This, however, doesn’t mean that the company must do away with the programs it needs. What it must do is to maintain a control policy that includes periodical revisions and uninstallation of programs that haven’t been used for some time.
In spite of the risks, the best option is always to update; as we mentioned, updates can contain new exploitable vulnerabilities. Nevertheless, developers try to correct errors and to apply new security measures in each version of their programs. It is therefore always worth keeping everything updated and using the latest versions of all software. To reduce the complexity of managing vulnerabilities, updates and patches for operating systems and applications, we recently launched Panda Patch Management. This solution makes it easier to respond to security incidents by patching all vulnerable computers in real time with just one click, all from a single security and management console.
Solutions based on behavioral analysis: The security model based on signatures is obsolete and inefficient against zero-day attacks. The way to fight these unknown attacks must therefore be based on the detection of suspicious behaviors.
This is the line followed by the most advanced cybersecurity solutions, such as Panda Adaptive Defense. It offers total endpoint security and complete protection against known malware. But that’s not all; it also classifies 100% of processes using machine learning techniques, which allows it to analyze all suspicious behaviors. This way it can increase the possibilities of detecting any kind of unknown malware. Panda Adaptive Defense combines EPP, EDR and 100% Attestation and Threat Hunting services, giving way to a new cybersecurity model that reduces the attack surface to the absolute minimum.
It’s not often that we hear about a critical vulnerability in Google Chrome, and perhaps it’s even more rare when Google’s own engineers are urging users to patch.
There are several good reasons why you need to take this new Chrome zero-day (CVE-2019-5786) seriously. For starters, we are talking about a full exploitation that escapes the sandbox and leads to remote code execution. This in itself is not an easy feat, and is usually observed only sporadically, perhaps during a Pwn2Own competition. But this time, Google is saying that this vulnerability is actively being used in the wild.
According to Clément Lecigne, the person from Google’s Threat Analysis Group who discovered the attack, there is another zero-day that exists in Microsoft Windows (yet to be patched), suggesting the two could be chained up for even greater damage.
If you are running Google Chrome and its version is below 72.0.3626.121, your computer could be exploited without your knowledge. While it’s true that Chrome features an automatic update component, in order for the patch to be installed you must restart your browser.
This may not seem like a big deal but it is. Another Google engineer explains why this matters a lot, in comparison to past exploits:
This newest exploit is different, in that initial chain targeted Chrome code directly, and thus required the user to have restarted the browser after the update was downloaded. For most users the update download is automatic, but restart is a usually a manual action. [3/3]
Considering how many users keep Chrome and all their tabs opened for days or even weeks without ever restarting the browser, the security impact is real.
Some might see a bit of irony with this latest zero-day considering Google’s move to ban third-party software injections. Many security programs, including Malwarebytes, need to hook into processes, such as the browser and common Office applications, in order to detect and block exploits from happening. However, we cannot say for sure whether or not this could prevent the vulnerability from being exploited, since few details have been shared yet.
In the meantime, if you haven’t done so yet, you should update and relaunch Chrome; and don’t worry about your tabs, they will come right back.
Researchers at the RSA Conference unveiled a zero day flaw in Microsoft Office that, when exploited on a Java enabled system, could lead to complete ownage of the end point. Microsoft Security Research has responded and said they won't be releasing a patch for it now, but might at a future date. Note the flaw is being actively exploited in the wild, not a theoretical situation. However, researchers admit this is not an easy flaw to exploit and requires in-depth knowledge of the format. Details are here at this ThreatPost article:
FireEye began investigating the vulnerability following the release
of the initial advisory from KISA.
We assess that the actors employing this latest Flash zero-day are a
suspected North Korean group we track as TEMP.Reaper. We have observed
TEMP.Reaper operators directly interacting with their command and
control infrastructure from IP addresses assigned to the STAR-KP
network in Pyongyang. The STAR-KP network is operated as a joint
venture between the North Korean Government's Post and
Telecommunications Corporation and Thailand-based Loxley Pacific.
Historically, the majority of their targeting has been focused on the
South Korean government, military, and defense industrial base;
however, they have expanded to other international targets in the last
year. They have taken interest in subject matter of direct importance
to the Democratic People's Republic of Korea (DPRK) such as Korean
unification efforts and North Korean defectors.
In the past year, FireEye iSIGHT Intelligence has discovered newly
developed wiper malware being deployed by TEMP.Reaper, which we detect
as RUHAPPY. While we have observed other suspected North Korean threat
groups such as TEMP.Hermit employ wiper malware in disruptive attacks,
we have not thus far observed TEMP.Reaper use their wiper malware
actively against any targets.
Analysis of the exploit chain is ongoing, but available information
points to the Flash zero-day being distributed in a malicious document
or spreadsheet with an embedded SWF file. Upon opening and successful
exploitation, a decryption key for an encrypted embedded payload would
be downloaded from compromised third party websites hosted in South
Korea. Preliminary analysis indicates that the vulnerability was
likely used to distribute the previously observed DOGCALL malware to
South Korean victims.
Adobe stated that it plans to release a fix for this issue the week
of Feb. 5, 2018. Until then, we recommended that customers use extreme
caution, especially when visiting South Korean sites, and avoid
opening suspicious documents, especially Excel spreadsheets. Due to
the publication of the vulnerability prior to patch availability, it
is likely that additional criminal and nation state groups will
attempt to exploit the vulnerability in the near term.
FireEye Solutions Detections
FireEye Email Security, Endpoint Security with Exploit Guard
enabled, and Network Security products will detect the malicious
document natively. Email Security and Network Security customers who
have enabled the riskware feature may see additional alerts based on
suspicious content embedded in malicious documents. Customers can find
more information in our FireEye Customer
Some time ago, we noticed some security researchers looking for critical vulnerabilities affecting "security" based products (such as antivirus) that can have a damaging impact to enterprise and desktop users. Take a stroll through the Google Project Zero bug tracker to see what we mean.
FireEye recently detected malicious Microsoft Office RTF documents
that leverage a previously undisclosed vulnerability. This
vulnerability allows a malicious actor to execute a Visual Basic
script when the user opens a document containing an embedded exploit.
FireEye has observed several Office documents exploiting the
vulnerability that download and execute malware payloads from
different well-known malware families.
FireEye shared the details of the vulnerability with Microsoft and
has been coordinating for several weeks public disclosure timed with
the release of a patch by Microsoft to address the vulnerability.
After recent public disclosure by another company, this blog serves to
acknowledge FireEye’s awareness and coverage of these attacks.
The attack involves a threat actor emailing a Microsoft Word
document to a targeted user with an embedded OLE2link object. When the
user opens the document, winword.exe issues a HTTP request to a remote
server to retrieve a malicious .hta file, which appears as a fake RTF
file. The Microsoft HTA application loads and executes the malicious
script. In both observed documents the malicious script terminated the
winword.exe process, downloaded additional payload(s), and loaded a
decoy document for the user to see. The original winword.exe process
is terminated in order to hide a user prompt generated by the OLE2link.
The vulnerability is bypassing most mitigations; however, as noted
above, FireEye email and network products detect the malicious
documents. Microsoft Office users are recommended to apply the patch
as soon as it is available.
It should come as no surprise that at Black Hat 2014 this week there were an enormous amount of invaluable conversations, as always. We talked about attacks, exploits and exploitation techniques as well as defenses basic and exotic. A few of these ended up in the same place, logically, and have led me to conclude that the majority of enterprises out there don't have a zero-day problem. Let me explain...
It should by now be clear if you're a security professional that the average enterprise struggles with even the most basic security hygiene. This of course makes life difficult when we start to pile on cross-silo dependancies - for example configuration management - for security effectiveness. While I certainly don't mean to imply that every enterprise can't do the basics, I have yet to meet a CISO who is comfortable with the fundamentals of asset, configuration and user management on an enterprise scale and in a timely fashion.
That being said, I further submit that zero-day attacks and exploits are an advanced level of attack typically reserved for targeted organizations which have significant levels of security capability mandating these advanced levels of effort. Basically if you've got your fundamentals right, and you're doing good block and tackle security, your users are well educated to be skeptical of links and things sent to them the determined attacker will be forced to turn to exploiting yet unknown and unpatched weaknesses in your software to get through your defenses. The truth is, I have come to believe, that the vast majority of enterprises just don't have their act together enough to merit that level of effort from the attacker.
From what I know, an attacker burning a zero-day exploit is a non-trivial matter. Zero-days, while still fairly plentiful, have a cost associated with them and an attacker will use one of these once he or she has exhausted the typical, and often easy, methods of breaching your security. There are simply too many options further down the chain. You have to look no further than a conversation with David Kennedy of TrustedSec who makes it clear exploits aren't required to break in. All that's required, in still far too many instances, is sending someone in the organization a malicious link, or a malicious file and they'll open the door and show you their closely-guarded intellectual property ... and probably hold the door for you as you walk out with it. Yes, indeed it is that simple to exploit corporate security with brain-boggling results.
So why burn a zero-day? Attackers typically won't unless they've encountered roadblocks in other avenues. Since PowerShell is installed on every new Windows PC, it's the perfect tool to use to execute an attack, legitimately, on a target host. All the user has to do is let you in...and we all know that most users will still click on the lure of a dancing bear or the promise of nude photos of their favorite celebrity.
So while your enterprise security organization may actually encounter some malware with zero-day exploits in them, they likely aren't targeted at your organization. The problem your average enterprise has is poor fundamentals - leaving you open to all manner of exploit and penetration without the use of any more advanced techniques than "asking the user for permission". So why would an attacker burn a precious zero-day against you? They likely wouldn't. Unless, you know, you're a target.