Playing NSA -- tapping internet communications
(originally posted 12.09.2017 on Google+)
In the wake of the Snowden reporting, a lot is written about intelligence agencies tapping internet backbone links. But what does this mean exactly? Which data can be collected? What's the effect of encryption? And what about infamous metadata? The problem so far is, when at all the media reports about the technical details, it's almost always wrong or misleading. I hope I can do better with this post. So I play NSA and show you the reality with concrete examples.
I'll send emails from my professional email account to my private gmail account (I actually sent the emails, but will X-out the local parts of the email addresses here; the ones who extract my email addresses from the hex dump really deserve it). The emails will be sent on three different ways:
1. Traditionally unencrypted email, without transport layer encryption (STARTTLS)
2. PGP-encrypted email, but sent without STARTTLS
3. Traditionally unencrypted email, but sent with STARTTLS
Concurrently I will tap the traffic with tcpdump (tcpdump is the traditional Unix tool to tap network traffic; btw the infamous NSA XkeyScore tool is basically nothing more than an enhanced tcpdump to ease the work of analysts analysing the network traffic):
tcpdump -n -i eth0 port 25 -w email.pcap
Then I will analyze the tapped traffic with:
tcpdump -X -n -r email.pcap
You can find the complete outputs of the tcpdumps at the end of this post. When you look at it, you'll see that tcpdump outputs are something that needs getting used to -- so you'll likely understand one reason why the NSA invented the cozy tool XKeyScore …
1. Traditionally unencrypted email, without transport layer encryption (STARTTLS)
Let's start with this one. The "S" in "SMTP" stands for "simple", and traditional SMTP really is simple, so I can send an email from a command line -- and this makes it easy to explain some important points:
$ telnet gmail-smtp-in.l.google.com. 25
Trying 74.125.133.27...
Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP v139si8345872wmv.47 - gsmtp
I telneted to the SMTP port of a gmail email server, it responds with a 220 line, everything OK.
EHLO me
250-mx.google.com at your service, [212.89.128.XX]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
My next command was "EHLO me". Some side remarks here (not important for the key goal of this post, but maybe interesting): 1. "EHLO" stands for "Extended HELO". "HELO" was the traditional way of starting an SMTP session, but was later extended so client and server could agree on advanced options, like the later discussed STARTTLS. As long as I don't acknowledge one or more of the offered options, the SMTP session will continue the traditional way. 2. Usually, the parameter after "EHLO" should be the fully qualified domain name of the sending host, but hardly any email server checks whether it is valid. I always used to use "HELO me" or "EHLO me" when I troubleshooted email from the command line, so I do it here too.
MAIL FROM: <XXXX@infos.de>
250 2.1.0 OK v139si8345872wmv.47 - gsmtp
I didn't acknowledge any of the offered options and just continue with the "MAIL FROM:" SMTP command. Gmail OK's it.
RCPT TO: <XXXXXX@gmail.com>
250 2.1.5 OK v139si8345872wmv.47 - gsmtp
Here I said with "RCPT TO:" to whom the email should be sent.
DATA
354 Go ahead v139si8345872wmv.47 - gsmtp
From: <XXXX@infos.de>
To: <XXXXXX@gmail.com>
Subject: tap me
Date: Tue, 12 Sep 2017 08:48:13 +0200 (CEST)
I'm just testing.
.
250 2.0.0 OK 1505198973 v139si8345872wmv.47 - gsmtp
The last command was "DATA". After "DATA", the complete email is transmitted. You should know that an email consists of headers (you can call it "metadata" as well) and the content, and the first empty line is the delimiter. "From:" and "To:" are email headers (they are often the same as the SMTP headers "MAIL FROM:" and "RCPT TO:", but do not need to be, eg if the email is sent to several addresses, or copied to others with "CC" or "BCC"), but there are others like "Date:" and "Subject:", and much more are possible. Some may find it strange that "Subject:" is a header field and not part of the content (reportedly there are users who write a complete email in the Subject-line), but this is how email was invented ages ago. OK, the email was sent now. Now let's look what the network tap reveals (spoiler: everything). You can find the complete output in Appendix 1, in the following I'll only explain the interesting parts:
08:48:52.729711 IP 10.32.1.64.56942 > 74.125.133.27.25: Flags [S], seq 1241588711, win 29200, options [mss 1460,sackOK,TS val 639877 ecr 0,nop,wscale 7], length 0
0x0000: 4510 003c e062 4000 4006 7f51 0a20 0140 E..<.b@.@..Q...@
0x0010: 4a7d 851b de6e 0019 4a01 23e7 0000 0000 J}...n..J.#.....
0x0020: a002 7210 db26 0000 0204 05b4 0402 080a ..r..&..........
0x0030: 0009 c385 0000 0000 0103 0307 ............
This is the first, initial packet, the so called SYN packet. Please note that the length of the packet is 0, meaning there is no content, or payload. What you see in the lines 0x0000 to 0x0030 are the IP and TCP headers of the packet. The most important of them are written in readable form in the first line. You see my sending IP address 10.32.1.64 (please note that this is a private IP address, my workstation is behind a NAT gateway; if the email would have been taped at an internet backbone link, you would see here the official IP address of the NAT gateway; I didn't tap at the NAT gateway for legal reasons, and it makes absolutely no difference for my explanations) and the sending port 56942 (this is a more or less random number). Further you see the destination IP 74.125.133.27 (a Google Gmail server), and the destination port 25 (allocated for the SMTP service). The next 2 packets are the rest of the TCP 3-way handshake. Then comes the first data packet:
08:48:52.757667 IP 74.125.133.27.25 > 10.32.1.64.56942: Flags [P.], seq 1:54, ack 1, win 166, options [nop,nop,TS val 1134699112 ecr 639880], length 53: SMTP: 220 mx.google.com ESMTP v139si8345872wmv.47 - gsmtp
0x0000: 4500 0069 d99c 0000 2b06 dafa 4a7d 851b E..i....+...J}..
0x0010: 0a20 0140 0019 de6e 0b5e 8855 4a01 23e8 ...@...n.^.UJ.#.
0x0020: 8018 00a6 60c2 0000 0101 080a 43a2 2268 ....`.......C."h
0x0030: 0009 c388 3232 3020 6d78 2e67 6f6f 676c ....220.mx.googl
0x0040: 652e 636f 6d20 4553 4d54 5020 7631 3339 e.com.ESMTP.v139
0x0050: 7369 3833 3435 3837 3277 6d76 2e34 3720 si8345872wmv.47.
0x0060: 2d20 6773 6d74 700d 0a -.gsmtp..
You see now a length of 53 (Bytes). And then, after the IP and TCP headers, you see perfectly in cleartext the Google email servers banner string "220 mx.google.com ESMTP v139si8345872wmv.47 - gsmtp". And in the following packets, you see all the other things in cleartext too: The SMTP headers: MAIL FROM: <XXXX@infos.de> RCPT TO: <XXXXXX@gmail.com> The email headers: From: <XXXX@infos.de> To: <XXXXXX@gmail.com> Subject: tap me Date: Tue, 12 Sep 2017 08:48:13 +0200 (CEST) And the email content: I'm just testing.
Keine Kommentare:
Kommentar veröffentlichen