How the hack of DigiNotar changed the infrastructure of the Internet forever, changing the way we think about security & how to hide malware in a PNG.

Plus a packed round up, great emails & more in a packed 300th episode!

RSS Feeds:

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

Become a supporter on Patreon:

Patreon

Show Notes:

How the hack of DigiNotar changed the infrastucture of the Internet forever

  • Think back to TechSNAP Episode 22: http://www.jupiterbroadcasting.com/11948/rooted-trust-techsnap-22/
  • “On Saturday, Aug. 27, 2011, an Iranian man who went by the online alias alibo tried to check his email—only to find he couldn’t connect to Gmail. Yet the problem disappeared when he connected to a virtual private network that disguised his location. Whatever was going on, it seemed to only affect computer users in Iran.”
  • “His first hunch was that the problem might be somehow tied to the Iranian government—which was known for interfering with online activity—or a problem with his local internet service provider. So alibo posted a question about the issue on the Gmail Help Forum. Two days later, Google responded to this apparently small problem in a big way: It issued a public statement about the incident, attributing the problem to security issues at a Dutch company called DigiNotar. Within a month, DigiNotar had been taken over by the Dutch government. Not long after that, it declared bankruptcy and dissolved.”
  • “Cybersecurity breaches don’t usually spell the end of companies, much less spur national governments to seize control of private firms. But the DigiNotar compromise was unusual in many ways. Usually, the cybersecurity incidents we read about involve a company failing to protect the information entrusted to it by users. DigiNotar was different: Its whole reason for existence was to tell internet users who and what they could trust—and in 2011, it failed spectacularly in that mission.”
  • This started a radical shift in the way a lot of things are done on the Internet
  • Suddenly, that archaically maintained list of Certificate Authorities started to be scrutinized.
  • Originally, the list often included quasi-government controlled agencies, but the trend over the previous 10 years had seen the shift towards commercial entities.
  • Now, we needed a better way to police the actions and procedures of these Certificate Authorities, because the security of almost all of our systems depend on them
  • The point of the Certificate Authority, is to Certify that the system you are connecting to, actually belongs to your bank, and not the russian mafia. Your browser or operating system usually gives them this authority, by including their certificate in the ‘root trust store’
  • They are basically like countries, and they issue websites a passport, proof that the website is who they claim to be. It only works if you trust the issuer of the passport.
  • “Five years later, the story of DigiNotar’s demise is all but forgotten, eclipsed by a series of more recent, more easily understandable, and more exciting breaches. But DigiNotar’s case has had long-lasting impacts, motivating some much needed improvements in the security of our online trust infrastructure, including a set of new minimum security requirements for companies like DigiNotar that were announced earlier this month by the Certificate Authority Security Council.”
  • “in 2015, a root CA operated by the China Internet Network Information Center issued an intermediate certificate to one of its customers, which then used the certificate to perform man-in-the-middle attacks and potentially intercept traffic between users and websites.”
  • “Any of those trusted CAs, whether they are root CAs or intermediate CAs that have been endorsed, can then issue certificates for any website they choose—even websites that have chosen to buy certificates from different CAs.”
  • To address this, there is a push for a system called Certificate Transparency, where every certificate, as it is issued, it published to immutable logs kept by 3rd parties.
  • Google Chrome began requiring Certificate Transparency for newly issued Extended Validation Certificates in 2015. It began requiring Certificate Transparency for all certificates newly issued by Symantec from June 1, 2016, after they were found to have issued 187 certificates without the domain owners’ knowledge.
  • Certificate Search is a tool that uses various Certificate Transparency logs (including Googles) to let you see all certificates that have been issued or seen for various domains or organizations
  • This provides a number of facets of security:
  • Your browser can check that the certificate you are being presented, is one listed on the transparency log, meaning it is not one a government is trying to keep secret, and one that has been legitimately issued.
  • It makes it possible to publically audit the activities of Certificate Authorities. If only certificates that are logged are trusted, and they cannot scrub a certificate from the logs, they cannot hide the fact that they incorrectly issued a certificate. This is why Google demanded participation in CT from Symantec after their screwup
  • A website operator can automatically search for and find any certificates issued on their behalf, to confirm they are legitimate
  • “Because CAs are prime targets, they have to—and tend to—take security very seriously. DigiNotar was no exception. Among other things, it had segmented its computer networks into several different isolated partitions to constrain access attempts and used an intrusion prevention system to monitor incoming traffic. Every request for a new certificate had to be vetted and approved by two DigiNotar employees. Then, to issue the certificate, an employee had to insert a physical key card into a computer kept in a heavily guarded room.”
  • According to a postmortem report on DigiNotar’s compromise by security firm Fox-IT: “This room could be entered only if authorized personnel used a biometric hand recognition device and entered the correct PIN code. This inner room was protected by an outer room connected by a set of doors that opened dependent on each other creating a sluice. These sluice doors had to be separately opened with an electronic door card that was operated using a separate system than for any other door. To gain access to the outer room from a publicly accessible zone, another electronic door had to be opened with an electronic card.”
  • “This mix of physical and virtual safeguards demonstrates that DigiNotar was not a company that had failed to think about or invest in security. It understood that its security was vital for its own reputation—and for the wider world of internet users who relied, often without even knowing it, on DigiNotar’s certificates to tell them whom to trust online.”
  • “But DigiNotar also made some serious mistakes during the summer of 2011. For one, it was running some unpatched software one its web servers, which allowed an intruder to begin burrowing into its maze of partitioned networks in June 2011. On July 10, the intruder successfully issued his first rogue certificate. All told, by the end of the summer, he would go on to issue 531 rogue certificates for domains ranging from aol.com and microsoft.com to mossad.gov.il and cia.gov. (Once you’ve got access to a CA server, issuing rogue certificates for high-value targets like the CIA is no harder than issuing them for sites like AOL.)”
  • “It’s still unclear how exactly the intruder managed to bypass all the physical security in place to protect the inner sanctum where certificates were generated, but the investigators’ best guess was that the keycards for a few computers were left permanently in place. If true, it would have largely defeated the purpose of requiring the keycard insertion—not to mention all those sluiced doors and biometrics and PIN codes—in the first place.”
  • Again, all that security defeated by: pesky humans
  • “On July 19, a routine check by DigiNotar revealed that some of the certificates it had ostensibly signed were not listed in the company’s logs—indeed, DigiNotar had no records of ever issuing these certificates. They were promptly revoked, and DigiNotar launched an internal investigation that uncovered still more rogue certificates. But by the end of July, the company believed the problem had been dealt with.”
  • “So it came as a shock when the report from alibo, the Iranian user, surfaced on the Gmail Help Forum a month later, and Google, in turn, blamed an unauthorized google.com certificate issued by DigiNotar. Some of the rogue certificates, it seemed, had slipped through the cracks of DigiNotar’s internal audit. And they were being used to certify impostor websites. Thousands of Iranians who tried to visit Google websites in August 2011 were apparently redirected to sites that looked like Google webpages and were also certified as belonging to Google according to certificates issued by DigiNotar. Users from 298,140 unique internet protocal addresses trying to access Google websites were affected, and 95 percent of those IP addresses originated in Iran.”
  • “Why bother redirecting hundreds of thousands of Iranian Google users to fraudulent websites? Probably in order to read their email. Only one thing stood in the way: Google Chrome.”
  • Google had taken to hard-coding the hashes of the certificates for Google owned websites into the Chrome browser, specifically to detect this type of situation, where a supposedly trusted certificate was in fact not authorized by Google
  • This effort has since been expanded, with other browsers implementing similar certificate pinning systems. This are also systems for individual websites to security publish the hash of the trusted certificate, so that the browser will warn users presented with the wrong certificate.
  • Some of these, like TLSA, require DNSSEC, as the hash is published in DNS, and needs to be protected from being spoofed as well
  • “No one has ever been caught or charged with the compromise, though many have speculated that Iran’s government was likely involved. The only clue left by the intruder—a message left behind on a DigiNotar server—offers little insight into the perpetrator’s mission or identity other than a profound sense of self-importance. “I know you are shocked of my skills, how I got access to your network,” the message begins. “THERE IS NO [sic] ANY HARDWARE OR SOFTWARE IN THIS WORLD EXISTS WHICH COULD STOP MY HEAVY ATTACKS MY BRAIN OR MY SKILLS OR MY WILL OR MY EXPERTISE.””
  • “The discovery of the DigiNotar compromise left the browser and CA community—to say nothing of the Dutch government—reeling. Browser vendors rushed to revoke trust in DigiNotar certificates, but removing a root CA was not entirely straightforward. “We actually needed to push out an update to Firefox because the CA information was hard-coded to the browser,” Firefox security lead Richard Barnes said. Additionally, many legitimate websites (including some operated by the Dutch government) were still relying on DigiNotar certificates, so the browser vendors were forced to hold off on a blanket ban. Instead, Mozilla decided to block all DigiNotar certificates issued after July 1, 2011, but allowed users to decide whether they wanted to trust certificates issued by the company before that date. But giving users that autonomy over their online security only works if they understand what it is they’re choosing and the implications of that choice—a task that surely went beyond many Firefox users.”
  • “While the browsers scrambled to protect their users, the Dutch government took charge of DigiNotar and commissioned Fox-IT to investigate what had gone wrong. Hans Hoogstraaten, who led the investigation, said in an email, “What really shocked me was when I realized the impact it had for the people of Iran. In those days … people got killed for having a different opinion. The hackers (presumably the state) had access to over 300,000 Gmail accounts. The realization that the … security of a small company in Holland [may have] played a part in the killing or torture of people really shocked me.””
  • “Perhaps the most significant change in the certificate landscape is simply that there are now many more certificates than there were five years ago. This is part of a larger push for widespread online encryption spearheaded by the CA Let’s Encrypt, launched earlier this year, which provides free certificates to anyone who wants them. Let’s Encrypt doesn’t provide the Extended Validation certificates that involve verifying a website owner’s identity (the kind that most high-value targets generally get and that warrant a green box in many browsers) because that process cannot be automated. “There are hundreds of millions of websites and devices out there, and in the future there will be many billions. For every one to have a certificate we’ll need issuance systems that can be fully automated,” said Josh Aas, founder of the Internet Security Research Group, which established Let’s Encrypt. Issuing more certificates helps spread encryption, but it also raises the stakes for the security of CAs and the risks posed by incidents like the DigiNotar compromise because it means that an increasing amount of our online communication relies on the protection provided by digital certificates.”
  • I almost wonder if LetsEncrypt should use a new intermediate CA for each calendar day. So that if there was some kind of compromise, they could dis-trust the intermediates from a specific date range, with much less impact on the other certificates.
  • “And problems with CAs have not gone away. On March 20, 2015, years after the collapse of DigiNotar, Google discovered another set of rogue certificates for Google domains. These certificates had been issued by an Egyptian company, MCS Holdings, which had, in turn, received its certificates from CNNIC, the CA operated by the China Internet Network Information Center, an agency in the Chinese government’s Ministry of Information Industry. Soon afterward, Firefox and Chrome both removed CNNIC from their root CA lists. Just this summer, Chinese CA WoSign was accused of issuing fake certificates for Github and Alibaba, and in October Mozilla announced that it would no longer trust WoSign certificates.”
  • “Thanks in no small part to the legacy of DigiNotar, browsers and CAs alike are better able to deal with problems like these than they were five years ago—they can revoke compromised certificates faster, check certificates against public logs, and restrict the use of rogue certificates with pinning. But in other, more fundamental ways, the system of relying on CAs to tell us who we can trust online remains inherently vulnerable—and, perhaps more importantly, largely invisible to most internet users. The complexity of the certificate infrastructure can make it difficult for the wider public—beyond the community of browsers and CAs who have long been attuned to the importance of the DigiNotar compromise—to understand the risks they face online, as well as the signals and warnings that their browsers provide.”
  • ““The folks who operate the CAs are really a very tempting point of attack,” said Daniel Kahn Gillmor, a senior staff technologist with the American Civil Liberties Union’s Speech, Privacy and Technology Project. “If I wanted to attack someone else I would be looking for a lever of control that they might not even know existed.” The more we gloss over the crucial components of the trust infrastructure underlying our online communications—an infrastructure that is every bit as relevant today as it was five years ago—the harder it becomes to grasp how deeply and fundamentally all of our security is predicated on the security of digital certificates and the companies that issue them.”
  • While much is changed, not all of the issued are solved yet, and we can expect to see more of this as we go forward

Changing the way we think about security: Class Breaks

  • “There’s a concept from computer security known as a class break. It’s a particular security vulnerability that breaks not just one system, but an entire class of systems. Examples might be a vulnerability in a particular operating system that allows an attacker to take remote control of every computer that runs on that system’s software. Or a vulnerability in Internet-enabled digital video recorders and webcams that allow an attacker to recruit those devices into a massive botnet.”
  • “It’s a particular way computer systems can fail, exacerbated by the characteristics of computers and software. It only takes one smart person to figure out how to attack the system. Once he does that, he can write software that automates his attack. He can do it over the Internet, so he doesn’t have to be near his victim. He can automate his attack so it works while he sleeps. And then he can pass the ability to someone­ — or to lots of people — ­without the skill. This changes the nature of security failures, and completely upends how we need to defend against them.”
  • “An example: Picking a mechanical door lock requires both skill and time. Each lock is a new job, and success at one lock doesn’t guarantee success with another of the same design. Electronic door locks, like the ones you now find in hotel rooms, have different vulnerabilities. An attacker can find a flaw in the design that allows him to create a key card that opens every door. If he publishes his attack software, not just the attacker, but anyone can now open every lock. And if those locks are connected to the Internet, attackers could potentially open door locks remotely — ­they could open every door lock remotely at the same time. That’s a class break.”
  • “It’s how computer systems fail, but it’s not how we think about failures. We still think about automobile security in terms of individual car thieves manually stealing cars. We don’t think of hackers remotely taking control of cars over the Internet. Or, remotely disabling every car over the Internet. We think about voting fraud as unauthorized individuals trying to vote. We don’t think about a single person or organization remotely manipulating thousands of Internet-connected voting machines.”
  • “In a sense, class breaks are not a new concept in risk management. It’s the difference between home burglaries and fires, which happen occasionally to different houses in a neighborhood over the course of the year, and floods and earthquakes, which either happen to everyone in the neighborhood or no one. Insurance companies can handle both types of risk, but they are inherently different. The increasing computerization of everything is moving us from a burglary/fire risk model to a flood/earthquake model, which a given threat either affects everyone in town or doesn’t happen at all.”
  • “But there’s a key difference between floods/earthquakes and class breaks in computer systems: the former are random natural phenomena, while the latter is human-directed. Floods don’t change their behavior to maximize their damage based on the types of defenses we build. Attackers do that to computer systems. Attackers examine our systems, looking for class breaks. And once one of them finds one, they’ll exploit it again and again until the vulnerability is fixed.”
  • “As we move into the world of the Internet of Things, where computers permeate our lives at every level, class breaks will become increasingly important. The combination of automation and action at a distance will give attackers more power and leverage than they have ever had before. Security notions like the precautionary principle­ — where the potential of harm is so great that we err on the side of not deploying a new technology without proofs of security — will become more important in a world where an attacker can open all of the door locks or hack all of the power plants. It’s not an inherently less secure world, but it’s a differently secure world. It’s a world where driverless cars are much safer than people-driven cars, until suddenly they’re not. We need to build systems that assume the possibility of class breaks — and maintain security despite them.”

How to hide malware in a PNG

  • With that recent router hijacking malware, we saw the attackers were hiding an encrypted payload in the actual image served via the advertising network, and then decrypting the payload only if the victim met a set of criteria
  • The main advantage to this method is that it doesn’t leave a trail back to a Command and Control infrastructure. There is no central location or obvious sign that the computer has downloaded some malware, all it did was load an image from legitimate advertising agency (maybe even Google)
  • This post shows a crude method of hiding an executable file in a .png image and posting it to imgur
  • The image can then be downloaded by a powershell script, vb script, or a MS Office macro
  • PNG files are different than most other image formats, because they are lossless. It is basically a bitmap that is zlib compressed. Each pixel is represented by a set of 4 values, 0-255 for each of Red, Green, Blue, and Alpha (transparency).
  • This allows the image to represent the full spectrum of 24-bit colour (16,777,216 unique colours) and each pixel can be 256 different degrees of transparent
  • In the post’s example, a .jpg is encoded into the Alpha channel of an existing image from Wikipedia. This does not substantially change the size of the image, since the alpha channel was there for each pixel already, it might just compress slightly differently now
  • In this crude example, the data is base64 encoded, then written into the alpha channel. This makes the original picture look a bit staticy and washed out
  • If more work were put into it, it could be much harder to detect, and if the original image was carefully chosen, it could be almost impossible to detect
    The post demonstrates encoding calc.exe and running it on a remote system, in a way that will bypass most intrusion detection systems

Feedback:


Round Up:


Question? Comments? Contact us here!