maZZoo maZZoo's blog
very low frequency tech postings  -  security

    code [12]
    dect [4]
    hard [8]
    meta [5]
    security [5]

jul 2009 (1)
jun 2009 (1)
jan 2009 (2)
dec 2008 (1)
oct 2008 (1)
jan 2008 (1)
oct 2007 (1)
jun 2007 (1)
feb 2007 (3)
jan 2007 (3)
nov 2006 (2)
aug 2006 (2)
jul 2006 (1)
may 2006 (1)
nov 2005 (2)
oct 2005 (1)
apr 2005 (2)
mar 2005 (2)
feb 2005 (1)
jan 2005 (1)
may 2004 (1)
jan 2004 (1)
apr 2003 (1)
jan 2003 (1)

Tue, 23 Jan 2007

update your Fritz!box now

Today around teatime AVM released a new firmware version 14.04.26 which fixes the DoS condition in the SIP daemon.

Get it from their official servers

I was in close contact with AVM the last two days and they did a good and quick job; I had gotten that firmare this morning already but only found time now to test it. It IS fixed :)

So to AVM I need to say: thanks for all the Fritz! And for the rest of you who might still be disappointed about the long time it took from my first report to the fix, one of the remarkable statements from AVM was that because there was no remote execution vulnerability or any danger of information leakage at any time they just planned to fix the DoS condition in the next feature release. Real security threats will still be handled immediatly.
Hope the day for proof doesn't come :P

posted in /security  |  link  |  comments [1]   

Thu, 18 Jan 2007

Fritz!Box 7050 (and others) DoS

Sending a zero-length UDP packet to port 5060 (SIP) of a Fritz!Box will crash the VoIP-telephony application. This works from any IP-interface, including the DSL line.
The vendor AVM was notified almost six month ago, he stated he had a fix still on that same day, but failed to release any firmware updates containing the fix. Nevertheless AVM did release a new (vulnerable) firmware version 14.04.25 in December 2006, and later they had sent me a firmware image in January to test against the DoS. I couldn't test that Jan-image as it kept bricking my 7050 whenever I configured the DSL internet interface.
I had sent a report of various tests I did with the Jan-image to AVM, and got ... no reaction. The only thing I noticed is that they have removed the December 2006 image..?!

Here's my personal DECT paranoia conspiracy theory: the kernels of the Dec. and Jan. images contain the string "DECT+AnnexA", and AVM had to remove it for license issues. AVM going DECT?

obviously the firmware images still contain a linux kernel with the respective license, so here they are. Source code to be obtained from AVM.

still awaiting a fix very soon.
  • AVM advises not to use the above images, as they contain bugs. They may brick your Fritz!box, as I did with mine. Restoring older FW is still possible with the recovery tool.
  • AVM is going DECT

posted in /security  |  link  |  comments [29]   
Wed, 03 Jan 2007

don't update your Fritz! box 7050

actually I had preferred to title this blog post "update your Fritz! box now"...
The story:
about a year ago in Jan 2006 I had discovered a very simple DoS against the telephone application in my Fritz! box 7050. It is triggered by a single UDP packet and works from the internal LAN, as well as from the internet. For the less technichally inclined reader: UDP means the packet can be even spoofed, which leaves the victim blind about who the attacker was...
The effect is that outgoing phonecalls won't work anymore.
I kept updating my Fritz! box with various firmware releases from AVM, but the bug wasn't fixed. So on July 21st 2006 I contacted AVM about the bug, and they stated were able to reproduce and fix the bug within the same day (hey, and they did that on a friday afternoon!).
I tried to be kind and told them I wanted a fix within two month, and that I will not disclose the bug within that timeframe. AVM was even kinder and sent me a T-Shirt plus some more HW bakshish (including that same vulnerability :), and the promise that the bug will be fixed with the 2nd-next firmware-release, as the subsequent release was in the next week, and it was too late to include the fix...
Then there simply were no more firmware updates for monthes. Now on December 13th 2006 a new firmware version 14.04.25 was released. I tested it this morning, but guess what? 14.04.25 is still vulnerable.

So I contacted AVM again, this time with a strict time constraint of 14 days, after that I will disclose what that UDP packet looks like.

BTW: I didn't look at the details, but it "feels" as if this bug doesn't lead to remote execution.
Read more on Jan 17th here...

posted in /security  |  link  |  comments [0]   

Fri, 25 Aug 2006

ohrwurm-0.1 - an RTP fuzzer

ohrwurm is a small and simple RTP fuzzer, I tested it on a small number of SIP phones, none of them did withstand.

  • reads SIP messages to get information of the RTP port numbers
  • reading SIP can be omitted by providing the RTP port numbers, sothat any RTP traffic can be fuzzed
  • RTCP traffic can be suppressed to avoid that codecs learn about the "noisy line"
  • special care is taken to break RTP handling itself
  • the RTP payload is fuzzed with a constant BER
  • the BER is configurable
  • requires arpspoof from dsniff to do the MITM attack
  • requires both phones to be in a switched LAN (GW operation only works partially)

Send feedback on anything ohrwurm broke to ohrwurm/at/mazzoo/dot/de, even if it was a famous packet sniffer ;)

posted in /security  |  link  |  comments [5]   
Sat, 05 Aug 2006

ICMP3, and cisco insecurity

I am at ICMP3 a nice hacker's event meeting nice people and having fun with lots of HW and SW. I will give a speech tomorrow, for which I still have to prepare some slides.

I was assuming I can find a lot of VoIP/SIP HW here to play around with, but I was a little bit disappointed not to find too much. I had prepared a piece of SW to stress VoIP phones (later there will be more on this), I also had success on all of them (as in crashing them).

The only exception is a Cisco 7905 SIP phone, where I couldn't even get to the point of attacking the SIP stack or codecs. The market leader in IP networking HW has implemented a remote reboot procedure:

# arpspoof
44:44:44:44:44:44 ff:ff:ff:ff:ff:ff 0806 42: arp reply is-at 44:44:44:44:44:44

Sigh. I need that command to run my stress test SW. Model and version are:
App Load ID
Boot Load ID

posted in /security  |  link  |  comments [0]   

validate HTML