Long Broken SSL History | TechSNAP 289

chris

6 years ago

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Spreading the DDoS Disease and Selling the Cure

Krebs has done some more digging into DDoS for hire businesses
“Earlier this month a hacker released the source code for Mirai, a malware strain that was used to launch a historically large 620 Gbps denial-of-service attack against this site in September. That attack came in apparent retribution for a story here which directly preceded the arrest of two Israeli men for allegedly running an online attack for hire service called vDOS. Turns out, the site where the Mirai source code was leaked had some very interesting things in common with the place vDOS called home.”
“The domain name where the Mirai source code was originally placed for download — santasbigcandycane[dot]cx — is registered at the same domain name registrar that was used to register the now-defunct DDoS-for-hire service vdos-s[dot]com”
“Normally, this would not be remarkable, since most domain registrars have thousands or millions of domains in their stable. But in this case it is interesting mainly because the registrar used by both domains — a company called namecentral.com — has apparently been used to register just 38 domains since its inception by its current owner in 2012, according to a historic WHOIS records gathered by domaintools.com (for the full list see this PDF).”
That is highly unusual, the cost of ICANN accreditation ($3,500, plus $4,000/year) makes this seem unlikely
“What’s more, a cursory look at the other domains registered via namecentral.com since then reveals a number of other DDoS-for-hire services, also known as “booter” or “stresser” services.”
vDoS, before it was taken down by authorities thanks to Krebs, was hacked, and its user database and history were posted online. From this data, Krebs was able to gather a list of other DDoS for Hire services, that were just reselling the vDoS service, using its API to launch attacks on behalf of their own customers
“And a number of those vDOS resellers were registered through Namecentral, including 83144692[dot].com — a DDoS-for-hire service marketed at Chinese customers. Another Namecentral domain — vstress.net — also was a vDOS reseller.”
“Other DDoS-for-hire domains registered through Namecentral include xboot[dot]net, xr8edstresser[dot]com, snowstresser[dot]com, ezstress[dot]com, exilestress[dot]com, diamondstresser[dot]net, dd0s[dot]pw, rebelsecurity[dot]net, and beststressers[dot]com.”
So, it seems a lot of these might have actually been the same company, just with many faces
“Namecentral’s current owner is a 19-year-old California man by the name of Jesse Wu. Responding to questions emailed from KrebsOnSecurity, Wu said Namecentral’s policy on abuse was inspired by Cloudflare, the DDoS protection company that guards Namecentral and most of the above-mentioned DDoS-for-hire sites from attacks of the very kind they sell.”
When asked about why the registrar had so few domains: Wu: “Like most other registrars, we register domains only as a value added service,” he replied via email. “We have more domains than that (not willing to say exactly how many) but primarily we make our money on our website/ddos protection/ecommerce protection.”
Wu: “We have a policy inspired by Cloudflare’s similar policy that we ourselves will remain content-neutral and in the support of an open Internet, we will almost never remove a registration or stop providing services, and furthermore we’ll take any effort to ensure that registrations cannot be influenced by anyone besides the actual registrant making a change themselves – even if such website makes us uncomfortable,” Wu said. “However, as a US based company, we are held to US laws, and so if we receive a valid court issued order to stop providing services to a client, or to turn over/disable a domain, we would happily comply with such order.”
“Taking a page from Cloudflare, indeed. I’ve long taken Cloudflare to task for granting DDoS protection for countless DDoS-for-hire services, to no avail. I’ve maintained that Cloudflare has a blatant conflict of interest here, and that the DDoS-for-hire industry would quickly blast itself into oblivion because the proprietors of these attack services like nothing more than to turn their attack cannons on each other. Cloudflare has steadfastly maintained that picking and choosing who gets to use their network is a slippery slope that it will not venture toward.”
“Although Mr. Wu says he had nothing to do with the domains registered through Namecentral, public records filed elsewhere raise serious unanswered questions about that claim.”
Krebs found a paper trail linking a number of the DDoS for Hire services to Thomas McGonagall, who at one point is also listed as the directory of “Namecentral LTD”
“Now we were getting somewhere. Turns out, Wu isn’t really in the domain registrar business — not for the money, anyway. The real money, as his response suggests, is in selling DDoS protection against the very DDoS-for-hire services he is courting with his domain registration service.”
But then Krebs caught Wu in a lie
“That other company —SIMPLIFYNT LTD — was registered by Mr. McGonagall on October 29, 2014. Turns out, almost the exact same information included in the original Web site registration records for Jesse Wu’s purchase of Namecentral.com was used for the domain simplifynt.com, which also was registered on Oct. 29, 2014. I initially missed this domain because it was not registered through Namecentral. If someone had phished Mr. Wu in this case, they had been very quick to the punch indeed.”
“In the simplyfynt.com domain registration records, Jesse Wu gave his email address as jesse@jjdev.ru. That domain is no longer online, but a cached copy of it at archive.org shows that it was once a Web development business. That cached page lists yet another contact email address: sales@jjdevelopments.org. I ordered a reverse WHOIS lookup from domaintools.com on all historic Web site registration records that included the domain “jjdevelopments.org” anywhere in the records. The search returned 15 other domains, including several more apparent DDoS-for-hire domains such as twbooter69.com, twbooter3.com, ratemyddos.com and desoboot.com.”
“Among the oldest and most innocuous of those 15 domains was maplemystery.com, a fan site for a massively multiplayer online role-playing game (MMORPG) called Maple Story. Another historic record lookup ordered from domaintools.com shows that maplemystery.com was originally registered in 2009 to a “Denny Ng.” As it happens, Denny Ng is listed as the co-owner of the $1.6 million Walnut, Calif. home where Jesse until very recently lived with his mom Cindy Wu (Jesse is now a student at the University of California, San Diego).”
Then there is another person, that uses Namecentral
“Another domain of interest that was secured via Namecentral is datawagon.net. Registered by 19-year-old Christopher J. “CJ” Sculti Jr., Datawagon also bills itself as a DDoS mitigation firm. It appears Mr. Sculti built his DDoS protection empire out of his parents’ $2.6 million home in Rye, NY. He’s now a student at Clemson University, according to his Facebook page.”
Krebs talked to this person back in 2015 about their cybersquatting suit with Dominos Pizza, and when Sculti didn’t like what Krebs wrote about him, he started DDoS’ing Krebs’ skype account and website.
“Last year, Sculti formed a company in Florida along with a self-avowed spammer. Perhaps unsurprisingly, anti-spam group Spamhaus soon listed virtually all of Datawagon’s Internet address space as sources of spam.”
“Are either Mr. Wu or Mr. Sculti behind the Mirai botnet attacks? I cannot say. But I’d be willing to bet money that one or both of them knows who is. In any case, it would appear that both men may have hit upon a very lucrative business model. More to come.”
DDoS Protection services, with connections to DDoS for Hire services, sounds an aweful lot like racketeering to me

The VeraCrypt Audit Results

“The QuarksLab audit of VeraCrypt has been completed, and this is the public release of the results”
The quick and dirty:
VeraCrypt 1.18 and its bootloaders were evaluated. This release included a number of new features including non-western developed encryption options, a boot loader that supports UEFI (modern BIOSes), and more. QuarksLab found:
8 Critical Vulnerabilities
3 Medium Vulnerabilities
15 Low or Informational Vulnerabilities / Concerns
“This public disclosure of these vulnerabilities coincides with the release of VeraCrypt 1.19 which fixes the vast majority of these high priority concerns. Some of these issues have not been fixed due to high complexity for the proposed fixes, but workarounds have been presented in the documentation for VeraCrypt.”
“VeraCrypt is much safer after this audit, and the fixes applied to the software mean that the world is safer when using this software.”
“I’d also like to extend a special thank you to Fred, Jean-Baptiste, and Marion at QuarksLab for conducting this audit, to Mounir at Idrix for his enthusiastic participation and continued development of this crucial open-source software, and to VikingVPN and DuckDuckGo and all of our individual donors for the funding to make this audit possible. We have all made the digital world a little bit safer for all of us.”
“This report describes the results of the security assessment of VeraCrypt 1.18 made by Quarkslab between Aug. 16 and Sep. 14, 2016 and funded by OSTIF. Two Quarkslab engineers worked on this audit, for a total of 32 man-days of study.”
The audit followed two lines of work:
The analysis of the fixes introduced in VeraCrypt after the results of the Open Crypto Audit Project’s audit of TrueCrypt 7.1a have been published.
- The assessment of VeraCrypt’s features that were not present in TrueCrypt.
“VeraCrypt is a hard to maintain project. Deep knowledge of several operating systems, of the Windows kernel, of the system boot chain and good concepts in cryptography are required. The improvements made by IDRIX demonstrate the possession of these skills.”
“Vulnerabilities which require substantial modifications of the code or the architecture of
the project have not been fixed. These include:”
TC_IOCTL_OPEN_TEST multiple issues (need to change the application behavior)
EncryptDataUnits() lacks error handling (need to design a new logic to retrieve
errors)
AES implementation susceptible to cache-timing attacks (need to fully rewrite the AES implementations)
“Vulnerabilities leading to incompatibilities with TrueCrypt, as the ones related to cryptographic mechanisms, have not been fixed. Most notable are:”
Keyfile mixing is not cryptographically sound
Unauthenticated ciphertext in volume headers.
“Among the problems found during the audit, some must be corrected quickly:”
The availability of GOST 28147-89, a symmetric block cipher with a 64-bit block size, is an issue. This algorithm must not be used in this context.
Compression libraries are outdated or poorly written. They must be updated or replaced
If the system is encrypted, the boot password (in UEFI mode) or its length (in legacy mode) could be retrieved by an attacker
“Finally, the UEFI loader is not mature yet. However, its use has not been found to cause security problems from a cryptographic point of view”
The full assessment PDF is on the website linked at the top of this story
With the original authors not around to sue anyone, it seems this Apache 2 licensed fork will continue, and might not be a bad choice for those that need to encrypt files across OSes

SSL/TLS and PKI History

“A comprehensive history of the most important events that shaped the SSL/TLS and PKI ecosystem. Based on Bulletproof SSL and TLS, by Ivan Ristić”
It starts in November of 1994: “Netscape develops SSL v2, an encryption protocol designed to support the Web as a hot new commerce platform. This first secure protocol version shipped in Netscape Navigator 1.1 in March 1995.”
A year later: “SSL v2 is shot down because of serious security issues. Consequently, Netscape scrambles to release SSLv3. This protocol seems good enough for now and the golden era of the Web begins. The specification was eventually published as RFC 6101”
So, we knew SSLv2 was bad, in 1995… why was it still in use in 2015?
January 1999: “In 1996, an IETF working group is formed to standardize SSL. Even though the resulting protocol is almost identical to SSL v3, the process takes 3 years. TLS v1.0 is published as RFC 2246. Microsoft forces the change of protocol name to Transport Layer Security (TLS), creating a confusion that continues to this day.”
January 2001: “Someone calls VeriSign claiming to be from Microsoft, pays $400, and gets away with two code-signing certificates. The certificates have no special powers, but the owner name is misleading and potentially dangerous.”
April 2006: “A new version of the TLS protocol is released as RFC 4346. This version addresses the BEAST attack, but it will be 5 years before the world realizes.”
June 2007: “In the early days, CAs are strict about identify verification before certificate issuance. Eventually, some CAs realise that they can get away with less work and domain-validated (DV) certificates are born. To restore the balance, Extended Validation (EV) certificates are designed as a way of guaranteeing a connection between a domain name and a real-life business entity.”
It used to require a lot of money ($100s or $1000s), a lot of paperwork, and a reasonable amount of time to get an SSL certificate. Eventually DV certificates meant anyone could get a cert for $9 a year. So the CAs came up with a way to charge $100s again.
May 2008: “It is discovered that a catastrophic programming error had been introduced to Debian in September 2006, becoming part of the official release in April 2007. All private keys generated on vulnerable systems were insecure.”
August 2008: “A new version of TLS is released as RFC 5246, although hardly anyone notices. A major new feature in this version is authenticated (AEAD) encryption, which removes the need for streaming and block ciphers (and thus the inherently vulnerable CBC mode).”
July 2009: “SSL Labs launches to build better tools for secure server assessment and research how SSL/TLS and PKI are used in practice.”
March 2011: “The IETF attempts to formally deprecate SSL v2 by publishing RFC 6176. According to SSL Labs, 54% HTTPS servers supported this obsolete protocol version in 2011.”
August 2011: DigiNotar
July 2012: “After their success with EV certificates, the CA/Browser Forum publishes Baseline Requirements to standardise issuance of all certificates.”
May 2013: “Edward Snowden releases thousands of classified NSA documents to selected journalists, changing the public’s perspective of the Internet forever. We eventually realise the extent of passive monitoring of plaintext communication.”
August 2013: “Work on TLS 1.3 begins. Although TLS 1.2 seems good enough for now, it’s clear that it can’t support the next few decades of Internet evolution. Thus, work on the next-generation encryption protocol begins.”
January 2014: “At the beginning of 2014, 1024-bit RSA keys for subscriber certificates are retired; 2048-bit RSA certificates become the new minimum. Weak intermediate and root keys remain in use.”
April 2014: “A critical vulnerability in OpenSSL, a very widely used TLS library, is discovered. If exploited, Heartbleed enables attackers to retrieve process memory from vulnerable servers, often resulting in private key compromise. Because of tremendous hype associated with the attack, most public servers fix the vulnerability practically overnight. A long tail of vulnerable devices remains, though. Heartbleed’s biggest contribution is showing the world how severely underfunded the OpenSSL project was in its 20 years of existence. In the following months, large organisations start contributing to the project and a big cleanup begins.”
February 2015: “The IETF publishes RFC 7465 to formally prohibit usage of the weak but ever-popular RC4 cipher.”
November 2015: “Let’s Encrypt is launched to provide free certificates with automated issuance. It is widely expected that this new non-profit CA will further drive down the price of DV certificates and encourage similar programs from other, more established CAs. However, it is their focus on automated issuance that excites, allowing all infrastructure to be protected.”
January 2016: “CAs are no longer allowed to issue public SHA1 certificates. The key word here is “public”. Some CAs continue to issue SHA1 certificates from roots that are not trusted by modern browsers, but continue to be trusted by older devices.”
February 2016: “Previous versions of SSL and TLS were either rushed (SSL v2 and SSL v3) or maintenance efforts (TLS v1.0-v1.2). With TLS v1.3, the working group is taking a different approach; after more than two years in development, a workshop is held to carefully analyse the new designs.”
The timeline extends into the future
January 2017: Browsers will stop accepting all SHA1 certificates
July 2018: “From July 2018, PCI-compliant merchants must not support TLS 1.0. Originally, this date was intended to be in July 2016, but that was not realistic because of too many users relying on obsolete technology that doesn’t support modern protocols.”

Long Broken SSL History | TechSNAP 289

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Spreading the DDoS Disease and Selling the Cure

The VeraCrypt Audit Results

SSL/TLS and PKI History

Feedback:

Round Up: