NETRESEC Network Security Blog - Tag : HTTPS


NetworkMiner 2.5 Released

NetworkMiner 2.5

I am happy to announce the release of NetworkMiner 2.5 today! This new version includes new features like JA3 and parsers for the HTTP/2 and DoH protocols. We have also added support for a few older protocols that are still widely used, such as Kerberos and the CIFS browser protocol. Additionally, NetworkMiner can now parse PCAP files up to twice as fast as before!

Improving Passive TLS Analysis with JA3

Almost all web traffic is TLS encrypted nowadays, which prevents incident responders, analysts and investigators from inspecting otherwise unencrypted HTTP traffic for clues about malicious behavior or criminal intent. This requires analysts to use alternative approaches, such as looking at hostnames and X.509 certificates. This type of analysis is supported by NetworkMiner, since it parses Server Name Indication fields in client TLS handshakes and extracts X.509 certificates automatically when PCAP files are loaded.

In this release we’ve also added support for another passive TLS analysis technique called JA3, which is a method for fingerprinting TLS client implementations.

NetworkMiner leverages the JA3 fingerprint database from Trisul Network Analytics in order to match observed JA3 hashes to hashes of known malware and “normal” applications. This is what it looks like when the capture file “snort.log.1428364808”, from the FIRST 2015 “Hands-on Network Forensics” training (available here), has been loaded into NetworkMiner 2.5:

JA3 fingerprint of a Skype client

Image: JA3 fingerprint of a Skype client in NetworkMiner 2.5

The JA3 hash is also available in the “Parameters” tab, which is useful in order to find out what hosts that particular TLS implementation was reaching out to.

Filtering on JA3 hash 06207a1730b5deeb207b0556e102ded2 in NetworkMiner 2.5

Image: Filtering on JA3 hash 06207a1730b5deeb207b0556e102ded2

HTTP/2 and DoH Support

Passive analysis of TLS traffic, such as HTTPS, often doesn’t give sufficient visibility. Many organizations therefore use TLS proxies in order to decrypt the traffic going in and out from their networks. However, more than half of all HTTPS traffic is actually http2 (RFC 7540) nowadays. This has previously been an issue for users who wanted to analyze decrypted http2 traffic from their TLS intercepting proxies with NetworkMiner. We’re happy to announce that NetworkMiner now can parse http2 traffic, that has been decrypted by a TLS proxy, and extract files from the http2 transfers.

NetworkMiner 2.5 also supports the DNS over HTTPS (DoH) protocol (RFC 8484), which is a technique for sending DNS queries as http2 POST requests and parsing the returned data as DNS responses. We’ve incorporated the DoH data into NetworkMiner’s DNS tab, so that you can analyze it just like normal DNS traffic.

DoH traffic to mozilla.cloudflare-dns.com in NetworkMiner’s DNS tab

Image: DoH traffic to mozilla.cloudflare-dns.com in NetworkMiner’s DNS tab

Please note that NetworkMiner 2.5 does not perform TLS decryption. This means that NetworkMiner can only parse the contents of a TLS stream if it has been decrypted by a TLS proxy, such as PolarProxy.

Extracting Kerberos Hashes from PCAP

NetworkMiner’s support for the Kerberos protocol allows you to passively track which user accounts that are authenticating to what services, simply by monitoring network traffic. This is a feature is essential in order to track credential theft and lateral movement by adversaries inside your networks. After implementing kerberos username and hash extraction we realized that this feature could also be valuable for penetration testers. We therefore decided to present extracted Kerberos credentials in a format that is compatible with tools like hashcat and John the Ripper.

Kerberos krb5pa, krb5asrep and krb5tgs credentials extracted from the Wireshark sample capture file

Image: Kerberos krb5pa, krb5asrep and krb5tgs credentials extracted from the Wireshark sample capture file Krb-contrained-delegation.cap

For more information about Kerberos hashes, please see our Extracting Kerberos Credentials from PCAP blog post.

Even more NetBIOS and CIFS Artifacts!

NetworkMiner is a popular tool for extracting files transferred over SMB and SMB2 from capture files. It can also extract a great deal of information about the communicating hosts from protocols like NetBIOS and SMB/CIFS, but earlier this year Chris Raiter notified us about an important piece of information that was missing in NetworkMiner: NetBIOS Name Service (NBNS) lookups and responses!

Detection and export of NBNS packets request on twitter

A couple of months later Dan Gunter sent us another great feature request for another protocol that runs on top of NetBIOS: the CIFS Browser Protocol (aka MS-BRWS).

We’re happy to announce that NBNS queries and responses are now shown in NetworkMiner’s Parameters tab, and details like hostnames, domain names, Windows versions and uptime us extracted from the MS-BRWS protocol. See the screenshots below, which were created by loading the capture file “case09.pcap” from Richard Bejtlich’s TCP/IP Weapons School 2.0 Sample Lab into NetworkMiner 2.5. Thanks for sharing Richard!

Hostname, domain and Windows version extracted from MS-BRWS traffic

Image: Hostname, domain and Windows version extracted from MS-BRWS traffic

NBNS queries and responses in NetworkMiner’s Parameters tab

Image: NBNS queries and responses in NetworkMiner’s Parameters tab

Mono 5 Required for Linux and MacOS

Linux and MacOS users, who run NetworkMiner with help of Mono, will need to ensure they have Mono 5 (or later) installed in order to run NetworkMiner 2.5. We recommend using at least Mono 5.18.

Instructions for installing NetworkMiner on Linux can be found in our blog post ”HowTo install NetworkMiner in Ubuntu Fedora and Arch Linux”.

MacOS users can refer to our “Running NetworkMiner on Mac OS X” blog post.

Users who are unable to install Mono 5 are recommended to use the old NetworkMiner 2.4 release, which can be downloaded here: https://www.netresec.com/?download=NetworkMiner_2-4

NetworkMiner Professional

Apart from the features mentioned so far, our commercial tool NetworkMiner Professional now comes with a few additional new features. One of these features is port independent identification of RDP traffic, so that mstshash credentials can be extracted from RDP sessions even if the service doesn’t run on port 3389. The OSINT lookup context menus in NetworkMiner Professional have also been enriched with the following online services:

Several new features have also been included in the command line tool NetworkMinerCLI, including:

  • Recursive loading of PCAP files with the "-R” switch.
  • Configurable export types (hosts, files, DNS etc) with the “-x” switch.
  • Relative paths in CSV, XML and JSON/CASE exports unless the “-- absolutePaths” switch is used.

Credits

I’d like to thank Dan Gunter, Chris RaiterChris Sistrunk and a few more (who I cannot mention here) for contributing with feature requests and bug reports that have helped improve NetworkMiner.

Upgrading to Version 2.5

Users who have purchased a license for NetworkMiner Professional 2.x can download a free update to version 2.5 from our customer portal, or use the “Help > Check for Updates” feature. Those who instead prefer to use the free and open source version can grab the latest version of NetworkMiner from the official NetworkMiner page.

Posted by Erik Hjelmvik on Thursday, 07 November 2019 11:45:00 (UTC/GMT)

Tags: #NetworkMiner #HTTP/2 #http2 #DoH #Kerberos #NetBIOS #PCAP #hashcat #John #NetworkMinerCLI #OSINT

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=19B4a1a


Raspberry PI WiFi Access Point with TLS Inspection

This is a how-to guide for setting up a Raspberry Pi as a WiFi Access Point, which acts as a transparent TLS proxy and saves the decrypted traffic in PCAP files.

Raspberry Pi 4 Model B running PolarProxy
Image: Raspberry Pi 4 Model B running PolarProxy

Step 1: Install PolarProxy for Linux ARM

We will start with installing PolarProxy, which will be used for the TLS decryption and re-encryption. The steps are almost identical to those in the official PolarProxy installation guide, except here we will download the "linux-arm" build of PolarProxy instead of the x64 version.

sudo adduser --system --shell /bin/bash proxyuser
sudo mkdir /var/log/PolarProxy
sudo chown proxyuser:root /var/log/PolarProxy/
sudo chmod 0775 /var/log/PolarProxy/
sudo su - proxyuser
mkdir ~/PolarProxy
cd ~/PolarProxy/
curl https://www.netresec.com/?Download=PolarProxy_linux-arm | tar -xzvf -
exit
sudo cp /home/proxyuser/PolarProxy/PolarProxy.service /etc/systemd/system/PolarProxy.service
sudo systemctl enable PolarProxy.service
sudo systemctl start PolarProxy.service

Verify that the PolarProxy service is running as expected with these commands:

systemctl status PolarProxy.service
journalctl -t PolarProxy

Step 2: Set up your Pi as a WiFi AP

The Raspberry Pi Foundation have a great guide for "Setting up a Raspberry Pi as a Wireless Access Point". Follow the instructions in their guide for the NAT mode setup (first section), but replace the iptables config with this:

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A INPUT -i wlan0 -p tcp --dport 10443 -m state --state NEW -j ACCEPT
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to 10443
Then save the iptables rules with:
sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"
Finally, edit /etc/rc.local and add this iptables-restore command just above "exit 0" to install the rules on boot.
iptables-restore < /etc/iptables.ipv4.nat

Step 3: Configure the Clients

The final step is to connect the clients (phones, tablets or computers) to the Raspberry Pi WiFi Access Point and install the root CA from PolarProxy.

Follow the instructions for "Trusting the PolarProxy root CA" in the official PolarProxy setup guide to install the public certificate from the TLS proxy in your clients. The certificate can be downloaded from the Raspberry Pi by browsing to http://192.168.4.1:10080/polarproxy.cer.

PCAP PCAP PCAP

Your Raspberry Pi WiFi AP will now intercept all HTTPS traffic going to tcp/443 and save the decrypted traffic in PCAP files, one per hour. The PCAP files with decrypted TLS traffic can be found in the /var/log/PolarProxy/ directory of your Raspberry Pi.

pi@raspberrypi:/var/log/PolarProxy $ ls *.pcap
proxy-190925-075704.pcap proxy-190925-152902.pcap
proxy-190925-085704.pcap proxy-190925-162902.pcap
proxy-190925-095704.pcap proxy-190925-172902.pcap
proxy-190925-105704.pcap proxy-190925-182902.pcap
proxy-190925-115704.pcap proxy-190926-062902.pcap
proxy-190925-125704.pcap proxy-190926-072902.pcap
proxy-190925-132704.pcap proxy-190926-082902.pcap
proxy-190925-132902.pcap proxy-190926-092902.pcap
proxy-190925-142902.pcap proxy-190926-102902.pcap

HTTP/2 traffic to Facebook opened in Wireshark
Image: Decrypted HTTP/2 traffic to Facebook opened in Wireshark

Posted by Erik Hjelmvik on Thursday, 26 September 2019 11:37:00 (UTC/GMT)

Tags: #PolarProxy #PCAP #TLS #SSL #HTTPS #Wireshark #http2

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=199dc9a


Packet Injection Attacks in the Wild

I have previously blogged about packet injection attacks, such as the Chinese DDoS of GitHub and Covert Man-on-the-Side Attacks. However, this time I've decided to share some intelligence on real-world packet injection attacks that have been running for several months and that are still active today.


Packet Injection by Network Operators

Gabi Nakibly, Jaime Schcolnik and Yossi Rubin recently released a very interesting research paper titled “Website-Targeted False Content Injection by Network Operators”, where they analyzed packet injection attacks in the wild. Here's a snippet from the paper's abstract:

It is known that some network operators inject false content into users’ network traffic. Yet all previous works that investigate this practice focus on edge ISPs (Internet Service Providers), namely, those that provide Internet access to end users. Edge ISPs that inject false content affect their customers only. However, in this work we show that not only edge ISPs may inject false content, but also core network operators. These operators can potentially alter the traffic of all Internet users who visit predetermined websites.

The researchers analyzed 1.4 petabits of HTTP traffic, captured at four different locations; three universities and one corporation. Some of their findings have been made available as anonymized PCAP files here:
http://www.cs.technion.ac.il/~gnakibly/TCPInjections/samples.zip

We have attempted to recreate these packet injections by visiting the same URLs again. Unfortunately most of our attempts didn't generate any injected responses, but we did manage to trigger injections for two of the groups listed by Nakibly et al. (“hao” and “GPWA”).


Redirect Race between hao.360.cn and hao123.com

We managed to get very reliable packet injections when visiting the website www.02995.com. We have decided to share one such PCAP file containing a packet injection attack here:
https://www.netresec.com/files/hao123-com_packet-injection.pcap

This is what it looks like when loading that PCAP file into CapLoader and doing a “Flow Transcript” on the first TCP session:

CapLoader Flow Transcript of race between hao.360.cn and hao123.com
Image: CapLoader Flow Transcript (looks a bit like Wireshark's Follow-TCP-Stream)

We can see in the screenshot above that the client requests http://www.02995.com/ and receives two different responses with the same sequence number (3820080905):

  • The first response is a “302 Found”, forwarding the client to:
    http://www.hao123.com/?tn=93803173_s_hao_pg
  • The second response is a “302 Moved Temporarily”, that attempts a redirect to:
    http://hao.360.cn/?src=lm&ls=n4a2f6f3a91

Judging from the IP Time-To-Live (TTL) values we assume that the first response (hao123.com) was an injected packet, while the second response (hao.360.cn) was coming from the real webserver for www.02995.com.

If you have an eye for details, then you might notice that the injected packet doesn't use the standard CR-LF (0x0d 0x0a) line breaks in the HTTP response. The injected packet only uses LF (0x0a) as line feed in the HTTP header.

Since the injected response arrived before the real response the client followed the injected redirect to www.hao123.com. This is what the browser showed after trying to load www.02995.com:

Browser showing www.hao123.com when trying to visit www.02995.com

SSL encryption is an effective protection against packet injection attacks. So if the user instead enters https://www.02995.com then the browser follows the real redirect to hao.360.cn

Browser showing hao.360.cn when using SSL to visit www.02995.com


id1.cn redirected to batit.aliyun.com

Prior to the release of Gabi's packet injection paper, the only publicly available PCAP file showing a real-world packet injection was this one:
https://github.com/fox-it/quantuminsert/blob/master/presentations/brocon2015/pcaps/id1.cn-inject.pcap

That PCAP file was released after Yun Zheng Hu (of Fox-IT) gave a presentation titled “Detecting Quantum Insert” at BroCon 2015. A video recording of Yun Zheng's talk is available online, including a live demo of the packet injection.

We have managed to re-trigger this packet injection attack as well, simply by visiting http://id1.cn. Doing so triggers two injected HTTP responses that attempts to do a redirect to http://batit.aliyun.com/alww.html. The target page of the injected responses has a message from the Alibaba Group (aliyun.com) saying that the page has been blocked.

Website blocked message from Alibaba Group

We have decided to also share a PCAP file containing a packet injection attack for id1.cn here:
https://www.netresec.com/files/id1-cn_packet-injection.pcap

This is what it looks like when that PCAP file is loaded into NetworkMiner Professional, and the Browsers tab is opened in order to analyze the various HTTP redirections:

Browsers tab in NeworkMiner Professional 2.0
Image: Browsers tab in NetworkMiner Professional 2.0

Here's a short recap of what is happening in our shared PCAP file for id1.cn:

  • Frame 13 : http://id1.cn is opened
  • Frame 18 : Real server responds with an HTML refresh leading to http://id1.cn/rd.s/Btc5n4unOP4UrIfE?url=http://id1.cn/
  • Frame 20 : The client also receives two injected packets trying to do a “403 Forbidden” that redirects to http://batit.aliyun.com/alww.html. However, these injected packets arrived too late.
  • Frame 24 : The client proceeds by loading http://id1.cn/rd.s/Btc5n4unOP4UrIfE?url=http://id1.cn/
  • Frame 25 : Two new injected responses are sent, this time successfully redirecting the client to the Alibaba page.
  • Frame 28 : The real response arrives too late.
  • Frame 43 : The client opens the Alibaba page with message about the site being blocked


Protecting against Packet Injection Attacks

The best way to protect against TCP packet injection attacks is to use SSL encryption. Relying on HTTP websites to do a redirect to an HTTPS url isn't enough, since that redirect could be targeted by packet injection. So make sure to actually type “https://” (or use a browser plug-in) in order to avoid being affected by injected TCP packets.


Referenced Capture Files

The following PCAP files have been referenced in this blog post:

For more PCAP files, please visit our list of publicly available PCAP files here: https://www.netresec.com/?page=PcapFiles

Posted by Erik Hjelmvik on Tuesday, 01 March 2016 13:37:00 (UTC/GMT)

Tags: #NetworkMiner #HTTP #browser #CapLoader #MOTS #HTTPS #TCP #PCAP

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=163e02b


Detecting TOR Communication in Network Traffic

The anonymity network Tor is often misused by hackers and criminals in order to remotely control hacked computers. In this blog post we explain why Tor is so well suited for such malicious purposes, but also how incident responders can detect Tor traffic in their networks.

Yellow onions with cross section. Photo taken by Andrew c

The privacy network Tor (originally short for The Onion Router) is often used by activists and whistleblowers, who wish to preserve their anonymity online. Tor is also used by citizens of countries with censored Internet (like in China, Saudi Arabia and Belarus), in order to evade the online censorship and surveillance systems. Authorities in repressive regimes are therefore actively trying to detect and block Tor traffic, which makes research on Tor protocol detection a sensitive subject.

Tor is, however, not only used for good; a great deal of the traffic in the Tor networks is in fact port scans, hacking attempts, exfiltration of stolen data and other forms of online criminality. Additionally, in December last year researchers at Rapid7 revealed a botnet called “SkyNet” that used Tor for its Command-and-Control (C2) communication. Here is what they wrote about the choice of running the C2 over Tor:

"Common botnets generally host their Command & Control (C&C) infrastructure on hacked, bought or rented servers, possibly registering domains to resolve the IP addresses of their servers. This approach exposes the botnet from being taken down or hijacked. The security industry generally will try to take the C&C servers offline and/or takeover the associated domains
[...]
What the Skynet botnet creator realized, is that he could build a much stronger infrastructure at no cost just by utilizing Tor as the internal communication protocol, and by using the Hidden Services functionality that Tor provides."


Tor disguised as HTTPS

Tor doesn't just provide encryption, it is also designed to look like normal HTTPS traffic. This makes Tor channels blend in quite well with normal web surfing traffic, which makes Tor communication difficult to identify even for experienced incident responders. As an example, here is how tshark interprets a Tor session to port TCP 443:

$ tshark -nr tbot_2E1814CCCF0.218EB916.pcap | head
1 0.000000 172.16.253.130 -> 86.59.21.38 TCP 62 1565 > 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1
2 0.126186 86.59.21.38 -> 172.16.253.130 TCP 60 443 > 1565 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460
3 0.126212 172.16.253.130 -> 86.59.21.38 TCP 54 1565 > 443 [ACK] Seq=1 Ack=1 Win=64240 Len=0
4 0.127964 172.16.253.130 -> 86.59.21.38 SSL 256 Client Hello
5 0.128304 86.59.21.38 -> 172.16.253.130 TCP 60 443 > 1565 [ACK] Seq=1 Ack=203 Win=64240 Len=0
6 0.253035 86.59.21.38 -> 172.16.253.130 TLSv1 990 Server Hello, Certificate, Server Key Exchange, Server Hello Done
7 0.259231 172.16.253.130 -> 86.59.21.38 TLSv1 252 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
8 0.259408 86.59.21.38 -> 172.16.253.130 TCP 60 443 > 1565 [ACK] Seq=937 Ack=401 Win=64240 Len=0
9 0.379712 86.59.21.38 -> 172.16.253.130 TLSv1 113 Change Cipher Spec, Encrypted Handshake Message
10 0.380009 172.16.253.130 -> 86.59.21.38 TLSv1 251 Encrypted Handshake Message

A Tor session to TCP port 443, decoded by tshark as if it was HTTPS

The thsark output above looks no different from when a real HTTPS session is being analyzed. So in order to detect Tor traffic one will need to apply some sort of traffic classification or application identification. However, most implementations for protocol identification rely on either port number inspection or protocol specification validation. But Tor often communicate over TCP 443 and it also follows the TLS protocol spec (RFC 2246), because of this most products for intrusion detection and deep packet inspection actually fail at identifying Tor traffic. A successful method for detecting Tor traffic is to instead utilize statistical analysis of the communication protocol in order to tell different SSL implementations apart. One of the very few tools that has support for protocol identification via statistical analysis is CapLoader.

CapLoader provides the ability to differentiate between different types of SSL traffic without relying on port numbers. This means that Tor sessions can easily be identified in a network full of HTTPS traffic.


Analyzing the tbot PCAPs from Contagio

@snowfl0w provides some nice analysis of the SkyNet botnet (a.k.a. Trojan.Tbot) at the Contagio malware dump, where she also provides PCAP files with the network traffic generated by the botnet.

The following six PCAP files are provided via Contagio:

  1. tbot_191B26BAFDF58397088C88A1B3BAC5A6.pcap (7.55 MB)
  2. tbot_23AAB9C1C462F3FDFDDD98181E963230.pcap (3.24 MB)
  3. tbot_2E1814CCCF0C3BB2CC32E0A0671C0891.pcap (4.08 MB)
  4. tbot_5375FB5E867680FFB8E72D29DB9ABBD5.pcap (5.19 MB)
  5. tbot_A0552D1BC1A4897141CFA56F75C04857.pcap (3.97 MB) [only outgoing packets]
  6. tbot_FC7C3E087789824F34A9309DA2388CE5.pcap (7.43 MB)

Unfortunately the file “tbot_A055[...]” only contains outgoing network traffic. This was likely caused by an incorrect sniffer setup, such as a misconfigured switch monitor port (aka SPAN port) or failure to capture the traffic from both monitor ports on a non-aggregating network tap (we recommend using aggregation taps in order to avoid these types of problems, see our sniffing tutorial for more details). The analysis provided here is therefore based on the other five pcap files provided by Contagio.

Here is a timeline with relative timestamps (the frame timestamps in the provided PCAP files were way of anyway, we noticed an offset of over 2 months!):

  • 0 seconds : Victim boots up and requests an IP via DHCP
  • 5 seconds : Victim perform a DNS query for time.windows.com
  • 6 seconds : Victim gets time via NTP
    ---{malware most likely gets executed here somewhere}---
  • 22 seconds : Victim performs DNS query for checkip.dyndns.org
  • 22 seconds : Victim gets its external IP via an HTTP GET request to checkip.dyndns.org
  • 23 seconds : Victim connects to the Tor network, typically on port TCP 9001 or 443
    ---{lots of Tor traffic from here on}---

This is what it looks like when one of the tbot pcap files has been loaded into CapLoader with the “Identify protocols” feature activated:
CapLoader detecting Tor protocol
CapLoader with protocol detection in action - see “TOR” in the “Sub_Protocol” column

Notice how the flows to TCP ports 80, 9101 and 443 are classified as Tor? The statistical method for protocol detection in CapLoader is so effective that CapLoader actually ignores port numbers altogether when identifying the protocol. The speed with which CapLoader parses PCAP files also enables analysis of very large capture files. A simple way to detect Tor traffic in large volumes of network traffic is therefore to load a capture file into CapLoader (with “Identify protocols” activated), sort the flows on the “Sub_Protocol” column, and scroll down to the flows classified as Tor protocol.


Beware of more Tor backdoors

Most companies and organizations allow traffic on TCP 443 to pass through their firewalls without content inspection. The privacy provided by Tor additionally makes it easy for a botnet herder to control infected machines without risking his identity to be revealed. These two factors make Tor a perfect fit for hackers and online criminals who need to control infected machines remotely.

Here is what Claudio Guarnieri says about the future use of Tor for botnets in his Rapid7 blog post:

“The most important factor is certainly the adoption of Tor as the main communication channel and the use of Hidden Services for protecting the backend infrastructure. While it’s surprising that not more botnets adopt the same design, we can likely expect more to follow the lead in the future.”

Incident responders will therefore need to learn how to detect Tor traffic in their networks, not just in order to deal with insiders or rogue users, but also in order to counter malware using it as part of their command-and-control infrastructure. However, as I've shown in this blog post, telling Tor apart from normal SSL traffic is difficult. But making use of statistical protocol detection, such as the Port Independent Protocol Identification (PIPI) feature provided with CapLoader, is in fact an effective method to detect Tor traffic in your networks.

Posted by Erik Hjelmvik on Saturday, 06 April 2013 20:55:00 (UTC/GMT)

Tags: #CapLoader #TOR #Protocol Identification #SSL #TLS #HTTPS #PCAP #PIPI

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=13400BE


Webmail Information Leakage

Switching protocol from unencrypted HTTP to encrypted HTTPS is a good move in order to help the users of a website to protect their privacy online. Many webmail providers have therefore started rolling out their encrypted services during the past few years. Google announced their optional “always use https” setting back in 2008 and also provided some guidance as to why it was important to use HTTPS:

Https keeps your mail encrypted as it travels between your web browser and our servers, so someone sharing your favorite coffee shop's public wifi can't read it.

It took Microsoft Hotmail until November 2010 to announce their optional support for HTTPS encryption, which users could activate by visiting https://account.live.com/ManageSSL.

Adding the option to manually turn on encryption seems to satisfy most people in the security community, probably since it enables us geeks to protect our privacy online through encryption. But the majority of the webmail users online are not aware of the risk of getting their traffic sniffed and do also not know how to turn the encryption feature on. The encryption must therefore be turned on by default in order to protect the broad mass of webmail users.

An open letter written by some well known security profiles, such as Jacob Appelbaum, Richard Clayton, Roger Dingledine, RSnake, Jeff Moss, Ronald L. Rivest and Bruce Schneier, was sent to Google in June 2009. In the letter the authors requested that Google should turn on encryption as part of the default settings:

Rather than forcing users of Gmail, Docs and Calendar to “opt-in” to adequate security, Google should make security and privacy the default.

The letter also mentioned that other competing webmail providers had even worse security since they didn't even provide any “opt-in” encryption at that time:

Google is not the only Web 2.0 firm which leaves its customers vulnerable to data theft and account hijacking. Users of Microsoft Hotmail, Yahoo Mail, Facebook and MySpace are also vulnerable to these attacks. Worst of all – these firms do not offer their customers any form of protection.

But how many of the major webmail providers do actually provide HTTPS as the default protocol today? We will in this blog post look closer at two major webmail services online: Gmail and Hotmail.

GMAIL

Just like most other webmail services Google's Gmail use HTTPS to encrypt the username and password while logging in. But Gmail now also provide encryption by default also after the user has logged in. This prevents hackers as well as investigators/analysts from extracting sent emails by sniffing network traffic.

Hackers have on the other hand been able to take over other users' logged in Gmail sessions for some time by sniffing the GX cookie and using it to fool Gmail that they are logged into the victim's user account. Google have now mitigated this issue by adding encryption and setting the GX cookie to “Secure connections only”, which means it will only be sent in HTTPS sessions.

There is, however, another cookie parameter used by Gmail that is allowed to be sent across an unencrypted HTTP session. This cookie is called “gmailchat” and is typically submitted when visiting http://mail.google.com/mail. This cookie parameter is picked up by NetworkMiner and displayed on both the Credentials tab as well as the Parameters tab.

gmailchat parameter

The client IP address, login time and Gmail account of a gmailchat cookie can be used as evidence by an analyst in order to determine which person that was using a particular computer at a particular time.

HOTMAIL

The security in Hotmail is much worse than that of Gmail. With default settings only the login is protected with encryption, everything after that is sent in cleartext HTTP. This makes it possible to extract emails sent with Hotmail just by passively sniffing the network traffic from a logged in Hotmail user. In our recent “TCP/IP Weapons School” blog post we showed how NetworkMiner displays extracted emails in the Messages tab, this feature works just as well also with Hotmail traffic. By loading a pcap with Hotmail web traffic into NetworkMiner you would get something like this:

Extracted Hotmail message

You can also use the Parameters tab to look for parameter names “fFrom”, “fTo”, “fSubject” and “fMessageBody” and thereby manually extract who sent and received the email as well as read the subject and message of the email. These parameters are all sent in an unencrypted HTTP POST to mail.live.com.

So if you're using Hotmail or Windows Live Mail, make sure to visit https://account.live.com/ManageSSL and enable the encryption functionality!

Posted by Erik Hjelmvik on Saturday, 12 February 2011 15:01:00 (UTC/GMT)

Tags: #Hotmail #SSL #HTTPS #NetworkMiner

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=112B58E

twitter

NETRESEC on Twitter

Follow @netresec on twitter:
» twitter.com/netresec


book

Recommended Books

» The Practice of Network Security Monitoring, Richard Bejtlich (2013)

» Applied Network Security Monitoring, Chris Sanders and Jason Smith (2013)

» Network Forensics, Sherri Davidoff and Jonathan Ham (2012)

» The Tao of Network Security Monitoring, Richard Bejtlich (2004)

» Practical Packet Analysis, Chris Sanders (2017)

» Windows Forensic Analysis, Harlan Carvey (2009)

» TCP/IP Illustrated, Volume 1, Kevin Fall and Richard Stevens (2011)

» Industrial Network Security, Eric D. Knapp and Joel Langill (2014)