Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : This week Doug Burks and I needed to decrypt a few gigabytes of SSL traffic to find a TCP stream that contained a key word. We learned a bit along the way so I'm passing it along here. First, full packet capture rocks. You are capturing EVERY packet that goes in and out of your network, right Yeah, I know you have a HUGE internet pipe. But for a few hundred bucks you can have TERABYTES of drive space on an old laptop with DAEMONLOGGER running. I'd suggest something a little better, but you can make full packet capture work on a shoestring budget. Capturing the data is the easy part. Finding a needle in that haystack when it is all encrypted is the hard part. SSLDUMP is one option, but I am really only interested in the text in the HTTP Payload and SSLDUMP give you a lot more information. We decided to use TSHARK because it has the ability to decrypt SSL and you can use Wireshark display filters. We started out with something like this tshark -n ssl.desegment_ssl_records TRUE -o ssl.desegment_ssl_application_data TRUE -o ssl.keys_list 0.0.0.0,0,data,private.key -o ssl.debug_file SSL-Decrypt.log -r all.pcap -R tcp.stream eq 1 The first problem we ran into was the format of our private key. We had the right private key but every time we started tshark it recorded unable to load PEM in the log file. Long story short, '---BEGIN PRIVATE KEY ---------- and ------BEGIN RSA PRIVATE KEY----- are NOT the same thing. Wireshark and Tshark want the private key in PKCS 1 format which is the --- BEGIN RSA PRIVATE KEY--- format. The other format is PKCS 8 format and Wireshark won't load keys in that format. Step one was to convert the PKCS 8 private key to PKCS 1 format. Openssl does the trick openssl pkcs8 -in private.key -out rsaprivate.key -nocrypt With our new PKCS 1 format private key rsaprivate.key , the tshark command line became tshark -n -o ssl.desegment_ssl_records TRUE -o ssl.desegment_ssl_application_data TRUE -o ssl.keys_list 0.0.0.0,0,data,rsa_private.key -o ssl.debug_file SSL-Decrypt.log -r all.pcap -R tcp.stream eq 1 Now tshark's log file no longer said unable to load PEM , but instead it said key loaded successfully . However, two lines down in the log we saw couldn't find key for this server, try the universal port 0 and the universal IP 0.0.0.0 . This entry was a little confusing as we were already using the universal IP and port. So we changed that to the actual IP address and port of the server and BAMM... The next time we ran tshark the SSL-Decrypt.log file grew REALLY fast. So how do we make tshark output HTTPS traffic as decrypted HTTP traffic in plain ASCII format similar to tcpdump -A One option is to tell tshark to output the data field data.data using the -T fields -e data.data parameters. However, this output is in hex. We can pipe it to xxd -r -p to convert to ASCII tshark -n -o ssl.desegment_ssl_records TRUE -o ssl.desegment_ssl_application_data TRUE -o ssl.keys_list 0.0.0.0,0,data,rsa_private.key -o ssl.debug_file SSL-Decrypt.log -r all.pcap -R tcp.port eq 443 -T fields -e data.data xxd -r -p That seemed to work for us. Our SSL streams were dumping their payload in ASCII and we could find our string, but Doug he is a bit of a perfectionist changed the options to this tshark -o ssl.desegment_ssl_records TRUE -o ssl.desegment_ssl_application_data TRUE -o ssl.keys_list ,443,http,rsa_private.key -o ssl.debug_file rsa_private.log -r all.pcap -R tcp.port eq 443 -V By changing the 3rd parameter of the ssl_keys_list form data to http , tshark parses the decrypted packets with its HTTP parser. When the -V option is passed, tshark gives you a nice fully parsed unencrypted HTTP stream. Piping that through GREP works very nicely. GET index.html HTTP 1.1 r n Expert Info Chat Sequence GET index.html HTTP 1.1 r n Message GET index.html HTTP 1.1 r n Request Method GET GET images logo.gif HTTP 1.1 r n Expert Info Chat Sequence GET images logo.gif HTTP 1.1 r n Message GET images logo.gif HTTP 1.1 r n Request Method GET Join me for SANS 504 Hacker Techniques, Exploits and Incident handling in San Antonio November 15th REGISTER TODAY BY CLICKING HERE

Les mots clés de la revue de presse pour cet article : wireshark
Les videos sur SecuObs pour les mots clés : wireshark
Les éléments de la revue Twitter pour les mots clé : wireshark





Les derniers articles du site "PaulDotCom" :

- Post Exploitation OS X Style
- Smartphone Attacks Overdramatized
- PaulDotCom - Security Weekly - Episode 232 - February 24th - 2010
- Bind DNS - The new Internet Kill Switch
- Episode 232 tonight with Murray Murr The keys to phishing success
- 7 ways to not get hacked by Anonymous
- PaulDotCom - Security Weekly - Episode 231 part 2 - February 17th 2011
- EXACTLY Why Your Network Needs to be Resilient Against the 0Day Threat
- Brute Forcing Passwords Part 2 with JTR, CeWL and the US Census
- PaulDotCom - Security Weekly - Episode 231 Part 1 - February 17th 2011

---

S'abonner au fil RSS global de la revue de presse

---