Archive

Category Archives for "Security"

Some notes on memcached DDoS

I thought I'd write up some notes on the memcached DDoS. Specifically, I describe how many I found scanning the Internet with masscan, and how to use masscan as a killswitch to neuter the worst of the attacks.


Test your servers

I added code to my port scanner for this, then scanned the Internet:

masscan 0.0.0.0/0 -pU:11211 --banners | grep memcached

This example scans the entire Internet (/0). Replaced 0.0.0.0/0 with your address range (or ranges).

This produces output that looks like this:

Banner on port 11211/udp on 172.246.132.226: [memcached] uptime=230130 time=1520485357 version=1.4.13
Banner on port 11211/udp on 89.110.149.218: [memcached] uptime=3935192 time=1520485363 version=1.4.17
Banner on port 11211/udp on 172.246.132.226: [memcached] uptime=230130 time=1520485357 version=1.4.13
Banner on port 11211/udp on 84.200.45.2: [memcached] uptime=399858 time=1520485362 version=1.4.20
Banner on port 11211/udp on 5.1.66.2: [memcached] uptime=29429482 time=1520485363 version=1.4.20
Banner on port 11211/udp on 103.248.253.112: [memcached] uptime=2879363 time=1520485366 version=1.2.6
Banner on port 11211/udp on 193.240.236.171: [memcached] uptime=42083736 time=1520485365 version=1.4.13

The "banners" check filters out Continue reading

Before Commenting on Someone Mentioning RFC1925 ;)

Some of my readers got annoyed when I mentioned Google’s BeyondCorp and RFC 1925 in the same sentence (to be perfectly clear, I had Rule#11 in mind). I totally understand that sentiment – reading the reactions from industry press it seems to be the best thing that happened to Enterprise IT in decades.

Let me explain in simple terms why I think it’s not such a big deal and definitely not something new, let alone revolutionary.

Read more ...

Routing Security BoF – APRICOT 2018

On Sunday, 25 February, the first day of APRICOT 2018, a “Routing Security BoF” (birds of a feather: An informal discussion group) was organized to address the ever-growing routing related incidents happening on daily basis. We have discussed routing security in general within the Asia Pacific region but there was a need to have a platform for open and candid discussion among the network operator community to find a possible way forward, where operators can share their approach in securing their own infrastructure and keeping the internet routing table clean as well.

A quick introduction was provided by the moderator (Aftab Siddiqui) on why it is important to have this BoF. Here are the introductory slides:

The first technical community presenter was Yoshinobu Matsuzaki (Maz) from Internet Initiative Japan (IIJ), the first ISP in Japan started in 1992. IIJ is one of the few ISPs in the region implementing prefix filtering, source address validation for their end customers, and making sure that all their routing information is reflecting the current status in the peeringdb for AS2497. IIJ was the first Asia Pacific ISP to join MANRS (Mutually Agreed Norms for Routing Security), a global initiative, supported by the Continue reading

Routing Security is a Serious Problem – and MANRS Can Help. A Report from APRICOT 2018.

Last week, at APRICOT 2018 in Kathmandu, Nepal, there were a lot of talks and discussions focused on routing security and the Mutually Agreed Norms for Routing Security (MANRS).

First, there was a Routing Security BoF, attended by about 150 people, where we talked about what it takes to implement routing security practices, how CDNs and other players can help, and why it is so difficult to make progress in this area. The BoF included an interactive poll at the end, and it showed some interesting results:

  • Participants almost unanimously see lack of routing security as a serious problem.
  • Slow progress in this area is largely seen as due to a lack of incentives
  • Participants see community initiatives (like MANRS) as the main driving forces for improvement, followed by CDNs and cloud providers. They doubt that governments or end-customers can effectively drive change.

My colleague Aftab Siddiqui is writing a separate blog post just about that BoF, so watch the blog in the next day or two.

Later, in the security track of the main APRICOT programme, Andrei Robachevsky, ISOC’s Technology Programme Manager, presented statistics on routing incidents and suggested a way forward based on the MANRS approach. In his Continue reading

Memcached DDoS – There’s Still Time to Save Your Mind

In case you haven’t heard, there’s a new vector for Distributed Denial of Service (DDoS) attacks out there right now and it’s pretty massive. The first mention I saw this week was from Cloudflare, where they details that they were seeing a huge influx of traffic from UDP port 11211. That’s the port used by memcached, a database caching system.

Surprisingly, or not, there were thousands of companies that had left UDP/11211 open to the entire Internet. And, by design, memcached responds to anyone that queries that port. Also, carefully crafted packets can be amplified to have massive responses. In Cloudflare’s testing they were able to send a 15 byte packet and get a 134KB response. Given that this protocol is UDP and capable of responding to forged packets in such a way as to make life miserable for Cloudflare and, now, Github, which got blasted with the largest DDoS attack on record.

How can you fix this problem in your network? There are many steps you can take, whether you are a system admin or a network admin:

  • Go to Shodan and see if you’re affected. Just plug in your company’s IP address ranges and have it Continue reading

AskRob: Does Tor let government peek at vuln info?

On Twitter, somebody asked this question:



The question is about a blog post that claims Tor privately tips off the government about vulnerabilities, using as proof a "vulnerability" from October 2007 that wasn't made public until 2011.

The tl;dr is that it's bunk. There was no vulnerability, it was a feature request. The details were already public. There was no spy agency involved, but the agency that does Voice of America, and which tries to protect activists under foreign repressive regimes.

Discussion

The issue is that Tor traffic looks like Tor traffic, making it easy to block/censor, or worse, identify users. Over the years, Tor has added features to make it look more and more like normal traffic, like the encrypted traffic used by Facebook, Google, and Apple. Tors improves this bit-by-bit over time, but short of actually piggybacking on website traffic, it will always leave some telltale signature.

An example showing how we can distinguish Tor traffic is the packet below, from the latest version of the Tor server:


Had this been Google or Facebook, the names would be something like "www.google.com" or "facebook.com". Continue reading

A Secure Supply Chain for Kubernetes

The beta release of the Docker Enterprise Edition (Docker EE) container platform last month integrates Kubernetes orchestration, running alongside Swarm, to provide a single container platform that supports both legacy and new applications running on-premises or in the cloud. For organizations that are exploring Kubernetes or deploying it in production, Docker EE offers integrated security for the entire lifecycle of a containerized application, providing an additional layer of security before the workload is deployed by Kubernetes and continuing to secure the application while it is running.

Mike Coleman previously discussed access controls for Kubernetes. This week we’ll begin discussing how Docker EE secures the Kubernetes supply chain.

What is a Software Supply Chain?

When you purchase something from a retail store, there is an entire supply chain that gets the product from raw materials to the manufacturer to you. Similarly, there is a software supply chain that takes an application from code on a developer’s laptop to production.

Every company’s software supply chain may be slightly different; some outsource software development, some have adopted Continuous Integration and Continuous Delivery processes, and some deploy production applications across multiple clouds, some on-premises. Regardless of what the software supply chain consists of, Continue reading

Memcrashed – Major amplification attacks from UDP port 11211

Memcrashed - Major amplification attacks from UDP port 11211

Memcrashed - Major amplification attacks from UDP port 11211CC BY-SA 2.0 image by David Trawin

Over last couple of days we've seen a big increase in an obscure amplification attack vector - using the memcached protocol, coming from UDP port 11211.

In the past, we have talked a lot about amplification attacks happening on the internet. Our most recent two blog posts on this subject were:

The general idea behind all amplification attacks is the same. An IP-spoofing capable attacker sends forged requests to a vulnerable UDP server. The UDP server, not knowing the request is forged, politely prepares the response. The problem happens when thousands of responses are delivered to an unsuspecting target host, overwhelming its resources - most typically the network itself.

Memcrashed - Major amplification attacks from UDP port 11211

Amplification attacks are effective, because often the response packets are much larger than the request packets. A carefully prepared technique allows an attacker with limited IP spoofing capacity (such as 1Gbps) to launch very large attacks (reaching 100s Gbps) "amplifying" the attacker's bandwidth.

Memcrashed

Obscure amplification attacks happen all the time. We often see "chargen" or "call Continue reading

Using Cloudflare Workers to identify pwned passwords

Using Cloudflare Workers to identify pwned passwords

Last week Troy Hunt launched his Pwned Password v2 service which has an API handled and cached by Cloudflare using a clever anonymity scheme.

The following simple code can check if a password exists in Troy's database without sending the password to Troy. The details of how it works are found in the blog post above.

use strict;
use warnings;

use LWP::Simple qw/$ua get/;
$ua->agent('Cloudflare Test/0.1');
use Digest::SHA1 qw/sha1_hex/;

uc(sha1_hex($ARGV[0]))=~/^(.{5})(.+)/;
print get("https://api.pwnedpasswords.com/range/$1")=~/$2/?'Pwned':'Ok', "\n";

It's just as easy to implement the same check in other languages, such as JavaScript, which made me realize that I could incorporate the check into a Cloudflare Worker. With a little help from people who know JavaScript far better than me, I wrote the following Worker:

addEventListener('fetch', event => {
  event.respondWith(fetchAndCheckPassword(event.request))
})

async function fetchAndCheckPassword(req) {
  if (req.method == "POST") {
    try {
      const post = await req.formData()
      const pwd = post.get('password')
      const enc = new TextEncoder("utf-8").encode(pwd)

      let hash = await crypto.subtle.digest("SHA-1", enc)
      let hashStr = hex(hash).toUpperCase()
  
      const prefix = hashStr.substring(0, 5)
      const suffix = hashStr.substring(5)

      const pwndpwds = await fetch('https://api.pwnedpasswords.com/range/' + prefix)
      const t =  Continue reading