Viewing entries tagged
cryptography

Comment

Threatpost - Google Chrome 57 Browser Update Patches ‘High’ Severity Flaws

Google released an updated version of its Chrome browser on Thursday to fix nine high-severity vulnerabilities that if exploited could allow adversaries to take control of targeted systems. As part of the update, Google thanked nearly two dozen bug hunters with bug bounty payments totaling $38,000.

Topping the list of vulnerabilities patched are; a memory corruption flaw in the V8 JavaScript engine, a use after free bug found in Google’s Almost Native Graphics Layer Engine, and an out-of-bounds write flaw found in the PDFium component of the Chrome browser.

Google said its Chrome version 57.0.2987.98 update for Windows, Mac and Linux includes a number of fixes and improvements; and will roll out them over the coming days and weeks. Beta Chrome 57 was introduced in February and included new features CSS grid layout, improved add to home screen, Media Session API. The Chrome 57.0.2987.98 was released to Google’s Stable channel, which means the software is fully tested by the Chrome OS team.

n November, Google said it removed support for SHA-1 certificates in Chrome 56, but will distinguish between certificates chained to a public Certificate Authority and those chained to local CAs. However, with the introduction of Chrome 57, released to the Stable channel in March, Google said at the time, “Features which require a secure origin, such as geolocation, will continue to work, however pages will be displayed as ‘neutral, lacking security.’ Without this policy set, SHA-1 certificates that chain to locally installed roots will not be trusted starting with Chrome 57.”

Google did not mention the additional SHA-1 notification feature Thursday with the rollout of Chrome 57.0.2987.98. However, it said more information regarding Chrome 57 is pending via its Chrome and Chromium blog.

The Chrome security holes were disclosed to Google’s Chromium Project and its bug bounty program. The largest bounty paid was for $7,500 and paid to researcher Brendon Tiszka for the (CVE-2017-5030) memory corruption flaw in the V8 JavaScript engine.

The second highest bounty of $5000 was paid to researcher Looben Yang for the use after free bug (CVE-2017-5031) found in Google’s Almost Native Graphics Layer Engine.

Comment

.author-name { display: none; }

Comment

Threat Post - Confide Updates App After Critical Security Issues Are Raised

The makers of the popular messaging app Confide said Wednesday that it has patched multiple security vulnerabilities that could have allowed hackers to intercept messages sent using its secure end-to-end messaging platform.

The flaws were identified in two separate reports, both released Wednesday, by security firms IOActive and Quarkslab. Both allege there are critical security vulnerabilities in versions of Confide’s encrypted messaging app, including version 4.0.4 for Android and 1.4.2 for Windows and OS X .

The security of Confide’s platform has taken center stage ever since reports surfaced last month that senior White House staff, including press secretary Sean Spicer, were using the app. Confide claims to offer “battle tested, military grade encryption.” According to Google Play, the Android app has been installed between 100,000 to 500,000 times.

Researchers with IOActive said the Confide suffered from a bevy of security vulnerabilities including:

  • Confide’s notification system did not require a valid SSL server certificate to communicate, therefore opening the door for an attacker to perform a man-in-the-middle attack.
  • The app lacked sufficient notifications when unencrypted messages were sent and received.
  • The application failed to have adequate protections to prevent brute-force attacks on user account passwords.
  • Confide’s website was vulnerable to an arbitrary URL redirection, which could facilitate social engineering attacks against its users.

IOActive also raised issues with Confide’s handling of public keys.

“Confide failed to provide a participant fingerprint authentication mechanism, allowing Confide to conduct man-in-the-middle attacks on encrypted messages by changing the public keys sent to parties of a conversation,” wrote IOActive researchers Mike Davis, Ryan O’Horo and Nick Achatz, who co-authored the report.

Quarkslab also took issue with some of security vulnerabilities highlighted by IOActive, and singled out the way Confide handled public and private encryption keys.

“The most obvious problem… is linked to the fact that the encrypted message origin and the authenticity of the public encryption key transmitted by the server can in no way be verified by the client,” wrote Jean-Baptiste Bédrune, security researcher with Quarkslab.

“The Confide server could generate its own key pair and transmit the public part to a client when the latter requests the public key of a recipient (we only note that Confide is able to do so, not that it does so). This client then unknowingly encrypts a message that can be decrypted by the server. Finally, when the server sends the message to the recipient, it is able to re-encrypt the message with its own key for the actual recipient,” Bédrune wrote.

Similar public key concerns were raised earlier this year when researchers commented on how WhatsApp and earlier versions of iMessage handled key change notifications. In February, Jonathan Zdziarski, an independent security researcher and forensics expert, wrote about Confide’s key exchange approach.

“What seems different about (Confide) encryption is that it appears to regenerate the public key under certain circumstances. It’s unclear why, but unlike Signal and WhatsApp, which consider it something to alert you about if your public key changes, Confide appears to consider this part of its function. Key exchange is always the most difficult part of good encryption routines. Depending on whether or not Confide is able to detect this and warn the user, it’s possible (although not confirmed) that the application could be susceptible to the same types of man-in-the-middle attacks that we’ve seen theorized in WhatsApp (if you leave the alerts off) and iMessage,” Zdziarski wrote.

Bédrune said the confidentiality of the exchanged messages depends on the robustness of TLS.

“Confide can technically read all the messages that pass through its servers. End-to-end encryption, as it is implemented, solely relies on the server through which the messages pass,” he said.

Quarkslab also claims that security features in the Android, iOS and desktop app, such as message deletion and screenshot prevention, can be easily circumvented.

For its part, Confide co-founder Jon Brod told Threatpost via email Wednesday the company was able to fix the issues quickly.

“We were able to detect anomalous behavior and remediate many of the issues during IOActive’s testing in real time starting on February 24. We were able to quickly address the remaining issues after the initial contact and roll out client updates in less than 48 hours. Not only have these issues been addressed, but we also have no detection of them being exploited by any other party. We do acknowledge the findings, but believe that the firm is overstating the severity level of some of them.”

IOActive claims the company privately disclosed its research to Confide in February and that Confide fixed the issues and updated the app on March 3, 2017.

Brod did not address the security concerns raised by Quarkslab.

“All the issues have been reported to Confide, and they are working on fixing them. In the meantime, do not consider your conversations to be so well concealed,” Bédrune wrote.

Comment

.author-name { display: none; }