STE WILLIAMS

Sigh. Cisco security kit has Java deserialisation bug and a default password SNAFU

Cisco’s security developers have served up a parcel of patches.

First up, there’s a gem in Switchzilla’s Secure Access Control System. The ACS (which ceased sale in August 2017) is a hardware-based login gatekeeper, and it’s got a remotely-pwnable Java deserialisation bug.

Cisco’s notice for CVE-2018-0147 says an attacker could exploit the bug with a crafted Java object, and gain root privilege.

The bug affects all units running software up to version 5.8 patch 9, and fortunately while no longer sold, the Secure ACS is still in support, so Cisco has shipped patched software.

The other critical-rated bug is in the Cisco Prime Collaboration provisioning system: it has a hard-coded password in its SSH implementation, CVE-2018-0141.

The advisory says an attacker could use the SSH connection to get access to the underlying Linux operating system as a low-privilege user, and then elevate themselves to root to completely control the system.

The bug is only present in Cisco Prime Collaboration Provisioning Software Release 11.6, and there’s a fix available.

Today’s advisory list contains another 20 lower-rated bugs – enjoy. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/03/08/cisco_security_patches/

Audit finds Department of Homeland Security’s security is insecure

The United States’ Department of Homeland Security could do more to keep its IT systems secure, a government report has found.

In an agency-wide audit titled “Evaluation of DHS’ Information Security Program for Fiscal Year 2017” (PDF), the DHS’s watchdog, the Office of Inspector General (OIG), concluded that DHS “could protect its information and systems more fully and effectively.”

Based on a scale of five possible maturity levels – 1) ad hoc; 2) defined; 3) consistently implemented; 4) managed and measurable; and 5) optimized – DHS’ information security program rated level three in three of the five areas evaluated, shy of the passing grade, level 4.

DHS fell short implementing the various configuration settings required to protect systems, continued using unsupported operation systems, failed to patch critical vulnerabilities quickly, failed to monitor software licenses on unclassified systems, and didn’t plan well enough for recovery from service disruptions.

The report, dated March 1 and released on Wednesday, March 7, found that as of June 30, 2017, 64 systems lacked the authority to operate, based on government security criteria. Of these, 16 were classified national security systems and 48 were unclassified systems.

The results nonetheless represent an improvement over 2016 when 79 unclassified systems were deemed insufficiently protected.

According to the report, the foremost reason that the DHS failed to meet its security goals was lack of security talent.

Among the issues identified were:

Exchange folders were indexed in cache mode, which means user emails could be accessed if the machine was compromised.

Registry auditing was not always enabled, thereby allowing unattributed changes to the Windows registry.

Anonymous access to shared network drives was not always disabled.

The report also scolds DHS for continuing to use unsupported operating systems. DHS, the Coast Guard, and the Secret Service were all found to be using Windows Server 2003 after Microsoft’s July 2015 discontinuation of support.

The OIG also noted that Windows workstations at DHS, the Federal Emergency Management Agency (FEMA), and the Coast Guard were missing a variety of patches.

“Windows 2008 and 2012 operating systems were missing security patches for Oracle Java, an unsupported version of Internet Explorer, and a vulnerable version of Microsoft’s Sidebar and Gadgets applications,” the report says. “Some of the missing security patches dated back to July 2013.”

A number of Windows 8.1 and Windows 7 workstations were missing key security patches, including the WannaCry fix, various browser updates, and patches for Adobe Flash, Shockwave, and Acrobat flaws.

The report concludes that the observed deficiencies run contrary to the President’s Cybersecurity Executive Order and demonstrate the need for stronger security oversight.

“Until DHS overcomes challenges to addressing its systemic information security weaknesses, it will remain unable to ensure that its information systems adequately protect the sensitive data they store and process,” the report concludes.

A DHS spokesperson was not immediately available to address the findings but the report indicates that DHS concurs with the report’s recommendations and intends to address the concerns raised by the end of September, 2018. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/03/08/feds_scolded_for_slow_security_patching_and_outdated_operating_systems/

Intel SGX Can Be Used to Hide, Execute Malware

The microprocessor giant’s Software Guard Extensions security feature can be abused to implement virtually undetectable malware, Graz University researchers say.

In a talk at the Black Hat Asia conference later this month, researchers from the Graz University of Technology in Austria plan to show how attackers can abuse Intel’s Software Guard Extensions (SGX) microprocessor security feature to steal cryptographic keys and other secrets.

The researchers will present proof-of-concept malware that takes advantage of SGX’s code protection features to hide from state-of-the-art detection tools. They will show how the malware can be used to mount an attack for extracting RSA keys and other code that SGX is specifically designed to protect.

According to the researchers, the exploit is the first involving malware running on SGX hardware. Additionally, the researchers will show how such exploits can be used to search for and abuse so-called double-fetch privilege escalation vulnerabilities in secure enclaves — or the special execution environments in SGX.

The main takeaway is that SGX can help attackers hide and execute malware without requiring any root privileges, or operating system modifications says Michael Schwarz, a doctoral student in information security at Graz University.

“This attack, and also the detection of double-fetch bugs, shows that SGX is not this perfect black box, but that certain activities can be observed from the outside,” Schwarz says.

SGX is a security mechanism that Intel introduced with its Skylake processor architecture. It is designed to protect code and data from leaks and disclosure. As Schwarz notes in a technical paper, SGX uses secure enclaves working in hardware-isolated memory areas to protect application secrets from hardware attacks. Such enclaves can be used to securely store hardware-encrypted passwords, password managers, cryptographic keys, bitcoin wallets, and other secrets.

Schwarz says his malware does not exploit any vulnerability in SGX. Rather it takes advantage of the fact that Intel considers software-based side-channel attacks on SGX as not possible and therefore out of scope. Side channel attacks gather and use information about some aspect of a system’s physical operation to attack and expose sensitive data.

According to Schwarz, despite the restrictions of SGX, attackers can execute malware inside an SGX enclave and use that enclave to then attack and extract data from other enclaves.

“We show how easy it is to extract real-world 4096-bit RSA keys across enclaves using the widespread mbed TLS crypto library,” he says. The attack is not limited to RSA, but can be applied to any software, which leaks secrets when attacked via software-based side-channel attacks, Schwarz notes.

“As a further exploit, we show how one can utilize cache attacks to automatically detect double-fetch bugs in scenarios where the code and the binary is not known,” he says. Also in the cards is a demonstration of how such vulnerabilities can be exploit using the shared cache, he adds.

The exploit against SGX itself is harder to mount than a regular zero-day exploit, Schwarz concedes. But for someone with a background in micro-architectural attacks, it is perfectly doable, he says. In fact, several undergraduate and graduate level students at Graz University have already mounted such attacks, he claims.

“We require the cryptographic implementation to not be hardened against software-based side-channel attacks,” Schwarz says. “Other than that, there are no special requirements.”

Related Content:

 

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/intel-sgx-can-be-used-to-hide-execute-malware/d/d-id/1331211?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Patch now! Half a million Exim mail servers need an urgent update

About half a million email systems running the hugely popular Exim Mail Transfer Agent (MTA) have yet to be patched for a potentially dangerous security flaw made public earlier this week.

Disclosed to the software’s maintainers in early February by Meh Chang, from security firm Devcore Security Consulting, the Exim vulnerability is a one-byte buffer overflow in the software’s Base64 decoding.

Notes Chang:

Base64 decoding is such a fundamental function and therefore this bug can be triggered easily, causing remote code execution.

The researcher’s proof-of-concept exploit targeted this through the preamble to the SMTP daemon’s authentication process, before any emails are sent or received.

Generally, this bug is harmless because the memory overwritten is usually unused. However, this byte overwrites some critical data when the string fits some specific length.

This prompted Exim’s developers to respond:

Currently we’re unsure about the severity, we *believe* an exploit is difficult. A mitigation isn’t known.

By which they mean that defending against the flaw requires an update rather than a configuration tweak – referenced as CVE-2018-6789, updated version, 4.90.1, was first made available on 10 February.

The main takeaway is that this flaw affects all Exim versions going back to its first appearance in 1995 as a University of Cambridge Computing Service project to build a sophisticated alternative to the older Sendmail.

Would it really be hard to exploit? Granted, the PoC design involves a sophisticated sequence of memory manipulation but the MO is now in the public domain, forever.

The clock is ticking for unpatched servers and it’s probably best not to wait and find out if somebody can find a way to turn a remotely triggerable bug into an RCE.

Devcore put the number of vulnerable systems at “at least 400k servers”.

One up-to-date survey puts the number of public-facing email servers on the Internet at around 1.9 million, half of which identified the software they were running. Of these, 560,000 (or 57%) were running Exim, putting it way ahead of Postfix, and the now rapidly declining Sendmail. Some of those systems will already have been patched though.

Shodan, the search engine for internet-connected systems, pins the number of Exim servers in the low millions.

Exim is the sort of software it would be easy to ignore, even after a slight quickening in the number of flaws reported in it in the last year or so. Given its huge popularity, applying the update should be considered an urgent matter.

No exploits targeting the vulnerability have yet been recorded, but the cat’s out of the bag all the same.


Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/cicXKutfRt4/

Buffer overflow in Unix mailer Exim imperils 400,000 email servers

Researchers have uncovered a critical buffer overflow vulnerability in all versions of the Exim mail transfer agent.

The flaw (CVE-2018-6789) leaves an estimated 400,000 email servers at potential risk to remote code execution-style attacks. Fortunately a patched version (Exim version 4.90.1) is already available.

The bug might be exploited by unauthenticated users rather than hackers who have already broken into targeted systems or scored login credentials through some other (doubtless nefarious) means.

Meh Chang, the Taiwanese researcher from the DEVCORE research team who uncovered the flaw, was able to bypass security mitigations built into Exim (such as Address Space Layout Randomisation) in developing a proof-of-concept exploit.

Structure of a handcrafted message capable of exploiting the Exim bug

Structure of a handcrafted message capable of exploiting the Exim bug

The bug stems from (previously dormant) flaws introduced since the first commit of Exim, so all versions prior to the latest update are affected. More details about the vulnerability can be found here.

In an advisory, the developers behind Exim confirmed the development of a patch while playing down the severity of the flaw.

There is a buffer overflow in base64d(), if some pre-conditions are met.

Using a handcrafted message, remote code execution seems to be possible.

A patch exists already and is being tested.

Currently we’re unsure about the severity, we *believe*, an exploit is difficult. A mitigation isn’t known.

The bug was reported to the Exim team on Monday and they managed to develop and release a fix only two days later.

Another coding error that also represented a remote code execution risk in Exim was discovered and plugged in November. ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/03/07/exim_mail_server_bug/

Facebook Onavo Protect doesn’t protect against Facebook

Facebook’s mobile VPN app, Onavo Protect, has been pushed as a way to protect personal information over public networks. But the app, which the social media giant acquired in 2013, sends users’ data back to Facebook, even when the app is turned off.

In a blog post on Monday, Will Strafach, CEO of the Sudo Security Group, published his findings about the data collected by Onavo Protect for iOS.

The app, says Strafach, uses a Packet Tunnel Provider app extension – part of Apple’s iOS SDK – to handle the VPN’s network traffic routing. He claims the following data is being sent to Facebook:

  • When a mobile is turned on and off
  • Daily Wi-Fi data usage (even when the app off)
  • Daily cellular data usage (even when off)
  • Amount of time the VPN connection is used

So while the VPN may be protecting against eavesdropping on traffic traveling over an untrusted wireless network, it’s simultaneously reporting details about its user to Facebook.

Strafach, in an email to The Register, said it’s not clear what Facebook is doing.

“I cannot figure out why they collect the information that I am seeing,” he said. “The screen thing does not seem relevant to VPN usage, it just tells them (I guess) how long you are actively on your phone during the day if I understand correctly.”

Strafach said data usage tracking could make sense if Facebook were looking to identify those using too much data on its VPN.

“But the weird part is that the APIs called would tell them total usage even when not connected to the VPN, and additionally they could account for VPN usage on the server side if they wanted to,” he said.

The Onavo privacy policy – more accurately described as a data use policy –explains that by using the app, “you choose to route all of your mobile data traffic through, or to, Onavo’s servers.” And the app says it may use collected data to “provide, analyze, improve, and develop new and innovative services for users.”

So on some level, anyone using the app, much less Facebook’s other services, should be aware that they’ve surrendered their data, despite Facebook’s assertion that Onavo “helps keep you and your data safe when you go online, by blocking potentially harmful websites and securing your personal information.”

Facebook did not immediately respond to a request for comment.

Strafach argues that Facebook should be clearer about what it’s doing with the data.

“They can easily clear things up by explaining more precisely why they collect certain data and what they do with it, so I don’t understand why they are so vague about it,” he said. “I do hope they are being respectful of user privacy and it would be very nice if they clarified that I think.” ®

Sponsored:
Minds Mastering Machines – Call for papers now open

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/03/07/facebook_onavo_protect_doesnt_protect_against_facebook/

Memcached DDoS Attack: Kill Switch, New Details Disclosed

Corero shares a kill switch for the Memcached vulnerability and reports the flaw is more extensive than originally believed.

Corero Network Security has disclosed a “kill switch” for the Memcached vulnerability to national security agencies and shared new evidence indicating the flaw is more dangerous than previously believed. For the first time, threat actors have been exploiting unsecured Memcached servers to launch distributed denial-of-service (DDoS) attacks on target businesses.

Memcached is an open-source memory caching system that stores data in RAM to accelerate access times. It was not built for Internet access; users don’t have to authenticate. This exploit lets attackers create spoof requests and boost attacks up to 50,000 times.

The attacks, which hit businesses including GitHub, started in late February. German DDoS mitigation service provider Link11 was among the first to report the new activity, which included UDP attacks using Memcached servers to spread. Link11 found 5,000 vulnerable Memcached servers on the public internet.

Corero researchers have discovered that any exposed Memcached server that can be leveraged for a DDoS attack can also be tricked into sharing user data it has cached from its local network or host. Because Memcached servers don’t require authentication, anything added to a vulnerable server can be stolen. Attackers can also modify data and reinsert it in the cache without owners’ knowledge.

The “kill switch” sends a command back to the attackers’ server to suppress the current DDoS exploitation. This invalidates the cache of a vulnerable server, including attackers’ potentially malicious payload. It has been effectively tested on live attacking servers, Corero reports.

Read more details here.

 

 

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/memcached-ddos-attack-kill-switch-new-details-disclosed/d/d-id/1331207?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Privilege Abuse Attacks: 4 Common Scenarios

It doesn’t matter if the threat comes from a disgruntled ex-employee or an insider anticipating financial gain, privilege abuse patterns are pretty much the same, and they’re easy to avoid.

Privileged account abuse is one of the most dangerous threats because it is relatively easy to execute and takes a long time to detect. The 2017 IBM Cost of Data Breach Study disclosed that organizations lost at least $3.62 million on forensic and investigative activities, remediation and legal expenditures associated with security incidents in 2016. But the overall damage for businesses can be irrecoverable.

No matter who the threat actor is — a disgruntled ex-employee looking for revenge or an insider with sticky fingers anticipating financial gain — privilege abuse patterns are pretty much the same. Four common scenarios offer cybersecurity professionals valuable lessons about proper privilege account management.

Scenario 1: Privilege Abuse
The simplest and most common situation is when an insider uses legitimate permissions for malicious activities. A vivid example of this is the July 2017 Anthem breach in which a third-party consulting firm, LaunchPoint Ventures, discovered one of its employees, in July 2016, had sent a file containing personal health identity information of 18,500 Anthem customers to his personal email. Besides that, the employee allegedly committed identity theft and misused non-Anthem data.

The investigation is underway. It is not yet known how the attack started, what the motives were, or what the employee did with the stolen data. But both Anthem and LaunchPoint are likely to face fines for noncompliance, bad publicity, and lawsuits from enraged customers.

Lesson Learned: Be aware of what your employees and contractors are doing by regularly monitoring the activity of all privileged users. You can deter misbehavior simply by letting people know they are being watched.

Scenario 2: Privilege Escalation
Privilege escalation is when an insider deliberately raises his or her level of permissions to get more access rights. Privilege escalation requires more effort and knowledge than simple privilege abuse. The most obvious example is the case of Edward Snowden, a contractor who worked as a systems administrator for the NSA, who leaked classified details of a NSA electronic surveillance program to the Washington Post and the Guardian in 2013.

We don’t know all the details, but the most reasonable version of what happened is that the agency had poor visibility into user activity and little awareness of the keys and certificates in the IT environment. Snowden fabricated digital keys to obtain privileged access to areas way above his clearance. He also asked some NSA staffers for their usernames and passwords under the pretext that he needed them for his job.

Lesson Learned: Make sure you have rigorous control over access to systems that store confidential information, and a complete key and certificate inventory. In addition, remind your employees about your security policy and the consequences of violating it, for example, by sharing their passwords.

Scenario 3: Unauthorized Access
The unauthorized use of another user’s account is particularly difficult to detect and investigate. It occurs when an employee either purposely steals someone’s credentials or obtains them by mistake. These cases rarely go public, but here is one good example. Before leaving his job at engineering firm Allen Hoshall and starting his own competitive business, Jason Needham gained the email credentials of a colleague and used them over the next two years to steal marketing proposals and client correspondence — as well as the rotating password credentials to the firm’s FTP server. This enabled Needham to download schematics, staff emails, budget plans, and other sensitive data.

It is still unknown how Needham gained access to his colleague’s account. Most likely, they were either left in a visible location (hello, sticky notes on the screen) or were shared with Needham voluntarily. Since the company couldn’t explain to regulatory bodies how the incident happened, it’s fair to conclude they didn’t have sufficient awareness of what was happening in their systems.

Lesson Learned: Detecting account hijacking can be tough, but thorough monitoring and analysis of user activity will help you detect anomalies that could indicate a security incident. It’s also a good idea to implement a user termination policy that includes steps such as immediately disabling the employee’s account, terminating VPN and remote desktop access, and changing all shared account passwords. Be sure that the policy is closely followed whenever an employee quits or is terminated.

Scenario 4: Human Error
Human mistakes are perhaps the most common type of privilege abuse. Actually, there are two types of mistakes to consider: when a user accidentally misuses access rights that were granted properly, or an admin grants a user excessive access rights by mistake or out of negligence. I bet every organization has experienced this issue. One example that was made public was about two employees at Vanderbilt University Medical Center (VUMC), who were granted access to 3,000 patient medical records that they didn’t need for work. Their unauthorized access to this protected health information continued for 19 months, until it was discovered during a routine audit of access logs.

The audit revealed the employees had viewed far more information than was necessary to perform their work duties, such as patients’ Social Security numbers and medical record numbers. While VUMC does not believe that any data was misused, the individuals involved were disciplined for their actions, and the data breach is a violation of HIPAA regulations.

Lesson Learned: Strictly enforce the least-privilege principle to minimize the amount of data each employee can reach, and closely monitor user behavior to detect suspicious activity and new patterns. Also educate users about proper behavior and let them know they are being monitored; these steps can go a long way toward preventing costly mistakes.

The Main Lesson
These four common scenarios for privilege abuse resulting in data compromise all share the same key problem: a poor understanding of what users are doing in critical systems and how they interact with sensitive data, according to the 2017 Netwrix IT Risks Report, which my company recently published. To mitigate the threat or privilege abuse, security pros need to ensure that users have only the permissions they need to perform their duties, and monitor user activity across all levels of IT infrastructure.

Related Content:

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Michael Fimin joined Netwrix Corporation in 2007, bringing more than a decade of IT industry experience, management practices and innovation. Prior to joining Netwrix, Michael held several key positions at Aelita Software (later acquired by Quest Software), driving the … View Full Bio

Article source: https://www.darkreading.com/endpoint/privilege-abuse-attacks-4-common-scenarios/a/d-id/1331186?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Group-IB Helps Suspend Ukrainian DDoS Attack Group

This case marks the first successful prosecution of cybercriminals in Ukraine, the organization reports.

Group-IB, an international organization dedicated to cyberattack prevention and security product development, announced the takedown of a criminal group that had been launching distributed denial-of-service (DDoS) attacks and extorting companies for over two years.

This marks the first large-scale international case of DDoS extortion in Ukraine that ended with a court sentence, Group-IB reports. The organization worked with law enforcement, cybersecurity firms, and online companies to successfully prosecute the criminals.

The attackers were found as part of an investigation into the September 2015 DDoS attack on international online dating service AnastasiaDate. They demanded $10,000 for stopping the attack, which shut down the site for four to six hours each day of the campaign.

Specialists in Group-IB’s investigation department analyzed the attack, identified the attackers, and discovered other incidents conducted by the same two people: Gayk Grishkyan and Inna Yatsenko, both from Ukraine. The duo later contacted AnastasiaDate in November 2016 to demand ransom and threaten to renew the DDoS attacks on its website.

Both attackers pleaded guilty to the crimes and were each given a five-year conditional sentence. Outside the AnastasiaDate case, Grishkyan and Yatsenko had previously targeted American leasing company Stafford Associated and the PayOnline payment service.

Read more details here.

 

 

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/group-ib-helps-suspend-ukrainian-ddos-attack-group/d/d-id/1331201?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Researchers Defeat Android OEMs’ Security Mitigations

At Black Hat Asia, two security experts will bypass security improvements added to Android by equipment manufacturers.

It’s getting harder and harder to exploit vulnerabilities in Android, thanks to a combination of Google-enabled security mechanisms and additional protections from individual smartphone manufacturers. However, as two researchers discovered, it’s still possible to break in.

Over the past few years, Google has buckled down on Android device security with new protections to reduce the number and impact of kernel-level bugs. Some of its mitigations include Stack Guard, SELinux, privileged execute never (PXN), hardened user-copy, privileged access never (PAN) emulation, and kernel address space layout randomization (KASLR).

“As far as we know, mainly mitigations are currently applied on Android kernel,” explains Jun Yao, security researcher with the Core team. “However, these mechanisms are difficult to apply to every phone due to Android fragmentation issues.”

To fill the security gaps, smartphone manufacturers integrate additional mitigations into the devices they produce. Attackers need to meet certain conditions to complete an exploit on an Android phone and OEMs’ extra mitigations make these conditions difficult to meet, he says.

In the second quarter of 2017, Samsung, Huawei, Oppo, and Vivo accounted for 47.2 percent of the global smartphone market share, the researchers report. Despite their standing as the world’s top four Android OEMs, deep research on their security mitigations has been limited to the Samsung Knox. Yao and Lin decided to put more manufacturers’ protections to the test.

At this year’s Black Hat Asia conference, being held March 20-23 in Singapore, Yao and fellow Core security researcher Tong Lin will share the details of these mitigations and demonstrate how they can be stably bypassed in ways that have not been made public. One of the implementations they broke was the addr_limit checking protection on Vivo devices.

“Usually, to get root privilege on [a] target device, attackers need to be able to overwrite kernel memory,” Yao explains. “The most popular way to do it is to modify the process’ addr_limit.”

Because the kernel checks addr_limit before the system call returns, it cannot be modified directly. The researchers had to find another way to overwrite the kernel without changing addr_limit, and they successfully did so. They report this mitigation can be easily bypassed on a target device depending on the security mechanisms already in place.

[Learn more about breaking Android security in the Black Hat Asia session “Prison Break Season 6: Defeating the Mitigations Adopted by Android OEMs” in which Yao and Lin will demonstrate how they bypassed security protections built into Android phones.]

“It depends on specific devices,” says Yao. “If PAN is enabled on a target device, I think it’s difficult to bypass it. If it’s not, it’s easy to defeat it.”

PAN emulation works with hardened usercopy, which adds bounds checking to usercopy functions that the kernel uses to transfer data from user space to kernel space memory and back. Missing or invalid bounds checking has often caused kernel vulnerabilities in the past.

Hardened usercopy functions help detect and mitigate security issues in developers’ code, but they can only help if developers use them, explains Sami Tolvanen, senior software engineer for Android Security, on the Android developer blog. Features like PAN in ARM 8.1 and Supervisor Mode Access Prevention (SMAP) in x86 prevent the kernel from accessing user space directly, and ensure developers go through usercopy functions.

“I think mitigations fall into two categories,” says Yao. “One is to reduce the attack surface, and the other is to make exploits harder. The mitigations we are talking about belong to the latter one.” Fewer vulnerabilities lessen the chances of defeating these mitigations, he adds.

The most important thing for OEMs to do is promptly patch kernel flaws, Yao continues. He also advises using a combination of mitigations, as single mitigation is easier to bypass.

Related Content:

 

 

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance Technology, where she covered financial … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/researchers-defeat-android-oems-security-mitigations/d/d-id/1331209?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple