Tag Archives: discovered

Session cookie mishap exposed HackerOne private reports

A researcher discovered a session cookie risk that could have exposed private bugs on HackerOne, and questions remain about if data may have been taken.

The risk for vulnerability coordination and bug bounty site HackerOne stemmed from a HackerOne security analyst accidentally including a valid session cookie in a communication with community member haxta4ok00. According to the HackerOne incident report attached to the original bug report, which was first reported by Ars Technica, the session cookie was disclosed due to human error and revoked exactly two hours and three minutes after the company learned of the issue.

“Session cookies are tied to a particular application, in this case hackerone.com. The application won’t block access when a session cookie gets reused in another location. This was a known risk. As many of HackerOne’s users work from mobile connections and through proxies, blocking access would degrade the user experience for those users,” HackerOne wrote in the incident report. “A short-term mitigation of this vulnerability is to bind the user’s session to the IP address used at initial sign-in. If an attempt is made to utilize the session from a different IP address, the session is terminated.”

HackerOne added that longer-term mitigations will include detecting session cookies and authentication tokens in user comments and blocking submission, binding sessions to devices rather than IP addresses, improving employee education, and overhauling the permission model for HackerOne security analysts.

Craig Young, computer security researcher for Tripwire’s vulnerability and exposure research team, told SearchSecurity, “The first rule of session cookies is don’t share your session cookies.”

“That being said, accidents and oversights can happen. The general idea here is to bind the session cookies with some other identifying attribute of the expected client. This is commonly done by associating session cookies with some additional fingerprint of the authorized user,” Young said. “This can be as simple as restricting session cookies based on IP address or region. More sophisticated methods might involve client-side scripting to fingerprint a specific client browser.”

After seeing “the amount of sensitive information that could have been accessed” as a result of the session cookie account takeover, HackerOne decided the submission was a critical vulnerability and awarded a $20,000 bug bounty.

Data access still in question

Haxta4ok00 wrote in the report that they had “HackerOneStaff Access” and could “read all reports” and edit private programs. However, they asserted multiple times that all actions were in the spirit of white hat hacking.

In the discussion about the issue in the bug report, Reed Loden, director of security at HackerOne, asked haxta4ok00 to “delete all screenshots, exports, etc.” and confirm they had “no other copies of vulnerability data” captured as part of the report submission. While haxta4ok00 claimed they only took screenshots, they admitted they didn’t understand how to prove such data was deleted. Even so, Loden thanked the member “for confirming your removal of all screenshots and other data you may have downloaded as part of your report submission.” 

Following this exchange, Jobert Abma, co-founder of HackerOne, joined the conversation to ask why haxta4ok00 had “opened all the reports and pages in order to validate you had access to the account,” noting the HackerOne team found the extent of the member’s actions unnecessary.

Again, the member claimed they meant no harm and that answer seemed to be accepted by HackerOne staff. The member went on to claim they had previously reported the session cookie risk and nothing was done.

Katie Moussouris, founder and CEO of Luta Security, pointed out on Twitter that the discussion between haxta4ok00 and HackerOne staff raised more questions.

Loden told SearchSecurity that “asking the reporting hacker to validate what we are seeing on our end is one of many steps in our investigation process.”

“HackerOne always conducts comprehensive investigations for all vulnerabilities reported to our own bug bounty program. In this case HackerOne’s bug bounty program operated exactly as intended, it gave us a way to identify an unknown risk fast so we could safely eliminate it,” he wrote via email. “Less than 5% of programs were impacted by this issue, the risk was eliminated within two hours of receipt and long-term fixes were pushed within days.”

Loden also clarified why action was not taken on the first report about session cookie issues.

“HackerOne’s bug bounty program is focused on identifying real-world vulnerabilities impacting the Platform, and we require hackers to provide a valid proof of concept with submissions,” Loden said. “The report in question from three years ago was a purely theoretical scenario focused on older browsers that were not, and are still not, supported by the HackerOne Platform.”

Go to Original Article
Author:

USBAnywhere vulnerabilities put Supermicro servers at risk

Security researchers discovered a set of vulnerabilities in Supermicro servers that could allow threat actors to remotely attack systems as if they had physical access to the USB ports.

Researchers at Eclypsium, based in Beaverton, Ore., discovered flaws in the baseboard management controllers (BMCs) of Supermicro servers and dubbed the set of issues “USBAnywhere.” The researchers said authentication issues put servers at risk because “BMCs are intended to allow administrators to perform out-of-band management of a server, and as a result are highly privileged components.

“The problem stems from several issues in the way that BMCs on Supermicro X9, X10 and X11 platforms implement virtual media, an ability to remotely connect a disk image as a virtual USB CD-ROM or floppy drive. When accessed remotely, the virtual media service allows plaintext authentication, sends most traffic unencrypted, uses a weak encryption algorithm for the rest, and is susceptible to an authentication bypass,” the researchers wrote in a blog post. “These issues allow an attacker to easily gain access to a server, either by capturing a legitimate user’s authentication packet, using default credentials, and in some cases, without any credentials at all.”

The USBAnywhere flaws make it so the virtual USB drive acts in the same way a physical USB would, meaning an attacker could load a new operating system image, deploy malware or disable the target device. However, the researchers noted the attacks would be possible on systems where the BMCs are directly exposed to the internet or if an attacker already has access to a corporate network.

Rick Altherr, principal engineer at Eclypsium, told SearchSecurity, “BMCs are one of the most privileged components on modern servers. Compromise of a BMC practically guarantees compromise of the host system as well.”

Eclypsium said there are currently “at least 47,000 systems with their BMCs exposed to the internet and using the relevant protocol.” These systems would be at additional risk because BMCs are rarely powered off and the authentication bypass vulnerability can persist unless the system is turned off or loses power.

Altherr said he found the USBAnywhere vulnerabilities because he “was curious how virtual media was implemented across various BMC implementations,” but Eclypsium found that only Supermicro systems were affected.

According to the blog post, Eclypsium reported the USBAnywhere flaws to Supermicro on June 19 and provided additional information on July 9, but Supermicro did not acknowledge the reports until July 29.

“Supermicro engaged with Eclypsium to understand the vulnerabilities and develop fixes. Supermicro was responsive throughout and worked to coordinate availability of firmware updates to coincide with public disclosure,” Altherr said. “While there is always room for improvement, Supermicro responded in a way that produced an amicable outcome for all involved.”

Altherr added that customers should “treat BMCs as a vulnerable device. Put them on an isolated network and restrict access to only IT staff that need to interact with them.”

Supermicro noted in its security advisory that isolating BMCs from the internet would reduce the risk to USBAnywhere but not eliminate the threat entirely . Firmware updates are currently available for affected Supermicro systems, and in addition to updating, Supermicro advised users to disable virtual media by blocking TCP port 623.

Go to Original Article
Author:

Capital One breach suspect may have hit other companies

A new report looking into the attacker accused in the Capital One breach discovered references to other potential victims, but no corroborating evidence has been found yet.

The FBI accused Paige Thompson, who allegedly went by the name “Erratic” on various online platforms, including an invite-only Slack channel. The Slack channel was first reported on by investigative cybersecurity journalist Brian Krebs, who pointed out that file names referenced in the channel pointed to other organizations potentially being victims of similar attacks.

A new report by cybersecurity firm CyberInt, based in London, regarding the Capital One breach built on the information discovered by Krebs. Jason Hill, lead cybersecurity researcher at CyberInt, said the company was able to gain access to the Slack channel via an open invitation link.

“This link was obtained from the now-offline ‘Seattle Warez Kiddies’ Meetup group (Listed as ‘Organized by Paige Thomson’),” Hill wrote via email. “Based on the publicly available information at the time of report completion, such as Capital One’s statement and the [FBI’s] Criminal Complaint, we were able to conduct open source intelligence gathering to fill in some of the missing detail and follow social media leads to gain an understanding of the alleged threat actor and their activity over the past months.”

According to Hill, CyberInt researchers followed the trail through a GitHub account, GitLab page and a screenshot of a file archival process shared in the Slack channel.

“The right-hand side of the screen appears to show the output of the Linux command ‘htop’ that lists current processes being executed. In this case, under the ‘Command’ heading, we can see a number of ‘tar –remove-files -cvf – ‘ processes, which are compressing data (and then removing the uncompressed source),” Hill wrote. “These files correlate with the directory listing, and potential other victims, as seen later within the Slack channel.”

Between the files named in the screenshot and the corresponding messages in the Slack channel, it appeared as though in addition to the Capital One breach, the threat actor may have stolen 485 GB of data from various other organizations. Some organizations were implied by only file names, such as Ford, but others were named directly by Erratic in messages, including the Ohio Department of Transportation, Michigan State University, Infoblox and Vodafone.

Hill acknowledged that CyberInt did not directly contact any of the organizations named, because the company policy is normally to “contact organizations when our research detects specific vulnerabilities that can be mitigated, or threats detected by our threat intelligence platform.

“However in this case, our research was focused on the Capital One breach to gain an understanding of the threat actor’s tactics, techniques and procedures (TTP) and resulted in the potential identification of additional victims rather than the identification of any specific vulnerability or ongoing threat,” Hill wrote. “Our report offered general advice for those concerned about the TTP based on these findings.”

We contacted some of the organizations either directly named or implied via file name in Erratic’s Slack channel. The Ohio Department of Transportation did not respond to a request for comment. Ford confirmed an investigation is underway to determine if the company was the victim of a data breach.

A spokesperson for Michigan State University also confirmed an investigation is underway and the university is cooperating with law enforcement authorities, but at this point there is “no evidence to suggest MSU was compromised.”

Similarly, an Infoblox spokesperson said the company was “continuing to investigate the matter, however, at this time, there is no indication that Infoblox was in any way involved with the Capital One breach. Additionally, there is no indication of an intrusion or data breach causing Infoblox customer data to be exposed.”

A Vodafone spokesperson claimed the company takes security seriously, but added, “Vodafone is not aware of any information that relates to the Capital One security breach.”

Go to Original Article
Author:

Intel disclosed Spectre-like L1TF vulnerabilities

A new set of Spectre-like flaws that can, theoretically, be exploited to steal sensitive information was discovered in Intel products.

Two separate teams of researchers discovered the new vulnerabilities within a few weeks of each other in January and reported it to Intel. Intel was then able to identify two closely related variants and disclosed them publically this week, calling them L1 Terminal Fault (L1TF) vulnerabilities.

The three varieties of the L1TF vulnerabilities include CVE-2018-3615, which affects Intel’s Software Guard Extensions (SGX); CVE-2018-3620, which affects operating systems and System Management Mode memory; and CVE-2018-3646, which affects hypervisors and virtual machines.

The flaw affecting Intel SGX — the Foreshadow vulnerability — has caused more of an uproar than the others. Since the discovery of the Meltdown and Spectre vulnerabilities in January, Intel SGX had mostly remained untouched. While Meltdown and Spectre targeted program instructions, Foreshadow targets program data.

As a speculative execution side-channel vulnerability, Foreshadow can enable an attacker to “steal sensitive information stored inside personal computers and third-party clouds,” according to the researchers who discovered the flaws.

In a blog post about the L1TF vulnerabilities, Google explained that in order to exploit Foreshadow, an attacker would need “control of hardware resources that are accessible only with operating system level control of the underlying physical or virtual processors.” The vendor noted that unpatched operating systems could also allow for exploitation.

“Defending against this method of attack is particularly challenging for virtualized environments, as a virtual machine exposes the state necessary to construct an attack,” Google explained. “Specifically, an attacker could intentionally configure their own page tables to direct these faults and probe the cache of the core on which they are currently executing.”

Foreshadow vulnerabilityForeshadow vulnerability

Intel has already released mitigations for the L1TF vulnerabilities and said the new patches work best in conjunction with the microcode updates the company released earlier this year in response to the Meltdown and Spectre vulnerabilities.

“When coupled with corresponding updates to operating system and hypervisor software released starting today by our industry partners and the open source community, these updates help ensure that consumers, IT professionals and cloud service providers have access to the protections they need,” Intel’s executive vice president and general manager of product assurance and security, Leslie Culbertson, said. “Once systems are updated, we expect the risk to consumer and enterprise users running non-virtualized operating systems will be low.”

In other news:

  • President Donald Trump has reversed an Obama-era memorandum on how and when the U.S. government can use cyberattacks against adversaries, according to The Wall Street Journal. Trump signed an order to undo Presidential Policy Directive 20, which outlined a complex interagency process that had to be followed before the government could target a cyberattack at foreign adversaries. Presidential Policy Directive 20 was signed by then-President Barack Obama in 2012. Trump has yet to issue a replacement for the memorandum, though The Wall Street Journal reported “a number of current U.S. officials confirmed the directive had been replaced, but declined to comment further,” because it’s classified.
  • August’s Patch Tuesday brought five Flash patches from Adobe and 17 updates to fix at least 60 vulnerabilities — including two actively exploited zero-day vulnerabilities — from Microsoft. The first zero-day flaw Microsoft patched was a critical vulnerability in Internet Explorer that would target users with malware. The other zero-day was a vulnerability in the Windows 10 shell that would enable an attacker to run code remotely. Microsoft also patched the Foreshadow vulnerability. Another 23 patches were for critical flaws in Internet Explorer, Edge and Chakra Scripting. Adobe patched Flash vulnerabilities with a new version of it for macOS, Chrome and Linux.
  • The NIST Small Business Cybersecurity Act — formerly called the MAIN STREET Cybersecurity Act — became a law this week. The law requires the National Institute of Standards and Technology to provide informational resources to small businesses to help them with cybersecurity. The law is the result of a bipartisan effort from U.S. Sens. Brian Schatz (D-Hawaii) and James Risch (R-Idaho), and co-sponsored by Sens. John Thune (R-S.D.), Maria Cantwell (D-Wash.), Bill Nelson (D-Fla.), Cory Gardner (R-Colo.), Catherine Cortez Masto (D-Nev.), Maggie Hassan (D-N.H.), Claire McCaskill (D-Mo.), and Kirsten Gillibrand (D-N.Y.). The resources NIST provides to small businesses must be applicable to a wide variety of small businesses, vary based on the size of the company and the sensitivity of the data it deals with, include basic ways to promote a cybersecurity-aware environment, include case studies, are technology- and vendor-neutral and be based on international standards as much as possible.

BGP hijacking attacks target payment systems

Researchers discovered BGP hijacking attacks targeting payment processing systems and using new tricks to maximize the attackers hold on DNS servers.

Doug Madory, director of internet analysis at Oracle Dyn, previously saw border gateway protocol (BGP) hijacking attacks in April 2018 and has seen them continue through July. The first attack targeted an Amazon DNS server in order to lure victims to a malicious site and steal cryptocurrency, but more recent attacks targeted a wider range of U.S. payment services.

“As in the Amazon case, these more recent BGP hijacks enabled imposter DNS servers to return forged DNS responses, misdirecting unsuspecting users to malicious sites.  By using long TTL values in the forged responses, recursive DNS servers held these bogus DNS entries in their caches long after the BGP hijack had disappeared — maximizing the duration of the attack,” Madory wrote in a blog post. “The normal TTL for the targeted domains was 10 minutes (600 seconds).  By configuring a very long TTL, the forged record could persist in the DNS caching layer for an extended period of time, long after the BGP hijack had stopped.”

Madory detailed attacks on telecom companies in Indonesia and Malaysia as well as BGP hijacking attacks on U.S. credit card and payment processing services, the latter of which lasted anywhere from a few minutes to almost three hours. While the payment services attacks featured similar techniques to the Amazon DNS server attack, it’s unclear if the same threat actors are behind them.

Justin Jett, director of audit and compliance for Plixer, said BGP hijacking attacks are “extremely dangerous because they don’t require the attacker to break into the machines of those they want to steal from.”

“Instead, they poison the DNS cache at the resolver level, which can then be used to deceive the users. When a DNS resolver’s cache is poisoned with invalid information, it can take a long time post-attacked to clear the problem. This is because of how DNS TTL works,” Jett wrote via email. “As Oracle Dyn mentioned, the TTL of the forged response was set to about five days. This means that once the response has been cached, it will take about five days before it will even check for the updated record, and therefore is how long the problem will remain, even once the BGP hijack has been resolved.”

Madory was not optimistic about what these BGP hijacking attacks might portend because of how fundamental BGP is to the structure of the internet.

“If previous hijacks were shots across the bow, these incidents show the internet infrastructure is now taking direct hits,” Madory wrote. “Unfortunately, there is no reason not to expect to see more of these types of attacks against the internet.”

Matt Chiodi, vice president of cloud security at RedLock was equally as worried and warned that these BGP hijacking attacks should be taken as a warning.

“BGP and DNS are the silent warriors of the internet and these attacks are extremely serious because nearly all other internet services assume they are secure. Billions of users rely on these mostly invisible services to accomplish everything from Facebook to banking,” Chiodi wrote via email. “Unfortunately, mitigating BGP and DNS-based attacks is extremely difficult given the trust-based nature of both systems.”

Yale data breach discovered 10 years too late

Yale University discovered it suffered a data breach — 10 years ago.

The Yale data breach occurred at some point between April 2008 and January 2009, but officials are unsure exactly when. The Yale data breach included sensitive data such as names, Social Security numbers and birth dates on an unknown number of people, as well as some email addresses and physical addresses.

Because the Yale data breach happened so long ago, the University claimed it did not have much information on how it occurred. In its announcement of the breach, Yale noted that in 2011, the school’s IT “deleted the personal information in the database as part of an effort to eliminate unneeded personal information on Yale servers, but the intrusion was not detected at that time.”

The Yale data breach was not discovered until June 2018 when the school’s IT was “testing its servers for vulnerabilities and discovered a log that revealed the intrusion.”

Ryan Wilk, vice president at NuData Security, said the data included in the breach was more than enough to put users at risk.

“Although financial information was not exposed, even having your Social Security number, name, address and date of birth stolen can still cause problems,” Wilk wrote via email. “Cybercriminals can use this information to create a complete profile of students. Add a bit of social engineering, and they can start cracking all types of accounts and even open up new accounts in the students’ names.”

The school said it notified those students, alumni, faculty and staff memers affected by the breach and has offered identity monitoring services.

Zach Seward, CPO and executive editor at Quartz, was one victim in the Yale data breach, and he relayed his story on Twitter.

Wilk said it might not be Yale’s fault for not discovering the breach sooner.

“Malicious actors are learning not only to access a system but also to do it without leaving a trace. This extreme sophistication results in hard-to-uncover breaches that can take a long to reveal. We encourage companies and organizations to monitor their security system constantly and to stay alert for any unusual activity,” Wilk wrote. “Even if they’ve checked unusual activity thousands of times and it turned out to be nothing risky, the next time that anomaly may just be your cybercriminal at work.”

No need to rush network patching for Spectre and Meltdown

The recently discovered security threat in CPUs from nearly a dozen manufacturers poses a low risk to corporate networking gear, so operators have time to test vendors’ patches thoroughly.

That’s the take of security experts contacted by SearchNetworking following the discovery last week of the Spectre and Meltdown vulnerabilities that affect Intel, AMD and ARM chips. In response, Cisco and Juniper Networks have released patches rated medium and low risk, respectively, for a variety of products.

The low risk of Spectre and Meltdown to switches and routers means network managers have the time to thoroughly test the patches to minimize their impact on hardware performance, experts said.

“If you’re getting a firmware update, you need to patch,” said Rob Westervelt, analyst at IDC. “[But] the issue is whether you just deploy the patch or test it thoroughly and make sure you don’t break any applications or anything else.”

Roughly 20 CSOs and IT security professionals interviewed by IDC were taking a methodical approach to applying Spectre and Meltdown fixes across all systems.

“While it is top of mind, it’s not something that they’re immediately jumping on to patch,” Westervelt said. “They are using established best practices and testing those patches first.”

Network performance at risk

Westervelt warned there is the possibility network performance will suffer. “In some cases, it could be very costly.”

If you’re getting a firmware update, you need to patch.
Rob Westerveltanalyst at IDC

Indeed, Microsoft reported in a blog post patches for the PC and server versions of Windows would range from minor to significant, depending on the age of the operating system and the CPU. “I think we can expect a similar variety of performance impacts across other [vendors’] products,” said Jake Miller, a senior security analyst at IT consulting firm Bishop Fox, based in Tempe, Ariz.

Security pros expect hackers sophisticated enough to exploit the hard-to-reach vulnerabilities to target mostly servers in large data centers that host cloud computing environments. Because of the level of expertise needed to take advantage of the flaws, hackers working for nation states are the most likely attackers, experts said.

Exploiting the CPU holes would involve crafting code that takes advantage of how some processors anticipate features computer users will request next. In preparation for those requests, processors will load into memory valuable data and instructions that hackers can steal.

“The threat is significant, but currently is limited to highly sophisticated attackers and hacking groups with the means to carry out multi-staged targeted attacks,” IDC said in a research note. “Financially motivated cybercriminals are more likely to continue to use more accessible, time-tested methods to retrieve passwords and sensitive data.”

Nevertheless, even a low risk to networking gear is worth the time needed for fixing. “It’s better to be safe than sorry,” said Jonathan Valamehr, COO and co-founder of cybersecurity company Tortuga Logic Inc.

Return of Bleichenbacher: ROBOT attack means trouble for TLS

A team of security researchers discovered eight leading vendors and open source projects whose implementations of the Transport Layer Security protocol are vulnerable to the Bleichenbacher oracle attack, a well-known flaw that was first described in 1998.

The Bleichenbacher attack has been referenced in all IETF specifications for the Transport Layer Security (TLS) protocol since version 1.0 in 1999, and implementers of TLS versions through 1.2 were warned to take steps to avoid the Bleichenbacher attack. However, the researchers noted that, based on the ease with which they were able to exploit the vulnerability, it appears that many implementers ignored the warnings.

The attack is named after its discoverer, Daniel Bleichenbacher, a Swiss cryptographer who was working for Bell Laboratories in 1998 when his research on the vulnerability was first published. The TLS protocol, which was meant to replace the Secure Sockets Layer, is widely used for encryption and the authentication of web servers.

The research team  included Hanno Bock, information security researcher; Juraj Somorovsky, research associate at the Horst Görtz Institute for IT Security at the Ruhr-Universität Bochum in Germany; and Craig Young, , computer security researcher with Tripwire’s Vulnerability and Exposures Research Team (VERT). “Perhaps the most surprising fact about our research is that it was very straightforward,” the researchers wrote. “We took a very old and widely known attack and were able to perform it with very minor modifications on current implementations. One might assume that vendors test their TLS stacks for known vulnerabilities. However, as our research shows in the case of Bleichenbacher attacks, several vendors have not done this.”

The researchers said many web hosts are still vulnerable to the ROBOT attack and that nearly a third of the top 100 sites in the Alexa Top 1 Million list are vulnerable. The team identified vulnerable products from F5, Citrix, Radware, Cisco, Erlang, and others, and “demonstrated practical exploitation by signing a message with the private key of facebook.com’s HTTPS certificate.”

The researchers described their work as the “Return Of Bleichenbacher’s Oracle Threat” (ROBOT) and published it in a paper of the same title, as well as on a branded vulnerability website. The team also published a capture the flag contest, posting an encrypted message and challenging the public to decrypt the message using the strategies described in the paper.

TLS protocol designers at fault

The researchers placed the blame for the ease of their exploits squarely on the shoulders of TLS protocol designers. The ROBOT attack is made possible by the behavior of servers implementing TLS using the RSA Public-Key Cryptography Standards (PKCS) #1 v1.5 specification; the issues that enable the Bleichenbacher attack are fixed in later versions of PKCS. TLS 1.3, which is expected to be finalized soon, deprecates the use of PKCS #1 v1.5 and specifies use of PKCS #1 v2.2.

The TLS protocol designers absolutely should have been more proactive about replacing PKCS#1 v1.5.
Craig Youngcomputer security researcher, Tripwire VERT

“The TLS protocol designers absolutely should have been more proactive about replacing PKCS#1 v1.5. There is an unfortunate trend in TLS protocol design to continue using technology after it should have been deprecated,” Young told SearchSecurity by email. He added that vendors also “should have been having their code audited by firms who specialize in breaking cryptography since most software companies do not have in-house expertise for doing so.”

TLS as currently deployed ignores improperly formatted data, and as described in 1999 in RFC 2246. “The TLS Protocol Version 1.0,” the original specification for TLS 1.0, the ROBOT attack “takes advantage of the fact that by failing in different ways, a TLS server can be coerced into revealing whether a particular message, when decrypted, is properly PKCS #1 formatted or not,” the RFC 2246 document states.

The solution proposed in that specification for avoiding “vulnerability to this attack is to treat incorrectly formatted messages in a manner indistinguishable from correctly formatted RSA blocks. Thus, when it receives an incorrectly formatted RSA block, a server should generate a random 48-byte value and proceed using it as the premaster secret. Thus, the server will act identically whether the received RSA block is correctly encoded or not.”

Potential for attacks, detection and remediation

The researchers noted in the paper that the ROBOT flaw could lead to very serious attacks. “For hosts that are vulnerable and only support RSA encryption key exchanges it’s pretty bad. It means an attacker can passively record traffic and later decrypt it,” the team wrote on the ROBOT website, adding that “For hosts that usually use forward secrecy, but still support a vulnerable RSA encryption key exchange the risk depends on how fast an attacker is able to perform the attack. We believe that a server impersonation or man in the middle attack is possible, but it is more challenging.”

Young said that it might be possible to detect attempts to abuse the Bleichenbacher vulnerability, but it would not be easy. “This attack definitely triggers identifiable traffic patterns. Servers would observe a high volume of failed connections as well as a smaller number of connections with successful handshakes and then little to no data on the connection,” he told SearchSecurity. “Unfortunately, I am unaware of anybody actually doing this. Logging the information needed to detect this can be cumbersome and for a site receiving a billion connections a second, it could be quite difficult to notice 10-100 thousand failed connections.”

As for other, ongoing risks, Young said that while “PKCS#1 v1.5 is not being used in TLS 1.3 but it is still used in other systems like XML encryption. Whether or not it can be disabled through configuration is highly application specific.”

DUHK attack puts random number generators at risk

Researchers have discovered a vulnerability that affects some legacy security devices, including Fortinet’s FortiGate devices.

The vulnerability has been dubbed DUHK, which stands for Don’t Use Hard-coded Keys, and affects devices that use the ANSI X9.31 Random Number Generator (RNG) and a hardcoded seed key. Researchers Nadia Heninger and Shaanan Cohney from the University of Pennsylvania, along with cryptographer Matthew Green at Johns Hopkins University, studied the Federal Information Processing Standards (FIPS) certified products that use the ANSI X9.31 RNG algorithm and found 12 that are vulnerable to DUHK.

“DUHK allows attackers to recover secret encryption keys from vulnerable implementations and decrypt and read communications passing over VPN connections or encrypted web sessions,” the researchers explained in a blog post. “The encrypted data could include sensitive business data, login credentials, credit card data and other confidential content.”

Heninger, Cohney and Green were only able to gain access to the firmware of one product — a Fortinet firewall — so their detailed research paper mostly focuses on the affected Fortinet devices, specifically the FortiGate VPN gateways.

“Traffic from any VPN using FortiOS 4.3.0 to FortiOS 4.3.18 can be decrypted by a passive network adversary who can observe the encrypted handshake traffic,” they explained. “Other key recovery attacks on different protocols may also be possible.”

The full list of affected vendors is in the research paper and includes Fortinet, Becrypt, Cisco, DeltaCrypt Technologies, MRV Communications, NeoScale Systems, Neopost Technologies, Renesas Technology America, TechGuard Security, Tendyron Corp., ViaSat and Vocera Communications.

The ANSI X9.31 RNG algorithm lost its FIPS certification in January 2016, so the researchers noted that many vendors have since published software updates to remove it.

Devices have to meet four requirements in order to be vulnerable to DUHK, according to Heninger, Cohney and Green:

  • A device must use the X9.31 RNG.
  • A seed key is hardcoded into the implementation.
  • The output from the RNG is used to generate crypto keys.
  • “At least some of the random numbers before or after those used to make the keys are transmitted unencrypted. This is typically the case for SSL/TLS and IPsec.”

The researchers recommended anyone who develops cryptographic software should stop using the X9.31 RNG and not use a hardcoded key.

The research team also warned that this vulnerability is the key to an easy and practical attack, though there’s no evidence it’s being actively exploited by attackers.

“Our attack against [the] FortiGate device can be carried out on a modern computer in about four minutes,” they noted.

In other news:

  • FBI Director Christopher Wray spoke earlier this week about the FBI’s continuous battle with mobile device encryption. Speaking at the International Association of Chiefs of Police conference in Philadelphia, Wray said the FBI was unable to access more than 6,900 mobile devices so far this year. “To put it mildly, this is a huge, huge problem,” Wray said. “It impacts investigations across the board — narcotics, human trafficking, counterterrorism, counterintelligence, gangs, organized crime [and] child exploitation.” The FBI has warred with vendors and the security community in recent years over encryption in mobile devices, arguing that law enforcement needs backdoors through encryption to access devices during investigations. Vendors such as Apple and security experts argue that a backdoor cannot exist for law enforcement without it being accessible by malicious actors, as well, and thus putting user privacy at risk. Wray’s comment follows the U.S. Department of Justice’s call for “responsible encryption.”
  • A group of senators and congressmen have introduced a bipartisan bill that would create a new legal framework that would allow law enforcement to access U.S. electronic communications stored on servers located in other countries. The group includes Rep. Doug Collins (R-Ga.), Rep. Hakeem Jeffries (D-N.Y.), Sen. Orrin Hatch (R-Utah), Sen. Chris Coons (D-Del.), and Sen. Dean Heller (R-Nev.). They are calling on Congress to pass the bill, called the International Communications Privacy Act, and are supported by organizations such as Americans for Tax Reform and the R Street Institute, which penned a letter to the Congress pushing for the bill. With this new bill, the group of senators and representatives aims to update the Electronic Communications Privacy Act of 1986, which they argued is outdated. The International Communications Privacy Act would require law enforcement to obtain a warrant for all electronic data on U.S. citizens and allow law enforcement to access data on foreign nationals.
  • Serious security flaws have been discovered in the way the Presidential Advisory Commission on Election Integrity, which is investigating voter fraud, handles the personal data of millions of voters. Illinois-based advocacy group Indivisible Chicago requested public records from Illinois and Florida on the Interstate Voter Registration Crosscheck Program. Crosscheck aims to identify people who are registered and voting in more than one state. Indivisible Chicago received emails and other documents from election officials, which showed several security issues with Crosscheck, including the freely available usernames and passwords. “The primary problem here is not that we have these passwords, but that every official and IT department involved in this process sends usernames, login passwords, and decryption passwords in clear text in email — sometimes with up to eighty recipients,” Indivisible Chicago wrote. “Anyone could have these passwords and could have had them at a time they could have been used while the ISBE would have been none the wiser.”

CCleaner malware spread via supply chain attack

Researchers discovered a popular system maintenance tool was the victim of a supply chain attack that put potentially millions of users at risk of downloading a malicious update.

CCleaner is a tool designed to help consumers perform basic PC maintenance functions like removing cached files, browsing data and defragmenting hard drives. CCleaner is made by Piriform Ltd., a UK-based software maker that was acquired by antivirus company Avast Software in July. The compromised update of the tool was first discovered by Israeli endpoint security firm Morphisec following an investigation that began on Sept. 11th, but the company claims it began blocking the CCleaner malware at customer sites on Aug. 20th.

“A backdoor transplanted into a security product through its production chain presents a new unseen threat level which poses a great risk and shakes customers’ trust,” wrote Michael Gorelik, vice president of research and development at Morphisec in a blog post. “As such, we immediately, as part of our responsible disclosure policy, contacted Avast and shared all the information required for them to resolve the issue promptly. Customers safety is our top concern.”

The CCleaner malware gathered information about systems and transmitted it to a command and control (C&C) server; it was reportedly downloaded by users for close to one month from August 15 to September 12, according to Morphisec. However, Avast noted that the CCleaner malware was limited to running on 32-bit systems and would only run if the affected user profile had administrator privileges.

Avast said CCleaner claims to have more than 2 billion downloads and adds new users at a rate of 5 million per week, but because only the 32-bit and cloud versions of CCleaner were compromised, the company estimated just 2.27 million users were affected.

Impact of the CCleaner malware

A team of researchers at Cisco Talos, which included Edmund Brumaghin, threat researcher, Ross Gibb, senior information security analyst, Warren Mercer, technical leader, Matthew Molyett, research engineer, and Craig Williams, senior technical leader, discovered and analyzed the CCleaner malware soon after Morphisec. According to the Cisco Talos team, Avast unwittingly distributed legitimate signed versions of CCleaner and CCleaner Cloud which “contained a multi-stage malware payload that rode on top of the installation.”

“This is a prime example of the extent that attackers are willing to go through in their attempt to distribute malware to organizations and individuals around the world. By exploiting the trust relationship between software vendors and the users of their software, attackers can benefit from users’ inherent trust in the files and web servers used to distribute updates,” Talos researchers wrote in their analysis. “In many organizations data received from commonly software vendors rarely receives the same level of scrutiny as that which is applied to what is perceived as untrusted sources. Attackers have shown that they are willing to leverage this trust to distribute malware while remaining undetected.”

What makes this attack particularly worrying is the volume of downloads this software receives leaving a huge number of users exposed.
James MaudeSenior security engineer for Avecto

James Maude, senior security engineer for Avecto, a privilege management software maker, said it was especially concerning that the CCleaner malware included the official code signature from Avast.

“Given that CCleaner is designed to be installed by a user with admin rights, and the malware was not only embedded within it but also signed by the developers own code signing certificate (giving it a high level of trust), this is pretty dangerous,” Maude told SearchSecurity via email. “This means that the malware, and therefore the attacker, would have complete control of the system and the ability to access almost anything they wanted. What makes this attack particularly worrying is the volume of downloads this software receives leaving a huge number of users exposed.”

Itsik Mantin, director of security research at security software company Imperva, said the CCleaner malware incident shows “there’s not much users can do when the vendor gets infected.”

“This hack creates a new reality where users need to assume that their desktops, laptops and smartphones are infected, which has been the reality for security officers at organizations in the last years,” Mantin told SearchSecurity. “For organizations, this does not really matter as security officers are accustomed to the reality that they should always assume the attackers are in, are looking for ways to spread the infection within the organization and are searching for business sensitive data to steal or corrupt.”

Avast response to the CCleaner malware incident

Vince Steckler, CEO of Avast Software, and Ondřej Vlček, executive vice president and general manager of the consumer business unit, released a statement saying the company remediated the issue within 72 hours of becoming aware of the problem by releasing an clean update without the malware. They also stated Avast is working with law enforcement to shut down the CCleaner malware C&C server on Sept. 15th.

The Avast execs downplayed their company’s involvement by saying they “strongly suspect that Piriform was being targeted while they were operating as a standalone company, prior to the Avast acquisition,” and that the compromise “may have started on July 3rd,” two weeks before Avast’s acquisition of Piriform was complete. Avast also claimed the compromised update took four weeks to discover due to “the sophistication of the attack.”

Avast asserted users “should upgrade even though they are not at risk as the malware has been disabled on the server side,” and claimed it was unnecessary to follow the suggestions by Talos and other experts to restore systems to a date before Aug. 15, 2017 to ensure removal of the CCleaner malware.

“Based on the analysis of this data, we believe that the second stage payload never activated, i.e. the only malicious code present on customer machines was the one embedded in the ccleaner.exe binary,” Steckler and Vlček wrote. “Therefore, we consider restoring the affected machines to the pre-August 15 state unnecessary. By similar logic, security companies are not usually advising customers to reformat their machines after a remote code execution vulnerability is identified on their computer.”

Supply chain attacks

Experts said the CCleaner malware incident should be a reminder of the dangers of supply chain attacks.

Marco Cova, senior security researcher at malware protection vendor Lastline, said the recent NotPetya attacks were another case of a supply chain attack “where an otherwise trusted software vendor gets compromised and the update mechanism of the programs they distribute is leveraged to distribute malware.”

“This is sort of a holy grail for malware authors because they can efficiently distribute their malware, hide it in a trusted channel, and reach a potentially large number of users,” Cova told SearchSecurity. “It appears that the build process of CCleaner itself was compromised: that is, attackers had access to the infrastructure used to build the software itself. This is very troublesome because it indicates that attackers were able to control a critical piece of the infrastructure used by the vendor.”

Jonathan Cran, vice president of product at Bugcrowd, told SearchSecurity the CCleaner malware issue appeared to be “less of a traditional supply chain attack and more of a case of poor vendor security. Given that the affected installer was signed as a verified safe binary by Piriform, this indicates that they didn’t realize at the time of release and that the corporate network of Piriform was likely compromised.”

Justin Fier, director for cyber intelligence and analysis at threat detection company Darktrace, said this “should come as yet another wake-up call that corporations must have visibility into how their suppliers interact with their systems, as well as a real-time assessment of their suppliers’ cyber risk.”

“The risk that companies inherit from their suppliers is a pervasive problem for cybersecurity. Quite simply, companies with a supply chain cannot avoid compromises — supply chain breaches are inevitable,” Fier told SearchSecurity. “The assessment of potential supply chain partners is often a rushed process in terms of evaluating their cyber security level, and is rarely as in-depth as it should be. While we can’t change the security posture of our supply chains, we can have a transparent relationship when it comes to cyber risk.”