abb's blog

Linux Routing Quirks

Recently I have spent some time trying to mess up a routing table of Linux appliance to trick it into leaking out certain network traffic I was interested in. In theory it looked reasonably simple, but not quite so in practice. While trying to screw up the appliance I have learned a couple of new things about Linux networking:

Capstats: fast NIC statistics reporting tool

Just came across a nice tool to display NIC statistics, it is called capstats. Capstats is much less CPU intensive that iptraf, so it can be run along with hping3 to monitor its performance.

Example from capstats's website:
>capstats -i nve0 -I 1
1186620936.890567 pkts=12747 kpps=12.6 kbytes=10807 mbps=87.5 nic_pkts=12822 nic_drops=0 u=960 t=11705 i=58 o=24 nonip=0
1186620937.901490 pkts=13558 kpps=13.4 kbytes=11329 mbps=91.8 nic_pkts=13613 nic_drops=0 u=1795 t=24339 i=119 o=52 nonip=0

DNS cache poisoning -- residual risk

I was looking for a way to calculate the probability of success of the cache poisoning attack against a DNS server implementing source port randomization. This paper describes the methodology. There are a few questions I don't have an answer for yet.

1. When I try to reproduce their results (Table 1) I get (slightly) different outcome. I wonder why. My source code is here.
65536 | 4 | 10427 | 0.500000
65536 | 200 | 227 | 0.500000
4294967296 | 4 | 683344693 | 0.500000

An attempt to quantify reliability of port scan results

Some time ago I had to port scan a network which happend to be mostly filtered out and in general rather scarcely populated. When I have started the port scan I had realized that my uplink connection regularly suffers from packet loss as high as 20% and there was no way to fix it in a foreseeable future. The next insight was this: there is no way for a port scanner to produce reliable results under these (and even more favourable) circumstances. So I have tried to quantify the reliability of the results of the port scan exercises carried out over the Internet.

Impact of TLS/SSL Renegotiation Vulnerability on HTTPS: Less Known Issues

There is a couple of issues with TLS/SSL renegotiation vulnerability in the context of HTTPS protocol, which appear not to have made their way to the public.

1. Plain text prefix injection is not the only risk. The original advisory [1] mentions the possibility of "forwarding and repurposing of client certificate authentication credentials". In oss-sec maillist Marsh Ray goes in more details [2], and [3] dedicates one slide to "client certificate redirection".

Shell Script Debugger

I often thought it would be nice to be able to execute shell scripts line by line, like in gbd or perl debugger. Today I have actually tried to find one and of course some nice people have already made it. Bashdb looks and feels similar to gdb -- exactly like I wanted it.

Making Linux network bridge transparent for 802.1x packets

Update 17/01/2011: If you are interested in 802.1x bridging, have a look at my Tapping 802.1x Links with Marvin blog post.

802.1x authentication messages are sent in Ethernet frames with destination MAC address set to 01:80:C2:00:00:03. This address belongs to “IEEE 802.1D MAC Bridge Filtered MAC Group Addresses” (01:80:C2:00:00:00 to 01:80:C2:00:00:0F) and such frames are not supposed to be relayed by bridges conforming to IEEE 802.1D [2]. For a number of reasons, you may want these frames to go through your bridge.

Transparent Connection Interception Trick

Now when I have a blog for half a year I figured I should post something. So here goes description of using Linux (Ubuntu in my case) bridge configured to redirect selected TCP connections to intercepting proxy (Burp) and while letting the intercepting proxy communicate with the server. Quite useful when doing pentests of fat clients and appliances communicating over HTTP(S), especially in a situation when you can't tamper with client's /etc/hosts file or use other technique to redirect interesting traffic.


Subscribe to RSS - abb's blog