Dukes of Cyber Hazard | TechSNAP 233

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:

RSS Feeds:

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