SACK, no Shark

Poor application performance? When it seems your applications are ok but there is something wrong and user experience isn't good enough, look your network!! It could be something about Hot potato and could potato routing in your Autonomous System, or something about Elephants in your Long Fat Networks or even because you are not taking advantages of Multipath TCP. However, this time I don't want that you buy a shark but a SACK or Selective Acknowledgement.

SACK or TCP Selective Acknowledgement is a TCP option defined in RFC 2018 that allows to retransmit only lost segments when there are packets loss instead of retransmiting every packet from the last Acknowledgement. Therefore, we would have a slow and inefficient throughput without SACK because if we use the traditional cumulative acknowledgment scheme, it wouldn't never know what packets have been lost and as a result it could send all packets again.

Next, we can compare both schemes. When we have a cumulative acknowledgment scheme like the left picture (No SACK) and there are packets loss, we see ACK messages ask for lost segments without acknowledging received packets. However, SACK scheme, like the right picture, acknowledges received packets with TCP SACK option and asks for lost packets with ACK messages.

No SACK vs SACK

At first, it seems both schemes are the same but if there are multiple dropped segments and sender can't free up the network buffer, network throughput will be inefficient. In addition, with an extension to the selective acknowledgement (SACK) option for TCP called Duplicate-SACK or D-SACK and defined in RFC 2883, we'll have better network performance because sender can infer the order of packets received at the receiver and it can report duplicate segments.

Selective acknowledgement option is negotiate in the TCP hadnshake with Kind=4 and receiver and sender (both) must support this kind of communication, as we can see in the top picture. While when there are some dropped packet and it should be retransmited by sender, receiver asks them with Kind=5 saying which packets have been received successfully, as we can see in the down picture.

SACK Kind 4

SACK Kind 5

If we have a poor application performance, maybe the issue isn't in the development team but in the networking team, be sure your systems manage this kind of technologies because there are many others like EVN Trunk, Unicast Reverse Path Forwarding (URPF), Tribal Flood Network (TFN), etc and if your are not network engineer maybe you are not aware about it.

Regards my friends and remember, networking isn't plug and play.

Bluetooth Security

Teeth with Bluetooth?? Awesome. This Personal Area Network (PAN) called Bluetooth is becoming more and more bigger. Today, we can have socks, shoes, balls, hats, etc in our PAN thanks to this wireless technology and its advance like Bluetooth low energy (BLE or Bluetooth Smart) which is intended to provide considerably reduced power consumption and cost saving. However, we should be careful because everything is in the air and an attacker could take advantage of this wireless technology using some of the next tools.

Socks with Bluetooth

 

First, an attacker would scan every bluetooth device around him. In this fingerprinting phase could be used an Ubertooth One Antenna to expand the scanning area range and with the help of some applications like Ramble, BlueScan or hcitool get a detailed list of devices which are around.

Next, there are many tools to try to exploit some vulnerabilities of Bluetooth devices. One of them is BlueSnarf which was published in the late 2003 by Holtmann and Laurie. Actually, BlueSnarf exploits some vulnerabilities of OBEX protocol on mobile phones and pocket palms. The goal of this exploit is to get requests to common files like calendar, contacts, etc easily bypassing the security channel without authentication. The victim wouldn't see any prompt on his device with this attack .

Another interested tool is BlueBug which is a nice exploit developed by Adam Laurie and Martin Herfurt in 2004. This exploit is regarding Bluetooth implementation on mobile phones, especially Symbian OS, where an attacker can control devices through plain serial connecion. For example, the attacker could send SMS to another phone, calling another phone or taking pictures without authentication and without leaving any track in the victim phones. BlueBug can also download items via OBEX protocol without authentication and without any prompt.

BlueChop is another hacking tool, following BlueSnarf. It is useful to break Bluetooth piconets, which is the connection between devices. This is posible if the master phone provide support of multiple connections. The only thing the attacker have to do is spoofing a random slave out of the piconet, spoof his address and contact the master, which will confuse the master's internal state and the piconet will be disrupted.

There are many other tools to hack Bluetooth devices like BlueDump which gets link keys, BlueBump which pushes link keys, Bluelog, BlueMaho, Bluepot, BlueRanger, etc. As you can see, there are a lot of tools to hack Bluetooth devices and we can use Linux distributions like Kali Linux or Bluediving which collect many hacking tools to attack Bluetooth devices easily.

Tips for protection? Turn off your Bluetooth when you don't need it and being aware of who is around you!!!

Regards my friends and remember, Internet of Things (IoT) is here and it's here to stay.

Everything is in the air

WiFi, that tecnology that everybody use and few of us protect. Although most of us protect our wireless networks with hardy security protocols like WPA-PSK or WPA-802.1X, we know the air is free and for everybody and then, our wireless networks can go beyond our offices, buildings and security perimeter. Therefore, an outsider could connect to our wireless network from outside, with the right credentials or exploiting some security flaw. For this reason is important to monitor all mobile devices that it's connecting to our networks, even those that aren't ours (BYOD), because we are used to sending all kind of information for these networks and we also know that once you are in, you can connect to almost anywhere.

This time I would like to write about some wireless attacks, tools and applications useful to understand how to protect our wireless networks. First, an attacker can deny our wireless service (DoS) sending deauthentication/disassociation frames, which can be also used to get beacons to break access passwords. Deauthentication frames are sent when we want to terminate all communications while disassociation frames are sent when we want to leave the current cell to roam to another cell, we also use disassociation frames when we use invalid parameters and many other reasons. Next, we can see deauthentiacion and disassociation frames:

Deauthentication Frame

Disassociation Frame

Today, there are many tools to test our wireless network like aircrack-ng, mdk3, wifite, etc but this time I want to write about WIDSTT developed by Jaime Blasco. This tool is useful to test our WIDS because we can flood the WLAN with deauthentication and disassociation frames, send invalid deauthentication frames, send over-sized SSID, send airjack beacon frames, send invalid channel numbers in beacon frames, etc.

WIDSTT tool

If we want to be “safe”, we'll have to monitor our wireless network with Wireless Intrusion Detection Systems (WIDS) to detect attacks against our access points and mobile devices. A popular wireless network detector, sniffer, and intrusion detection system is Kismet which can be used to detect the main wireless attacks like AP Spoofing or Rogue APs, deauthentication/disassociation attacks, long SSID attacks, etc. However, most manufacturers like Cisco, Fortinet, Aruba, Aerohive have their own WIDS.

Fortinet WIDS

It's time not just to have an IDS and HIDS but a WIDS as well. If you don't still have any WIDS, you can make your own WIDS with Kismet wireless sensors and sending logs to a central management interface to alert to you when something is wrong.

Alienvault WIDS

Regards my friends and remember, drop a line with the first thing you're thinking.

Elephants – Long Fat Networks

Two weeks ago, I wrote about hot potato and cold potato routing because I was studying to recertify my CCNP certification and this was a new concept that I didn't know. Today, I can say I passed the exam and I have learnt more concepts that I would like to highlight in this blog. This time, I'm going to write about how to receive large amount of data, till 1 GB, in high delay and high bandwidth networks.

Everyone who has studied networking knows about TCP Windowing what means servers and endpoints or clients negotiate the amount of data they can transmit without overwhelming each other. We can see 16 bits for Window Size in the TCP header what give us till 2^16 = 65536 bytes or 64 KB that it can be received without sending an ACK message.

TCP Header

What happen in high delay and high bandwidth networks such as satellite links? First, we can transmit a lot of amount of bytes in a single burst but it is going to delay too much time to be received for the receiver. Therefore, we can transmit till 64 KB and after that, we have to wait for an ACK message, what it is inefficient although we have a high bandwidth link. It's like to want to carry a lot of things with an elephant (large amount of data in high delay networks), it will never be fast. This is also called Long Fat Networks or LFN.

However, TCP Extensions for High Performance networks or RFC 1323 (obsolete and replaced by RFC 7323) solves this issue. Window Scaling extends the 16-bit window field to 32 bits in length using a TCP option to specify a count by which the TCP header field bitwise shifts the window size. For instance, we can see in the next image a left shift by 7. First, we had a window size of 5840 bytes and after shifting by 7 we have 747520 bytes of window size.

Left shift by 7

This TCP option is negotiated in SYN packets so it can't be changed once the session is established. Next, we can see a window scale by 7, what means we can receive till 128 x 65536 bytes = 8 MB without sending an acknowledge (ACK) message.

Window Scaling - SYN

 

Next, we can see a window size of 1505 bytes, what it is actually 1505 x 128 = 192640 bytes or nearly 188 KB, what it is much more than 64 KB that we have had without Window Scaling.

Window Scaling

 

Once we know about Window Scaling we should look for these RFCs when we purchase a new appliance. For example, F5 load balancer supports this kind of extensions for high performance in their TCP profiles.

F5 TCP Profile

 

Regards my friends and remember, drop a line with the first thing you're thinking.

More information:

- TCP Windows and Window Scaling

- Understanding TCP Window Size / Window Scaling

Telegram – HTTP over HTTPS

When we think about instant messaging, we think about WhatsApp and Telegram. Today I want to write about Telegram, an application that got popularity after the PRISM project was known and after WhatsApp was unavailable in 24th of February 2014, and particularly I want to write about a behavior that I don't really understand very well. It is said that Telegram is highly secure and this is the reason why ISIS uses Telegram, because they can send secret messages without any tracking but we are going to see that everything isn't encrypted.

Telegram uses MTProto or Mobile Transport Protocol which was released in 2013 by Digital Fortress and it is different from the XMPP protocol. MTProto uses SHA-1 algorithm to encrypt secret messages and XOR-128 for digital sign. In addtion, Diffie-Hellman protocol is used to get session keys. However, what it is weird for me is how Telegram Mobile Apps send POST request in plaintext over the HTTPS port to Telegram servers where we can also see what API is used by the user. Is this useful for an attacker? Maybe yes.

In fact, I have realised about this, looking and analysing an alarm in the Ariolo Probe which detected a network anomaly because there were HTTP traffic over the HTTPS port. In a deep analysis, we can see that the destination IP is from the Telegram company, and POST actions are sent in plaintext to Telegram servers through HTTPS (tcp/443) port. What is this?

Ariolo Probe Alarms

Alarm HTTP over HTTPS

Next, I downloaded the wireshark pcap to analyse thoroughly this behavior and we can even see the API identifier that the user is using. Is this information useful?

Analysis with Wireshark

According to Telegram, this kind of connection is made to send messages:

POST from Telegram

 

I don't know if this is the normal behavior but I don't think so. Meanwhile, we can use other instant messaging applications to protect our communications like Signal Private Messenger or Cryptocat.

Regards my friends and remember, drop a line with the first thing you're thinking.