Archive for the Category encryption

 
 

Speed is not the issue, but sneaking past it is …

Encrypted and encoded traffic has always been one of the troubles for IDS/IPS systems to handle. A vulnerability was disclosed last week, related to the encoding issue, affecting many systems that does some sort of content inspection of the HTTP-protocol. From the advisory:

Full-width and half-width encoding is a technique for encoding Unicode characters. Various HTTP content scanning systems fail to properly scan full-width/half-width Unicode encoded HTTP traffic. By sending specially-crafted HTTP traffic to a vulnerable content scanning system, an attacker may be able to bypass that content scanning system

Systems affected by the vulnerability includes most commercial and “free” IDS/IPS systems, including Snort, Bro, TippingPoint and ISS - and disables their detection/protection for attacks mounted in HTTP-sessions.

Interop (as in: “just another vendor conference”) is currently running at the other side of the pond. This is a conference were its common for vendors to release their new silver-bullet products - and IDS/IPS vendors is not an exception. The strange thing with many of the vendors of IDS/IPS-products, is that they seem to focus on relatively irrelevant features - not on these kind of issues that could increase their ability to detect and actually prevent intrusions. They seem to think that the biggest issue with their technology, or the greatest improvement, is to increase the speed at which the devices can inspect and block traffic. ISS is battling Tippingpoint, who can currently operate their IPS at 5 gbit speeds, with a system that can now run at 15 gbit (which in reality means more like 6 gbit). Still, no body with the intention of buying and IDS/IPS for getting increased security should let speed be deciding factor. These people might just as well look at a an firewall with some sort of novel deep inspection.

May 22nd, 2007 | encryption, Intrusion Detection, Security | 3 Comment

Decoding and decrypting SSL-sessions as Eve

Many aspects of encryption is interesting, and one of them is the issue of detecting attacks hidden in encrypted sessions. One of the main advantages of running IDSs and IPSs in demilitarized zones is to detect and respond to intrusion attempts on the public available servers. We've all seen the vast number of (mostly automated) intrusion attempts in our apache logfiles. An IDS/IPS is commonly connected by a network tap to a switch in the DMZ, and can thus detetct these attempts too… if the attacking session doesn't connect to the server under HTTPS and performs their attempts. This is an interesting challange - How do we monitor and respond to attacks on our public servers if they are in encrypted sessions?

SSLDump is an interesting application, which utilises LibPCAP to sniff the network in promisc mode, and is able to decode SSL traffic on the fly - AND - most interestingly, decrypt the application layer data if supplied with the X.509 private key of one of the parties - A technique often refered to as "key escrow".

We supply ssldump with the private key of our apache webbserver, listens on interface eth0, and tell ssldump to decrypt the traffic. We connect our webbbrowser to the server under https, and fetch the unexisting webbpage secure.html. This session should not be viewable to our sniffer, as it's under HTTPS. Let's see how SSLDump manages this:

neewt@twosome:~$ sudo ssldump -d -k ./snakeoil-rsa.key -i eth0

After information of handshake messages and their containts, the following application layer data is presented, in decrypted form (The full output of the command is available as a plain text file).

11 10 0.2063 (0.1715) C>S application_data
---------------------------------------------------------------
GET /secure.html HTTP/1.1
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.3 (like Gecko) (Kubuntu package 4:3.4.3-0ubuntu1)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate
Accept-Charset: utf-8, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: 192.168.0.10

---------------------------------------------------------------
1 11 0.2072 (0.0009) S>C application_data
---------------------------------------------------------------
HTTP/1.1 404 Not Found
Date: Mon, 12 Dec 2005 16:09:22 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-15 mod_ssl/2.8.22 OpenSSL/0.9.7d
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

113
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /secure.html was not found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.33 Server at 192.168.0.10 Port 443</ADDRESS>
</BODY></HTML>

SSLDump managed to decrypt the session on the fly. The interesting part of this, is that if SSLDump is somewhat modular, much of the code could be used in a pre-processor for Snort, to give it functionallity to decode and alert on malicious traffic inside SSL-sessions. I believe I've heard about plans of such a pre-processor. I know SourceFire co-operates with a vendor selling SSL-accelerators with decryption-capabilities which gives them the same functionallity in their appliances - This is probably why we haven't seen support for it in Snort yet :)

December 12th, 2005 | encryption, Intrusion Detection, Security | 0 Comments

Using one time passwords with Secure shell

Some time ago, we had a laboration accercise as a part of a course at the university, which involved setting up One time password-authentication. This accercise actuall failed because it was badly planned. However, to me it sounded cool, and I wanted to give it a shot. It would be awesome to be able to use one time passwords for remote logins when sitting on a (insecure?) coffeyshop in, say thailand? My friend Johnny later told me that he’d implemented the intended setup, so I aimed to do the same.

Using Debian makes this task easy (as always). I’d like to point out that I’m (still) running the stable Woody-set, but if you’re running Sarge there will probably not be to many differences.
First off, install the package opie-server (this will also include opie-client, as it’s a dependencie). This is the tools that makes this magic work. The Opie-server creates and maintains the OTP-keys, and Opie-client makes OTP-passwords off those keys (very roughly spoken). To be able to use this in a real login-procedure, we need to install libpam-opie. This gives us the tools to enable OTP-authentication for real, with for example SSH.

foursome:/# dpkg -l : grep opie
ii libpam-opie 0.21-7 Use OTP’s for PAM authentication
ii opie-client 2.32-8.1 OPIE programs for generating OTPs on client
ii opie-server 2.32-8.1 OPIE programs for maintaining an OTP key fil

Now, all we have to do is enable this PAM-module in the apropriate configuration file, which is /etc/pam.d/ssh. There are alot of different setups available for this, and some of them can be found in libpam-opie’s documentation (found in /usr/share/doc/libpam-opie/). In my configuration example, I will be able to login with my ordinary unix-password -OR- a One Time Password. Why? Simply because it would be extremely inconvinient for me if I had to use a OTP even though I login from my secure LAN, which is what I do in 90% of the cases. But, for those occasions when I don’t trust the computer I’m at (if I believe there might be keyloggers or somehting like that on them, in other words, any Windows-box :)), I can just choose to login with a OTP. To have this configuration, be sure to have the following “auth”-lines in your /etc/pam.d/ssh.

auth required pam_nologin.so
auth required pam_env.so # <1>
auth sufficient pam_unix.so
auth sufficient pam_opie.so
auth required pam_deny.so

Basicly this tells us that unix-passwords are sufficent, so are opie OTP-passwords. If neither are met, the login will be denied. Also, be sure to enable PAM-authentication in /etc/ssh/sshd_config by setting UsePrivilegeSeparation no and PAMAuthenticationViaKbdInt yes, and restart sshd.

Now, we are at the step of creating the OTP-keys and passwords.

test@foursome:~$ opiepasswd -c -f
Adding test:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase: ******
Again new secret pass phrase: ******

ID test OTP key is 499 fo7385
SKIN TRIO FARM OATH MA SHE
test@foursome:~$

This should be done in a secure enviroment, and not from remote, as I’m doing here.
The last two lines tells us that the OTP for matching sequencenumber 499 and with seed fo7385 is “SKIN TRIO FARM OATH MA SHE”. So logging in from remote to this host will look something like this (first, the unix-password is prompted, and simple enter will skip that)

$ ssh test@192.168.0.10
Password:
otp-md5 499 fo7385 ext, Response:
Linux foursome 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 unknown

test@foursome:~$

But how would we know the One time password when we are at a remote location? Well, either you can use some sofware that can calculate the password when configured with the secret passphrase and OTP sequence number. Or, you can have a list of passwords printed out. To get a range of sequence-numbers, all you have to do is something like this

test@foursome:~$ opiekey -n 10 498 fo7385
Using the MD5 algorithm to compute response.
Warning: Continuing could disclose your secret pass phrase to an attacker!
Enter secret pass phrase:
489: GILT ROTH VINE CHOU LYNN THAN
490: SILO BAIL ULAN TELL NEWT ITEM
491: ROOD CLOD HOWE BONG LUGE WIN
492: DRAW NIT HOOD RACY NOVA SHAG
493: REIN ROAD HERB LEAK MAID KANT
494: SAG AIRY OMIT VIEW GLOM ECHO
495: CRIB ENDS GUST ACHE JOG BAH
496: CANE IRE BEET MORN CUP BREW
497: SUNK IDLE HAWK HUGH KNEE FIG
498: WET RUDY ORGY GRAY ARAB SET

This will give us 10 OTP’s.

I’ve probably forgotten something, and if you notice what, please inform me. I think this is a good way of adding a bit of extra security to SSH and remote-access. If my Ericsson T610 would support a decent version of Java I’d be happy, because then I could run a sofware-OTP-calculator, such as jotp

January 1st, 1970 | encryption, System Administration, Security | 1 Comment