Let’s Encrypt hits a major milestone, F-Secure publishes their investigation into “The Dukes” & we dig into Tarsnap’s email confirmation bypass.

Plus a great batch of your questions, a rocking round up & much, much more!

Thanks to:

• Get Paid to Write for DigitalOcean

Direct Download:

HD Video | Mobile Video | MP3 Audio | OGG Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

— Show Notes: —

Let’s Encrypt goes live

• “Let’s Encrypt, a movement to issue free and automated HTTPS certificates, today hit a major milestone when its first cert went live”
• It is hoped that free, automatically generated SSL certificates will allow the web to move to HTTPS everywhere
• “A coalition of technology companies, including Mozilla, Cisco, Akamai, Automattic and IdenTrust, joined the EFF and the University of Michigan late last year in getting Let’s Encrypt off the ground; the initiative is open source and overseen by a California non-profit called Internet Security Research Group (ISRG)”
• Let’s Encrypt has done all of the setup, paperwork, and audits required to become a regular trusted Certificate Authority
• The big difference is, they will give the certificates away for free
• “IdenTrust is providing Let’s Encrypt with the cross-signature it needs in order to become a CA for existing browsers and software”
• “Eventually, webmasters will merely have to run a client to authenticate their server. They’ll also be able to enable features on their site like HTTP Strict Transport Security (HSTS), OCSP stapling and making sure that visitors to the old HTTP version of their site are redirected to the new HTTPS version”
• The cross signature is not yet in place, so Let’s Encrypt issued certificates are not trusted by existing browsers. This is expected to be in place in about a month

F-Secure publishes their investigation into “The Dukes”, a Russian APT team

• “We believe that the Dukes are a well-resourced, highly dedicated, and organized cyber-espionage group that has been working for the Russian government since at least 2008 to collect intelligence in support of foreign and security policy decision-making”
• The same group is also tracked by FireEye, where they are known as just APT29
• By combining their new research, and that of other researchers like Kaspersky, FireEye and ICDS, then going back over historical research and data from as far back as 7 years, the F-Secure researchers were able to “connect the dots” and attribute 2 older malware campaigns to this same group, and better understand the objectives of that malware
• The Dukes are known to employ a wide arsenal of malware toolsets including MiniDuke, CosmicDuke, OnionDuke, CozyDuke, SeaDuke, CloudDuke (aka MiniDionis), and HammerDuke (aka HAMMERTOSS).
• “The Dukes rapidly react to research being published about their toolsets and operations. However, the group (or their sponsors) value their operations so highly that though they will attempt to modify their tools to evade detection and regain stealth, they will not cease operations to do so, but will instead incrementally modify their tools while continuing apparently as previously planned.”
• These campaigns utilize a smash-and-grab approach involving a fast but noisy breakin
  followed by the rapid collection and exfiltration of as much data as possible. If the
  compromised target is discovered to be of value, the Dukes will quickly switch the
  toolset used and move to using stealthier tactics focused on persistent compromise
  and long-term intelligence gathering.
• In some of the most extreme cases, the Dukes have been known to engage in
  campaigns with unaltered versions of tools that only days earlier have been brought
  to the public’s attention by security companies and actively mentioned in the
  media. In doing so, the Dukes show unusual confidence in their ability to continue
  successfully compromising their targets even when their tools have been publicly
  exposed.
• This suggests they do not fear getting caught. They may have been promised protection by the Russian government
• The story of the Dukes, as it is currently known, begins with a malware toolset that F-Secure call PinchDuke.
• This toolset consists of multiple loaders and an information-stealer trojan. Importantly, PinchDuke trojan samples always contain a notable text string, which we believe is used as a campaign identifier by the Dukes group to distinguish between multiple attack campaigns that are run in parallel.
• Their first campaign appears to have in 2008, against Chechnya
• The first time the group targeted a Western government was 2009
• In 2013 the group shifted targets to the Ukraine, and also started working against drug dealers inside Russia
• On the 12th of February 2013, FireEye published a blogpost alerting readers to a combination of new Adobe Reader 0-day vulnerabilities, CVE-2013-0640 and CVE-2013-0641, that were being actively exploited in the wild. 8 days after FireEye’s initial alert, Kaspersky spotted the same exploit being used to spread an entirely different malware family from the one mentioned in the original report.
• On the 23rd of October 2014, Leviathan Security Group published a blog post describing a malicious Tor exit node they had found. They noted that this node appeared to be maliciously modifying any executables that were downloaded through it over a HTTP connection. Executing the modified applications obtained this way would result in the victim being infected with unidentified malware. On the 14th of November, F-Secure published a blog post naming the malware OnionDuke and associating it with MiniDuke and CosmicDuke, the other Duke toolsets known at the time.
• Based on the presented evidence and analysis, F-Secure believe, with a high level of confidence, that the Duke toolsets are the product of a single, large, well-resourced organization (which F-Secure identify as the Dukes) that provides the Russian government with intelligence on foreign and security policy matters in exchange for support and protection.
• The evidence seem to be pretty compelling, but it is hard to know anything for certain
• FireEye PDF — Hammertoss
• F-Secure PDF — The Dukes

Tarsnap email confirmation bypass

• Colin Percival of Tarsnap has posted a blog entry describing a flaw in the Tarsnap signup process that he recently fixed
• This provides some interesting insight into how easy it is to make a small mistake when building an application, that ends up having real world repercussions
• Because of the Tarsnap bug bounty program, a lot of fake signups are attempted against Tarsnap, to try to ‘fuzz test’ the forms on the site
• For this, and other reasons, Tarsnap requires an email verification before creating an account
• “so I wasn’t concerned when I received an email last week telling me that someone was trying to create an account as admin@tarsnap.com”
• “Five minutes later, I was very concerned upon receiving an email telling me that the registration for admin@tarsnap.com had been confirmed and the account created.”
• “This should not have happened, so I immediately started running down a list of possibilities. Was it a forged email? No, the headers showed it being delivered from the CGI script to the tarsnap web server’s qmail to the tarsnap mail server’s qmail to my inbox. Was a copy of the confirmation email — which should never have gotten past the mail server — being misdelivered somehow? No, the mail logs showed that the email to admin@tarsnap.com went from CGI script to the web server’s qmail to the mail server’s qmail and then was dropped. Was one of the CGI scripts on the tarsnap web server compromised? There was nothing in the logs to suggest a malformed request of the sort which might have been used to exploit a bug; nor, for that matter, anything to suggest that someone had been probing for bugs, so if a CGI script had been exploited, it was done completely blindly. Nevertheless, I disabled the CGI scripts just in case.”
• “Had someone managed to compromise the web server or mail server? unlikely”
• “The mystery was solved a few minutes later when an email arrived from Elamaran Venkatraman: He hadn’t compromised any servers or exploited any bugs in my C code; rather, he had found a dumb mistake in tarsnap’s account-creation process.”
• “For most people to create a Tarsnap account, only a few things are required: An email address, a password, and checkbox confirming that you agree to the Tarsnap legal boilerplate. You submit those to the Tarsnap server; it generates a registration cookie; it sends that cookie to you as part of a URL in the confirmation email; and when you click through that link and re-enter your password your account is created. So far so good — but some people need a bit more than that. Tarsnap is a Canadian company, and as such is required to remit sales tax for its Canadian-resident customers. Moreover, Tarsnap is required to issue invoices to its Canadian-resident customers — invoices which show the customers’ physical mailing addresses — so if a registrant identifies themself as being a Canadian resident, they are taken to a second page to provide their name and mailing address.”
• “But what of that confirmation email? Well, I didn’t want someone who self-identified as a Canadian resident to create an account without providing the legally-mandated information, so I couldn’t send out that email until they submitted the second page. On the other hand, they having provided their email address and password once already, I didn’t want to ask for those again. And so, when I finally got all the paperwork sorted and started accepting Canadian customers in July 2012, I took the option which was simple, obvious and completely wrong: I passed the registration cookie as a hidden variable in the second-page form, to be echoed back to the server.”
• “This of course is what Elamaran had found. To be clear, the registration cookie didn’t reveal any server internals; the only thing it could be used for was to confirm an email address. But because it was being sent in the HTML response, anyone could “confirm” any email address, simply by claiming to be a Canadian resident and viewing the page source. Oops. The fix for this was easy: Use two cookies, one for email confirmation and one for the Canadian-address-obtaining continuation. More importantly, I’ve moved the cookie-generation to where it belongs — within the routine which generates and sends the confirmation email — and I’ve added a comment to remind myself that the cookie must never be exposed via any channel other than an email destined for the address being confirmed.”
• “That last part is ultimately the most important lesson from this: Comments matter! I don’t know what I was thinking three years ago when I reused that cookie; but unless my memory was much better then than it is now, I almost certainly wasn’t thinking about my original design from four years prior. While this was hardly a fatal bug — while I’ll never know for certain, I doubt anyone exploited this email confirmation bypass, and the impact would not be severe even if someone did — it’s a reminder of the importance of writing useful comments. I often see solo developers excuse a lack of comments in their code on the basis that they understand their code and nobody else will be touching it; this misses an essential point: I am not the same person as I was three years ago, nor do I understand everything I understood three years ago. People make mistakes, and people edit code without fully understanding how and why it works. Leave breadcrumbs behind, even if you don’t intend for anyone to follow you: When you try to retrace your steps, you might get lost without them.”

Feedback

• Apple Keychain

• FreeBSD Network Troubles

• ZFS snapshots instead on the FreeNAS server?

• Can’t get enough Allan? Was recently interviewed by the BSDTalk Podcast, episode 256

Round Up:

• Ashley Madison Lawsuit: Former CTO sues security researcher for libal and more coverage
• Oracle releases fix for Virtualbox, won’t disclose what the bug was
• Malicious Cisco router backdoor found on 79 more devices, 25 in the US
• AT&T offering $250,000 USD reward for leading to the capture of the “fiber ripper”
• Dutch police arrest alleged authors of CoinVault ransomware
• Bug in iOS and OS X allow anyone within Airdrop range to overwrite arbitrary files on your system or phone
• How I created a fake business and got many positive reviews
• Cryptome announces his PGP keys have been compromised. All prior communications at risk of disclosure
• Justice Department Releases Letters to Congress about breach risk, just before Snowden
• Intel launches the Automotive Security Review Board (ASRB)
• Survey finds users need atleast 10mbps to feel like they have “broadband”
• A journey through the Yahoo bug bounty program
• Bug Bounties are a privilege, not a right
• An IT themed set of Cards Against Humanity cards

The post Dukes of Cyber Hazard | TechSNAP 233 first appeared on Jupiter Broadcasting.

Red Hat highlights how leaky many open source RSA implementations are, Netflix releases Sleepy Puppy & the Mac is definitely under attack.

Plus some quick feedback, a rockin’ roundup & much, much more!

Thanks to:

• Get Paid to Write for DigitalOcean

Direct Download:

HD Video | Mobile Video | MP3 Audio | OGG Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

— Show Notes: —

NetFlix releases new open source security tool, Sleepy Puppy

• Sleepy Puppy is a delayed XSS (Cross-Site Scripting) vulnerability scanner
• In a typical XSS scan, and attacker (or the scanner program) attempts to send a script as part of some user input (the comment on a blog or something like that, or via a URL variable). This content is then shown to that user, and often times, other users. If I can make a bit of my javascript run on your computer, when you visit someone else’s site, I have achieved XSS
• There are a number of scanners out there, and they “fuzz test” all of the inputs and variables they can find, and attempt to get some code they submit to be returned to them
• This new tool from NetFlix addresses second level vulnerabilities, and beyond
• What if an attacker injects the code on the website, and the website mitigates this, but some other application, internal or public facing, also uses the data from the database, and it then ends up being vulnerable to the XSS
• Sleepy Puppy is a “XSS payload management framework”, it generates unique code snippets for each injection, so that when a successful XSS happens, it can be tracked back to its source, even if that is outside of the application where the exploit took place
• “Delayed XSS testing is a variant of stored XSS testing that can be used to extend the scope of coverage beyond the immediate application being tested. With delayed XSS testing, security engineers inject an XSS payload on one application that may get reflected back in a separate application with a different origin.”
  • Show Diagram
• “Here we see a security engineer inject an XSS payload into the assessment target (App #1 Server) that does not result in an XSS vulnerability. However, that payload was stored in a database (DB) and reflected back in a second application not accessible to the tester. Even though the tester can’t access the vulnerable application, the vulnerability could still be used to take advantage of the user. In fact, these types of vulnerabilities can be even more dangerous than standard XSS since the potential victims are likely to be privileged types of users (employees, administrators, etc.)”
• SleepyPuppy ships with a default set of assessments includes, so is ready to use out of the box

Researchers announce new iOS vulnerability: brokenchain

• The vulnerability allows a piece of malware to access the keychain in iOS, and copy your saved passwords and other secret keys
• These keys can then be exfiltrated via SMS or HTTP etc
• When the malware attempts to access the keychain, iOS presents a dialog asking them user to allow or deny the action, but the malware can simulate a tap on the screen and accept the dialog
• Further, some malware seems to be able to cause the popup to appear off screen, so the user never even sees it
• “Special-crafted commands can be triggered by malware — or even an image or video — which causes OS X to display a prompt to click an Allow button. But rather than relying on users clicking on a button that appears unexpectedly, the button is displayed very briefly off the edge of the screen or behind the dock, and is automatically pressed using a further command. It is then possible to intercept a user’s password and send it to the attacker via SMS or any other means.”
• “Apple has been told about the vulnerability. The company has not only failed to issue a fix yet, but has not even responded to Jebara and Rahbani.”
• Ars Technica found that parts of the vulnerability have existed since 2011, and have been used actively
• “DevilRobber, the then new threat caught the attention of security researchers because it commandeered a Mac’s graphics card and CPU to perform the mathematical calculations necessary to mine Bitcoins, something that was novel at the time. Less obvious was the DevilRobber’s use of the AppleScript programming language to locate a window requesting permission to access the Keychain and then simulate a mouse click over the OK button.”
• “The same technique was being used by the Genieo adware installer to gain access to a Safari extensions list that’s protected inside the Mac Keychain.”
• The same day, another group of researchers independently found the same vulnerability
• Windows UAC has a bunch of defenses against apps users accidentally accepting or malware auto-clicking the authorization popups. Maybe we need the same in mobile OSes
• “Mac users should remember that the technique works only when invoked by an application already installed on their systems. There is no evidence the technique can be carried out through drive-by exploits or attacks that don’t require social engineering and end-user interaction. Still, the weakness is unsettling, because it allows the same app requesting access to the keychain to unilaterally approve it and to do so quickly enough for many users to have no idea what has happened. And by default, OS X will grant the access without requiring the user to enter a password. The Mac keychain is the protected place storing account passwords and cryptographic keys.”
• Maybe the solution is to require the unlock code or password in order to authorize access to sensitive areas like the keychain
• “I think that Apple needs to isolate that particular window,” Reed told Ars on Wednesday. “They need to pull that particular window out of the window list … in a way that an app can’t tell it’s on the screen and get its location.”

Factoring RSA keys with TLS Forward Secrecy

• “Back in 1996, Arjen Lenstra described an attack against an optimization (called the Chinese Remainder Theorem optimization, or RSA-CRT for short). If a fault happened during the computation of a signature (using the RSA-CRT optimization), an attacker might be able to recover the private key from the signature (an “RSA-CRT key leak”). At the time, use of cryptography on the Internet was uncommon, and even ten years later, most TLS (or HTTPS) connections were immune to this problem by design because they did not use RSA signatures.”
• “This changed gradually, when forward secrecy for TLS was recommended and introduced by many web sites.”
• “We evaluated the source code of several free software TLS implementations to see if they implement hardening against this particular side-channel attack, and discovered that it is missing in some of these implementations. In addition, we used a TLS crawler to perform TLS handshakes with servers on the Internet, and collected evidence that this kind of hardening is still needed, and missing in some of the server implementations: We saw several RSA-CRT key leaks, where we should not have observed any at all.”
• “An observer of the private key leak can use this information to cryptographically impersonate the server, after redirecting network traffic, conducting a man-in-the-middle attack. Either the client making the TLS handshake can see this leak, or a passive observer capturing network traffic. The key leak also enables decryption of connections which do not use forward secrecy, without the need for a man-in-the-middle attack. However, forward secrecy must be enabled in the server for this kind of key leak to happen in the first place, and with such a server configuration, most clients will use forward secrecy, so an active attack will be required for configurations which can theoretically lead to RSA-CRT key leaks.”
• “Does this break RSA? No. Lenstra’s attack is a so-called side-channel attack, which means that it does not attack RSA directly. Rather, it exploits unexpected implementation behavior. RSA, and the RSA-CRT optimization with appropriate hardening, is still considered secure.“
• While it appears that OpenSSL and NSS properly implement the hardening, some other products do not
• It seems RedHat discovered this issue some time ago, and reported it to a number of vendors
• Oracle patched OpenJDK back in April
• “None of the key leaks we observed in the wild could be attributed to these open-source projects, and no key leaks showed up in our lab testing, which is why this additional hardening, while certainly desirable to have, does not seem critical at this time.”
• “Once the necessary data is collected, the actual computation is marginally more complicated than a regular RSA signature verification. In short, it is quite cheap in terms of computing cost, particularly in comparison to other cryptographic attacks.”
• Then the most important question came up
• “Does this vulnerability have an name? We think that “RSA-CRT hardening” (for the countermeasure) and “RSA-CRT key leaks” (for a successful side-channel attack) is sufficiently short and descriptive, and no branding is appropriate. We expect that several CVE IDs will be assigned for the underlying vulnerabilities leading to RSA-CRT key leaks. Some vendors may also assign CVE IDs for RSA-CRT hardening, although no key leaks have been seen in practice so far.”
• Crypto Rundown, Hardened:
  • GnuPG
  • NSS
  • OpenSSL 1.0.1l
  • OpenJDK8 (after the April patch)
  • cryptlib (hardening disabled by default)
• Unhardened:
  • GNUTLS (via libgcrypt and Nettle)
  • Go 1.4.1
  • libgcrypt (1.6.2)
  • Nettle (3.0.0)
  • ocaml-nocrypto (0.5.1)
  • OpenSwan (2.6.44)
  • PolarSSL (1.3.9)
• Technical Record [PDF]

Feedback

• Reply to the pfSense question from episode 229
• Where to get news on vulnerabilities and urgent patches

Round Up:

• China and Russia cross-referencing OPM data, other hacks to out US spies
• The Zero Trust Initiative, making it possible to trust your vendors
• Hackers Stole the Biggest Number of Apple Accounts Ever with iOS Malware Researcher Post
• The police body camera business is not about camera, but overpriced cloud storage. 300 Cameras: $180,000. 5 year contract for storage: $889,000
• Pre-Installed Android Malware Raises Security Risks in Supply Chain
• AppLock, a popular Android app that claims to securely store photos, videos, and other content, turns out to just hide the files in a non-default location. It also has a weak pin reset feature, meaning it provides basically no security to its 100 million users
• Android ransomware uses XMPP chat to call home, claims it’s from NSA
• The Government should pay bug bounties and not attack security researchers
• Department of Justice being sued by Reuters for not fulfilling FoIA requests re: fake news stories with embedded malware used in 2007
• If documents are not for public release, try not posting them on the public Internet

The post Leaky RSA Keys | TechSNAP 231 first appeared on Jupiter Broadcasting.

Vulnerabilities in iOS & Android devices announced today, both are in the wild with no fix yet. We’ll share the details. Comcast wants to buy T-Mobile, Microsoft shakes it up, Kodi gets banned & more!

Direct Download:

MP3 Audio | OGG Audio | Video | HD Video | Torrent | YouTube

RSS Feeds:

MP3 Feed | OGG Feed | iTunes Feed | Video Feed | Video Feed | Torrent Feed

Become a supporter on Patreon

Show Notes:

Episode Links:

• Researchers Find Major Keychain Vulnerability in iOS and OS X – Slashdot
• Samsung Cellphone Keyboard Software Vulnerable To Attack – Slashdot
• Comcast said to be leading suitor in T-Mobile buyout – CNET
• Microsoft Shakes Up Its Leadership And Internal Structure As Its Fiscal Year Comes To A Close | TechCrunch
• Let’s Encrypt Launch Schedule
• Amazon Bans Kodi/XBMC App Over Piracy Concerns | TorrentFreak

The post Comcast's Next Prey | Tech Talk Today 184 first appeared on Jupiter Broadcasting.

Internet Explorer, Ruby on Rails, and the Windows Nvidia drivers all have new exploits. We’ll tell you the good, the bad, and the ugly.

Plus picking the right VPS, a big batch of your questions, and Allan’s videos from EuroBSD Con.

On this week’s episode of TechSNAP!

Thanks to:

Use our code tech295 to get a .COM for $2.95.

Something else in mind? Use go20off5 to save 20% on your entire order!

Pick your code and save:
techsnap7: $7.49 .com
techsnap10: 10% off
techsnap11: $1.99 hosting for the first 3 months
techsnap20: 20% off 1, 2, 3 year hosting plans
techsnap40: $10 off $40
techsnap25: 25% off new Virtual DataCenter plans
techsnapx: 20% off .xxx domains

 

Support the Show: