1

See strings in Binaries using Notepad++

Written by Jason Kendall Wednesday, 27 July 2011 14:39

User Rating: / 1
PoorBest 

So here is a little trick I use constantly to see what strings are in a sample I'm working with. I find that sometimes it's easier to see the strings in this context rather then doing just a "strings" command.

Step 1: Open you sample in Notepad++



Step 2: Use TextFX -> TextFX Characters -> Zap all non printable characters to #



Step 3: Once all the non-printable characters are # (hash) you can remove them by doing a replace





Step 4: Profit

PHP Zip Encryption

Written by Jason Kendall Thursday, 14 July 2011 16:15

This is going to be 2 things:

1. A note pad for my notes on implementing PKWARE Zip Encryption in PHP
2. Once I get it working - a note and link to my ostlabs.com project page for the work.

So begins the notes:

1. A few twitter responses suggested Chilkat http://www.chilkatsoft.com/php.asp (Thx @hrbrmstr and @jwgoerlich)
2. Base ZIPing of a file can be found here: http://www.devco.net/code/zipfile.inc.txt
3. ZIP format details can be found here: http://www.pkware.com/documents/casestudies/APPNOTE.TXT

The following data:

In the file header section there is a "general purpose bit flag: (2 bytes)" - Bit 0 set will be encryption

Encryption details are in the same file as note 3 above - Heading: "VII. Traditional PKWARE Encryption"

Looks like the hardest part to implement will be:

Where crc32(old_crc,char) is a routine that given a CRC value and a
character, returns an updated CRC value after applying the CRC-32
algorithm described elsewhere in this document.

Sigh.

Update (July 15):

Realized that 7-Zip is open source ;) Found the code here: http://shurl.ca/a9 Files: CPP/7Zip/Crypto/ZipCrypto.cpp/.h

One of the hurdles above was the CRC32 stream update used in the PKWARE Crypto algo - A good friend of mine (@ircmaxell) took the code from 7-Zip and made the following: https://github.com/ircmaxell/PHP-CryptLib/blob/master/lib/CryptLib/Hash/CRC32.php#L100

Next stop - Crypto ;)

Holy Trinity of InfoSec Tools

Written by Jason Kendall Tuesday, 12 July 2011 09:48

User Rating: / 1
PoorBest 

So a buddy of mine and myself have been talking a lot about this concept of the Holy Trinity of Infosec. The three main technologies that you should put the most time and effort into making sure they are working as expected, and yet, seems to be the most ignored areas of Infosec because they don't have blinky lights and aren't all that shiny anymore.

Anti-Virus:

We can all agree that AV needs to change - the concept of signature based anti-virus isn't working anymore since every other day a new variant can be built, thus bypassing current detection methods. Heuristics are great, especially if they include some sort of behavioral analysis of the binary - if it's connecting outbound, listening on a port, and changing important files, probably a bad thing. However, the failure in this area is that, you can't clean something found with huristics / behavioral, because you don't know what your cleaning. Of course, given the size of your IS shop, at the very minimum a sample should be taken, an Image of the box if possible (That's the GREM in me talking), and a complete re-image should be done - I'm a firm believer in the re-image only option when malware is detected on a box. Having said all that, AV is still one of the Holy Trinity of Infosec, because that's the first stop in detecting bad things - when implemented correctly.

Vulnerability Assessment:

When talking about Vulnerability assessment, I include not only VA, but Web Application Scanning, Database Scanning, and Configuration Management/Compliance. Given today's tools, there is no reason not to be doing these things - and it should work. This really is the first defense against any attack as it *should* show you where your weakness is. Yes, the argument is that your not going to find 0-Days, or more complex vulnerabilities, but those are always going to be there anyway - You want to protect at the very least the known bad, and low hanging fruit. Let's be realistic, a lot of the attacks that's happened in the past few months have been low hanging fruit - and that's just sad on the part of the companies - I can only hope the IS department for those companies have been screaming about these issues, or the failure of their VA programs. Oh, as a side note here, if your VA takes out a firewall (which you shouldn't be scanning though anyway) that's still a vulnerability and not the fault of the VA systems - that's called a DoS, and should still be fixed by your network team.

IDS/IPS:

The one thing we all take for granted - we all expect the IDS/IPS systems to detect and/or block when someone comes a knocking. The most common problems I see when it comes to IDS: 1) Network changes happen all the time, and there is little to no communication between the IS-OPs team and the Network team to make sure coverage still exists. 2) People are still using something that was implemented 6+ years ago, was good at the time, the vendor failed to keep up with new technologies, and then your team doesn't want to out-lay the money to replace a huge investment. In both cases, it sucks. From an IDS/IPS section, I want to see the following abilities:

• Detect attempts at known vulnerabilities - This should have a high confidence rate - Its great to detect edge cases, but give it a different detection name, this separates the real attacks from the possible false positives.
• Detect Command & Control Traffic - Really, this shouldn't be that hard, IRC, HTTP, and other non-encrypted protocols, there is no excuse. Even encrypted tunnels, if it's going to a known DNS name, detect the DNS request.
• Anomaly Detection - If after 6 months of traffic, all of a sudden something is trying to connect to all other computers on the network, this should toss up red flags - it's just that simple.
• IP based reputations - We have lists of SPAMers, C&Cs, and world wide attackers, there is no reason why an IDS can't pull at least from DShield or some other reputation IP database, given enough customers, the vendor should even be able to use opt-in anonymous information from it's clients to build it's own database - I for one would consider it.

The Center:

In the center of this Triad is broken up into two parts, both are things that really isn't specific to Info Sec; Log Correlation, and Asset Management.

Log Collection and Correlation:

You should have some sort of Log Collection system, even if its a simple box that runs syslog and dumps all the logs to disk - it's hugely important not only for the Info Sec shop so you have something to analyze when things go horribly wrong during an attack, but also the IT department as a way to track issues away from a box. It's a very simple thing to implement, and really, the only outlay of money would be hard drive space. Given higher volumes then a SOHO or SMB moving into an enterprise grade tool bring Correlation to the mix which really increases the proficiency of your log analysis teams, whether it be troubleshooting or investigations.

Asset Management:

If you've listened to the Jump Bag podcast you've heard me talk about the requirement to have a good asset control system. This integrates with so much of the above and is increasing important. The biggest Challenge of any investigation or troubleshooting process is identifying what an asset does, who owns it, who supports it, and where it is. A good asset tool should be able to keep track of all of that as well as the configuration of the device from at the very least the identifying characteristics. These include, not only Asset Identifiers, Serial Numbers, Hostnames, and local IP addresses, but if it's behind a load balancer or NATing device, it should also contain any IPs and DNS names that get redirected to the boxes.

This is something I've been thinking about for a while, and I'd like comments on it - Submit them here, or find my email address and flip me one - I'd like your thoughts on this concept.

Google+ Hangout Details

Written by Jason Kendall Thursday, 30 June 2011 22:19

User Rating: / 4
PoorBest 

So one of the first things I played with when I got my Google+ was the Hangout feature - to kinda give a quick overview, it allows you and 9 others to create a room where you can see and talk using your Webcam and Mic, there is a Chat box and the options to share youtube videos. But thats not what this is about - this is about HOW it works, I'm a hacker after all ;)

So first things first, we wanted to check out the TCP connections - At first glace those are easy to see but what was interesting about it was the connections were only to Localhost - this wasn't analysed yet to see what those were for, I'm assuming it has to do with interconnects between some backend process and the web plugin.

Today, I started looking at the UDP packets, and to my surprise (After clearing out all of Skype connections) there was only ONE UDP stream, and only going to ONE IP address.
This IP has the following information:

me@server:~# nslookup 209.85.225.127
Server:         10.0.0.1
Address:        10.0.0.1#53

Non-authoritative answer:
127.225.85.209.in-addr.arpa     name = iy-in-f127.1e100.net.

Authoritative answers can be found from:
225.85.209.in-addr.arpa nameserver = ns3.google.com.
225.85.209.in-addr.arpa nameserver = ns1.google.com.
225.85.209.in-addr.arpa nameserver = ns4.google.com.
225.85.209.in-addr.arpa nameserver = ns2.google.com.
ns3.google.com  internet address = 216.239.36.10
ns1.google.com  internet address = 216.239.32.10
ns4.google.com  internet address = 216.239.38.10
ns2.google.com  internet address = 216.239.34.10

So it looks like all the Video and Audio traffic is going though the one server (in this instance)

The process handling this traffic is:

udp        0      0 10.0.0.100:50437        0.0.0.0:*                           12349/GoogleTalkPlu
udp        0      0 10.0.0.100:42549        0.0.0.0:*                           12349/GoogleTalkPlu
udp        0      0 10.0.0.100:56608        0.0.0.0:*                           12349/GoogleTalkPlu

All with the same Destination port of: 19305

Update 1:

Another interesting point is that the SERVER is sending STUN requests with the username attribute set to a random string to the client - to which the client is sending back the username and the servers "client" address.

Update 2 (Biggie):

Seems there is a little Data Leakage and infrastructure data. My client will also send out STUN requests to the server, however, when the SERVER responds - It returns an 10.13.32.10 - Safe to say, that isn't my internal, nor external IP address. This seems to suggest the servers are being load balancers and the STUN server isn't seeing MY external IP, but the internal IP of the load balancer. -- It's also reporting back a different port then any port in my captures.

Update 3:

Control and Chat are sent via encrypted XMPP - Nothing really surprising there to say the least. However, switching into YouTube mode, did not provide an XMPP event. (The Youtube request I found out is carried out by in the HTTPS stream) This XMPP server is located at 209.85.225.125 Duh, should have checked this - this turned out to be my GoogleTalk account ;)

Update 4:

Starting a new stream (and no one joined yet) - The same Server IP addresses and ports where seen. Random Client side ports are used, as expected. However, upon deeper inspection, a 4th port is used. The full list of ports used for the plugin is (New session then above):

me@server:/usr/local# netstat -anp | grep Google
tcp        0      0 127.0.0.1:50981         0.0.0.0:*               LISTEN      13116/GoogleTalkPlu
tcp        0      0 127.0.0.1:50981         127.0.0.1:53486         ESTABLISHED 13116/GoogleTalkPlu
tcp        0      0 127.0.0.1:50981         127.0.0.1:53458         ESTABLISHED 13116/GoogleTalkPlu
tcp        0      0 127.0.0.1:50981         127.0.0.1:52903         ESTABLISHED 13116/GoogleTalkPlu
udp        0      0 10.0.0.100:42102        0.0.0.0:*                           13116/GoogleTalkPlu
udp        0      0 10.0.0.100:35009        0.0.0.0:*                           13116/GoogleTalkPlu
udp        0      0 10.0.0.100:44302        0.0.0.0:*                           13116/GoogleTalkPlu
udp        0      0 10.0.0.100:36667        0.0.0.0:*                           13116/GoogleTalkPlu
unix  2      [ ]         DGRAM                    1814743  13116/GoogleTalkPlu @google-nacl-GoogleTalkPlugin
unix  3      [ ]         SEQPACKET  CONNECTED     1833112  13116/GoogleTalkPlu 
unix  3      [ ]         SEQPACKET  CONNECTED     1830401  13116/GoogleTalkPlu 
unix  3      [ ]         STREAM     CONNECTED     1790867  13116/GoogleTalkPlu 

The interesting part is the localhost connections. These connections only appear to be TCP packets with [PSH,ACK] and an [ACK] reply. There is data in the PSH packet, looks like statistics and maybe some control details. Example Data:

["jmidata","
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it
 ","c2018723930","1890",[[{"b":763553,"en":114,"fl":-1,"j":-1,"p":23916,"rtt":-1,"s":3493708127,"t":"s"}],[{"b":0,"fir":15,"fps":12,"h":360,"nack":457,"nbr":176000,"p":
t["jai","
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it
 ","c2018723930","0",["0",[]],"5"]                                                                                                                                         
n["comment","SSRC 2 render input fps: 14,12,12,12,11,13,12,12,12,12 output fps: 14,12,12,12,11,13,12,12,12,12"]                                                                                                                                               
n["comment","SSRC 2 render input fps: 14,12,12,12,12,12,12,12,12,12 output fps: 15,12,12,12,11,13,12,12,12,12"]                                                                                                                                               
["trstate","
 This e-mail address is being protected from spambots. You need JavaScript enabled to view it
 ","c2018723930",{"allWritable":true,"anyRelay":false,"anyTcp":false,"anyWritable":true,"smoothedBWRecv":229738,"smoothedBWSend":495285}]                               

So there is some FPS stats, and state date communicated via loopback in the same processes. Interesting, using GDB I caused a restart of the process - it kept the old ports open and created new threads.

Update 5:

Turning to the Binary we found these interesting strings:

received-voice.rtpdump
sent-voice.rtpdump
received-video.rtpdump
sent-video.rtpdump
application/aecdump
application/rtpdump                                                                                                                                                                                                                                         application/x-bzip
google:jingle
urn:xmpp:jingle:1
stun.l.google.com

Seems there is also some references to the GIPS codec (http://www.voip-info.org/wiki/view/GIPS) and H.264 (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC) and what appears to be ICEMediaStreams. This domain also popped up: http://www.vidyo.com/