2411, 2011

DeepSec 2011 Conference Network Observations

René Pfeiffer/ November 24, 2011/ Security, Stories

All of you who attended DeepSec 2011 know that we had a Wall of Sheep at the conference. We set it up by copying packets via the Netfilter TEE target from the router to the Wall of Sheep box (note to self: never ever mirror broadcast or multicast packets). We only displayed logins and the number of characters of the password, all data was processed and stored in RAM. The display was only accessible from the conference network. On the first day of the conference we did not announced the Wall, we only encouraged everyone to use secure protocols and not to use services that send sensitive data unprotected. We even set up posters and flyers warning to use the conference network (the reason were other events at the venue taking place in parallel).

Read More

0811, 2011

Conference Network Survival Guide for DeepSec 2011

René Pfeiffer/ November 8, 2011/ Administrivia

For all of you who frequently visits „hacking hot spots“ this should be familiar. For all others who blindly trust the Net it should be a wake-up call. Here’s a short and probably incomplete check-list in case you are preparing for DeepSec 2011 or any other event with a public Internet access (the CCC has a more complete list on their event web site). Secure your operating system (vendor and type doesn’t matter). Backup your data. Do run a firewall or a similar filter on your device (vendor and type doesn’t matter). The hostile network starts right at your antenna or Ethernet jack (again regardless of vendor and layer 1 technology). Try to use a VPN tunnel to a trusted network (such as your company or home network). Tunnel all traffic through your VPN

Read More

1410, 2011

Talk: Design and Implementation of a Secure Encryption-Layer for Skype Voice-Calls

René Pfeiffer/ October 14, 2011/ Conference

You probably use communication tools that transport the voice/messaging data over the Internet. We’re not speaking about e-mail, but about recent software of the information age – Skype. Skype is widely used for audio/video chats around the world. Its security is shrouded in proprietary mystery and many urban legends exist. In 2006 Philippe Biondi and Fabrice Desclaux analysed the Skype network and its security in their talk „Silver Needle in the Skype“. Since end users can neither create their own cryptographic keys nor see the ones that are actually used, the network has always the capability of eavesdropping on calls. It is not clear if this capability is used or abused at all, but the risk is present. As with eavesdropping in mobile phone networks the communication partners will be totally oblivious, and neither

Read More

2509, 2011

The BEAST SSL Attack and the postponed Digital Apocalypse

René Pfeiffer/ September 25, 2011/ Security

When it comes to security flaws of SSL/TLS (either in theory or in implementation), then a lot of people get very nervous. The past days have been full of media coverage of the BEAST SSL Attack. Since Juliano Rizzo and Thai Duong have published their results the level of speculation has dropped. Let’s replace panic by analysis of facts. Starting with the name of the BEAST, Browser Exploit Against SSL/TLS Tool, it is clear that a browser and a web site is involved. If you take a look at the description of the attack, you can infer that the impact doesn’t affect all SSL/TLS deployments. The following text is taken from Bruce Schneier’s blog entry on BEAST. The tool is based on a blockwise-adaptive chosen-plaintext attack, a man-in-the-middle approach that injects segments of plain text

Read More

0409, 2011

Encrypted Communication with DeepSec

René Pfeiffer/ September 4, 2011/ Administrivia

For all of you who do not pay close attention to our contact section on our web site, we offer various way to communicate via encrypted messages. We have published two GPG keys, one for our role account (key 0x22860969)  and one for a person from our organisation team (key 0x6E4037AF). Use PGP/MIME format if possible (ASCII armour is so old school ☺). We have set up an e-mail forwarding service via privacybox.de. You can use a standard web form, a form suited for mobile clients and a form reachable via a TOR hidden service. While we have no idea how privacybox.de handle their own security, it’s a nice service. You can always double- or triple-encrypt if in doubt. When on IRC (channel #deepsec on irc.freenode.net, usually most active prior to and shortly after

Read More

3108, 2011

Talk: How Terrorists Encrypt

René Pfeiffer/ August 31, 2011/ Conference

Encryption technology has always been regarded as a weapon, due to its uses in wars and espionage. Software used for encryption was banned for export to other countries in the US. The export regulations for strong cryptography were relaxed in 1996. Some countries still consider cryptographic software as a threat. Recently there have been discussions in the USA again about controlling access to encrypted communication channels. The United Arab Emirates, Indonesia, India, and Saudi-Arabia legally attacked the BlackBerry’s strong encryption of the BlackBerry Messenger Service. Encrypted messaging was discussed in UK after the riots in August. Pakistan has banned all encryption and requires users to apply for a permit. Usually the proponents of regulations claim that terrorists and cybercrime are heavy users of strong cryptography. So how do terrorists really encrypt? Are there software

Read More

0805, 2011

Talks held at the Linuxwochen Wien

René Pfeiffer/ May 8, 2011/ Security, Veranstaltung

MiKa and me held three talks at the Linuxwochen Wien 2011. The scheduled talks were „VoIP Security“ and „The Wind Chill Factor of Security“. The third talk was a review of the trust models used with X.509 certificates and issued by certificate authorities. The review was a drop-in replacement talk for a speaker who did not show up. Since the talks were held in German, I’d like to present a short summary in our blog. VoIP has become a well-established technology in companies during the past years. Periodically we assess the security of VoIP protocols and implementations. The talk we gave was a review of the state-of-the-art focussing on SIP signalling and audio/video codecs. We discussed the basics, the SIP Digest Authentication Leak found by Sandro Gauci, SIP probes, the troubles of SIP gateway

Read More

1511, 2010

A Brief History of GSM A5/2 and 2G/3G Security

René Pfeiffer/ November 15, 2010/ Stories

MiKa and me shared some knowledge about the design flaws and the state of security in 2G/3G networks. The idea was to present an overview. Those networks have been shrouded in NDAs for too long. It is good to see that this is changing. Given the fact that millions of people use this technology on a daily basis, there should have been more publications and a deeper analysis many years ago. GSM features four A5 encryption algorithms. They are called A5/0, A5/1, A5/2 and A5/3. A5/0 is basically plaintext, because no encryption is used. A5/1 is the original A5 algorithm used in Europe. A5/2 is a weaker encryption algorithm created for export (the weakness is a design feature). A5/3 is a strong encryption algorithm created as part of the 3rd Generation Partnership Project. The

Read More

1210, 2010

Thoughts about Secure Communication and Wiretapping

René Pfeiffer/ October 12, 2010/ Communication

Secure communication is a very important cornerstone of modern network design and corporate infrastructure. The need to communicate securely is part of everyday life. Businesses, political groups, individuals, governments, non-governmental organisations, and many others use secure communication. The basic idea is that you put a decent portion of trust into the way you exchange messages. Typically the message is only seen by the sender and the recipient. Many take this property of message exchange for granted, but you have to use suitable protocols to meet this goal. Secure communication protocols usually use encryption or steganography to protect and hide the transported messages. Anyone intercepting the data transmission must not be able to decode the original message(s) sent. This is the idea, and when designing secure protocols there is no way around it. Some use

Read More