The market capitalization of the Bitcoin ecosystem crossed 1 billion US dollars recently. As the value of the each Bitcoin nears 100 US dollars, many have begun to take notice.

One likely source of this sudden interest is the Cypriot banking crisis. As depositors scramble to hedge their investments, the steadily growing notoriety of bitcoin raises some interesting opportunities. The two most alluring aspects that make the Bitcoin economy unique are the concept of mining and, interestingly enough, the automatic limits on mining.

Unlike other forms of currency, bitcoin users can create new money. By solving complex math problems users, or miners as they are often called, create new bitcoins where there used to be none. This operation is not strictly free “as in beer”. Miners need to invest time, electricity, and equipment into the endeavor. Profit is also not guaranteed. The nature of the math problems being solved mean that a single miner may never create new bitcoins on their own.

This self-limiting aspect of Bitcoin creates a fascinating set of contradictions. First there is a hard limit. There will never be more than 21 million bitcoins in circulation. It is important to note that each Bitcoin can be divided almost ad-infinitum. Some software only supports fractional bitcoins to 8 decimal places, but there is no hard limit in the Bitcoin system itself. Once all bitcoins have been mined it is expected that the value will increase as smaller and smaller fractions are transacted.

Read the rest of this entry »

Currently, we have been seeing an uptick in the number of denial-of-service attacks using DNS reflection or amplification. There are many variants, but the general outline of the attack is the same:

1. An attacker creates a DNS query with a fake source IP address – that of the intended victim. (Consider this as being analogous to a fake return-to-sender address.)
2. The query is sent to a DNS server that accepts queries from external addresses (i.e., those from a different ISP/network than its own). In addition, the query is crafted to generate the largest reply possible. Frequently, DNSSEC is used, as returns using it  tend to be much larger than other DNS replies.
3. The intended victim is flooded with packets. These can either be replies from the DNS server, or error messages sent along the way which are sent back to the “sender.”
4. Using DNS reflection, it is possible to use a relatively small number of hosts (often compromised) to generate huge volumes of traffic aimed at victims. Often, the abused DNS servers don’t even know they are involved in an ongoing attack.
5. This type of attack is very hard to trace as the source is well masked and you need lots of cooperation from the DNS server operators as well as their network service providers to trace attack to a source.

Both network operators and the administrators of DNS servers can help mitigate these attacks.

Network Operators

It is estimated that 14.1% of netblocks, which total 16.8% of all IP addresses, can be spoofed. That may sound small, but the Internet is a big place. An attack using DNS reflection can cause a large amount of damage, even if much less than 1% of IP addresses are used.

Ingress filtering applied at the router or firewall is one way to prevent networks from being a source of this type of attack. It prevents packets from transiting the router if the source address of the packet does not belong on the interface on which the packet was received. By analogy, this would be like a post office rejecting outgoing mail that had return addresses from out of town.

This doesn’t stop spoofing attacks from machines on the same network, it does prevent machines from initiating spoofing-based attacks against outside networks. One of the best resources here is BCP-38, which describes in detail how to implement this type of filtering.

Read the rest of this entry »

Earlier, we talked about how ordinary users can use NFC securely. However, truly widespread adaptation of NFC is only going to happen if businesses adopt it for their own use. How can businesses safely use NFC for their own purposes?

For one of the most popular uses of NFC – mobile payments – businesses really aren’t in a position to use their own solution; what’s more likely is that businesses will adapt some sort of existing mobile payment system. Both credit card and mobile providers are trying to enter this space, but both groups will support NFC. In such a situation, what businesses can do is ensure that their solution is from a reputable vendor, and to keep themselves informed about any potential security loopholes in the solution they adopt.

However, payment systems are far from the only use of NFC in businesses. At the simple end, it can be something like letting people visit a website without typing a URL or scanning a QR code. However, as the standard develops, something like this becomes possible: a shop wants to offer free WiFi to its customers, but doesn’t necessarily want to expose it to the entire world. What they can do is put an NFC tag at the entrance that customers entering can swipe to set their phone’s WiFi settings.

NFC tags could also be used to automatically update someone’s social media – it’s easy to imagine a tag for Twitter, another for Facebook, and another for Foursquare (just to cite three popular social networks that one might be interested in using on the go). All of this can be done either now, or are quite likely to become possible in the near future.

Read the rest of this entry »

Recently, I spoke at the hashdays security conference in Switzerland to talk about the security of Near field communication (NFC) – specifically, how people and businesses can use it securely.

While NFC is not quite yet seeing widespread usage, early adopters – like many readers of this blog – are already using it in their lives. Some mobile manufacturers are touting the addition of NFC in their mobile devices. For my talk, I discussed what aspects of NFC usage can be considered secure, and what can be considered just “convenient”; what businesses can do to keep their customers safe; and what features of NFC should designers implement or completely avoid.

For home users, though, the most important part of my talk was what they can do to keep themselves safe. It’s never too early to pick up good NFC habits. What are these habits that can keep you secure? They are:

• Lock your mobile device. In general, devices have to be turned on or unlocked before they can read any NFC tags. A simple screen lock – even without any password being used – can protect users against these threats.
• For passive tags, use an RFID/NFC-blocking device (such as a wallet). Passive tags will emit fixed information in the presence of a NFC field, which means that there is a slight privacy risk carrying around these devices – if a blocking device is not used. (Anti-static bags can also block RFID devices.) This isn’t the case for mobile devices as their NFC reader automatically turns off once devices are locked, so this precaution is not necessary.
• Use an NFC reader app on your mobile device. By default, most mobile devices will simply open a URL if one is detected on an NFC tag. If you wouldn’t lick a tag, you shouldn’t open it blindly – instead, use an app like NFC TagInfo or NFC TagInfo by NXP to read the tag first. The apps will be able to tell you what information is on the tag – allowing you to make an informed decision if you want to scan it or not.

We’ve seen no indication that NFC has been used in the wild by attackers, but it’s never too early to develop good habits when using this emerging – and promising – technology.

Earlier this week the folks over at OpenDNS announced a preview release of their new tool DNSCrypt. This is touted as a huge step forward for privacy and security across the Internet. The premise is simple, encrypt all DNS traffic between the user and their recursive resolver. It’s a nice idea and all, but I think they missed the mark.

According to OpenDNS, the code is actually the first real-world implementation of the DNSCurve scheme. The stated goals are to provide privacy and authenticity to the entire DNS transaction. Unfortunately, you can’t just wrap an existing protocol with crypto and expect to be more secure than you were before. In this case you need to look at the entire ecosystem. Sure your DNS query will be private, invisible to other users or attackers on the same network. The problem comes a few milliseconds after you get the result. The privacy you gained by encrypting your DNS traffic evaporates when the browser makes its request of the server. An attacker in a position to see your DNS traffic is likely to have the same visibility into other forms of traffic.

If you are more concerned with authenticity of the data than privacy, there are better ways to get that as well. DNSSEC is ready to answer your call. A major advantage of DNSSEC is that in the case of some TLDs it can authenticate the result all the way to the root (This list includes an indication of which TLDs are signed). According to the DNSCrypt FAQ at OpenDNS, DNSSEC and DNSCrypt function perfectly in concert: “They aren’t conflicting in any way.”

Read the rest of this entry »