Showing posts with label Traffic Analysis. Show all posts
Showing posts with label Traffic Analysis. Show all posts

Friday, April 2, 2010

Open Source Keykeriki Captures Wireless Keyboard Traffic

Another interesting attack, rather than going after the PC/Server this one goes after the data sent by wireless devices such as the wireless keyboards sold by Microsoft. The neat thing is by using a replay attack you could also send rogue inputs to the device.

But then it serves Microsoft right for using XOR encryption for the data-steams, which can very easily be broken using frequency analysis.

Security researchers on Friday unveiled an open-source device that captures the traffic of a wide variety of wireless devices, including keyboards, medical devices, and remote controls.

Keykeriki version 2 captures the entire data stream sent between wireless devices using a popular series of chips made by Norway-based Nordic Semiconductor. That includes the device addresses and the raw payload being sent between them. The open-source package was developed by researchers of Switzerland-based Dreamlab Technologies and includes complete software, firmware, and schematics for building the $100 sniffer.

Keykeriki not only allows researchers or attackers to capture the entire layer 2 frames, it also allows them to send their own unauthorized payloads. That means devices that don’t encrypt communications – or don’t encrypt them properly – can be forced to cough up sensitive communications or be forced to execute rogue commands.

It’ll be interesting to see what other kinds of devices they can successfully use this data capture technique on. Keyboards are one thing, and I’d imagine the transmission range of a wireless keyboard is fairly limited so you or the sniffing device would have to be physically near to the target.

At least Logitech seem to have stepped up the security a bit by using AES-128 for the transmission on their wireless keyboards, but the researchers say they still may be able to crack it due to the way the secret keys are exchanged.

Again most likely not an algorithm problem but an issue with the implementation.

At the CanSecWest conference in Vancouver, Dreamlab Senior Security Expert Thorsten Schroder demonstrated how Keykeriki could be used to attack wireless keyboards sold by Microsoft. The exploit worked because communications in the devices are protected by a weak form of encryption known as xor, which is trivial to break. As a result, he was able to intercept keyboard strokes as they were typed and to remotely send input that executed commands on the attached computer.

“Microsoft made it easy for us because they used their own proprietary crypto,” Schroder said. “Xor is not a very proper way to secure data.”

Even when devices employ strong cryptography, Schroder said Keykeriki may still be able to remotely send unauthorized commands using a technique known as a replay attack, in which commands sent previously are recorded and then sent again.

News time is always fun during conference season due to the fact all these interesting and new attacks and vectors are released for public consumption – generally along with code and examples.

If they can use the same techniques to own more interesting devices with more sensitive data, things could certainly get a little more heated.

source : darknet.org.uk

Wednesday, December 16, 2009

Monitoring Traffic with Span Ports

This is just a quick post to detail the configuration of setting up a Span Port on a Cisco 2950 switch to monitor traffic.


Previously I had used either a hub or ARP poisoning to capture traffic in a switch environment. On my Cisco switch I can capture traffic by telling the switch to send a copy of all traffic destined for one port (or multiple ports) to another port.


Span Port Configuration

In the configuration below I have told the switch to send a copy of all data sent or received from the port range 3 - 5 to port 23

S1(config)#monitor session 1 source interface fastEthernet 0/3 - 5 both
S1(config)#monitor session 1 destination interface fastEthernet 0/23


The configuration can be verified with the following command:

S1#sh monitor session 1



This works across VLANs too, as port 23 is configured into a separate VLAN from ports 3 to 5.

This should emphasise the need to secure your switch (passwords, SSH, lock down ports etc..) as it is obviously great for monitoring traffic but can also be used by an attacker to capture traffic.


Links
Here is a great Cisco article on all things Span Port!

Saturday, December 12, 2009

Fun with Tcpdump

Tcpdump is a really useful program for capturing packets that are on the wire. It can be used to view packets going through your own interface, on a network with a hub, or on a switched network (arp-cache poisoning or mirrored switch ports).

The output from tcpdump can either be sent to the screen, written to a raw file using -w and viewed with tcpdump (using -r) or the capture files can be read with a tool such as Wireshark.

Tcpdump is a tool that anyone who is interested in networks should be familiar with. It will help you understand what normal traffic looks like on your network at a packet level so you can quickly identify abnormal traffic.

The purpose of this blog post is to get a few of the commands documented to familierize myself with tool so i can quickly apply filters when needed.

For the Windows users there is a very good port of tcpdump called Windump, the syntax is very similar if not identical.


Using Tcpdump

When first running tcpdump without any filters the output can be overwhelming. Don't worry about this, as you begin to get familiar with the filters you can quickly get to the information you want.

If you have multiple interfaces that are up you may need to use the -i {interface} switch.

tcpdump -i eth1

The command can be terminated with ctrl+c.

I recommend using the -n switch to prevent name resolution whilst you are performing the capture. The name resolution can always be performed later.

tcpdump -i eth1 -n

You can also cut down the amount of data you capture by using the quiet option (-q)

tcpdump -q

Or to really cut down on what i can see I could use the following which would just display the from and to, the protocol and the packet size:

tcpdump -qt

As previously mentioned the output of tcpdump can be sent to a file using the -w switch or straight to a text file using the redirect >

I recommend writing the output to libpcap format using a command such as:

tcpdump -i eth1 -n -w capture.lpc

However, you may want to view the output on the screen as you write it to a file, this can be done by using the -l switch and piping through tee into the file:

tcpdump -l | tee mydump


You can also limit the capture to a certain amount of packets using the -c switch. To only collect 100 packets:

tcpdump -c 100


The -c switch can also be used when reading from a packet capture file:

tcpdump -n -s 1514 -r capture.lpc -c 5 tcp

The command above will read the first 5 tcp packets from the capture.lpc file.




Collecting Packets Based on Size

Usually tcpdump does not collect the entire packet. Use the snaplen option -s 0 to force it to do so:

tcpdump -s 0

Or to only collect the first 1514 bytes of a packet:

tcpdump -s 1514

1514 bytes will capture the ethernet portion without VLAN tagging. To capture the VLAN tagging information an additional 4 bytes will need to be added.


To only collect packets from a particular host:

tcpdump -i eth 1 -n -w capture.lpc host 208.68.234.113


Name Resolution

As mentioned earlier, by default tcpump will resolve network addresses into names. To disable this use the -n switch. And to disable port resolution use -nn:

tcpdump -nn

Use -f to prevent remote name resolution.


If you are on a local LAN and want to capture only traffic based on a MAC address use:

tcpdump ether host 11:22:33:44:55:66:77:00

Or if you want the Ethernet header in the output use the -e option:

tcpdump -i eth1 -e -n -s 1514-w capture.lpc

To restrict the capture to a network use:

tcpdump -i eth1 -n -w capture.lpc -s 1514 net 192.168.1

or

tcpdump -i eth1 -n -w capture.lpc -s 1514 net 192.168.1.0 mask 255.255.255.0


Using Keywords

Keywords alow you to easily filter traffic. The Keywords that can be used are ip, tcp, udp, icmp and igmp.

As an example of using keywords, to capture all IP traffic use keywords:

tcpdump -i eth1 -n -w capture.lpc -s 1514 ip

or to capture just TCP traffic:

tcpdump -i eth1 -n -w capture.lpc -s 1514 tcp

Other traffic types without keywords can be captured using the "ip proto" option:

tcpdump -i eth1 -n -w capture.lpc -s 1514 ip proto l2tp

or by its protocalnumber as found in the /etc/protocols file:

tcpdump -i eth1 -n -w capture.lpc -s 1514 ip proto 115


To capture traffic based on it's application from further up the stack such as ftp traffic specify the port:

tcpdump -i eth1 -n -w capture.lpc -s 1514 port 21

And to capture the data portion of the FTP traffic as well you could add port 20:

tcpdump -i eth1 -n -w capture.lpc -s 1514 port 21 && port 20

This could have been specified by name as detailed in the /etc/services file.

tcpdump -i eth1 -n -w capture.lpc -s 1514 port ftp && port ftp-data

In the examples above I have used && to add 2 filters together. I could have used the word 'and' instead. You can also use 'or' to idicate that i want one filter to apply or another filter to apply. || means the same as 'or' also.

tcpdump -i eth1 -n -w capture.lpc -s 1514 port http or https
tcpdump -i eth1 -n -w capture.lpc -s 1514 port 80 || 443

The above filters will capture the same data.


Filtering by Packet Size

You could create a filter to capture packets that are larger than a certain size (in bytes):

tcpdump -i eth1 -n -w capture.lpc -s 1514 greater 250

This type of filter can be useful if you are trying to locate certain types of packet based on attributes from further up the stack.




We can also tell tcpdump to leave out certain types of traffic, in this example we don't want http or https traffic but we want everything else:

tcpdump -i eth1 -n -w capture.lpc -s 1514 " (not tcp port http and not tcp port https)"



To view the output in output in ascii use -X (the verbose -v is optional):

tcpdump -i eth1 -n -w capture.lpc -s 1514 -X -v

To dump the whole packet in hex use:

tcpdump -i eth1 -n -w capture.lpc -s 1514 -x -v


Further Examples

To display a list of visited sites:

tcpdump -w dumpfile
tcpdump -r dumpfile > textfile
cat textfile /usr/bin/cut -f 8 -d ' ' /bin/grep -i www*


Looking at ICMP

Although you can capture all ICMP traffic, you could actually capture only particular types of ICMP based on attributes of the protocol. For example, if i wanted to capture just ICMP echo requests knowing that an ICMP echo request is a Type 8 i might use:

tcpdump -e -x "icmp[0]=8"

To capture just ICMP repies (Type 0) i might use:

tcpdump -e -x "icmp[0]=0"


Wireless Stuff

If i was curious about what networks wireless clients are probing for I could set my card into promiscuous mode (ifconfig -i eth1 promisc), configure my wireless settings to monitor (iwconfig eth1 mode monitor) and issue the following command:

tcpdump -i eth1 -s0 -nn -vv -t | grep -i request

This would reduce the output to just display probe requets from nearby wireless clients.




Note: I will update this blog entry with new and interesting uses for Tcpdump as I learn them.


Links

For a great book on network monitoring using Tcpdump as well as many other opensource tools try "The Tao of Network Security Monitoring" from Richard Bejtlich.

Another great book on this topic is "Practical Packet Analysis"

+++

Share |

"make something then You never be lost"

wibiya widget