Sunday, October 18, 2009

Quick shell script to extract the contents of an image

- assuming TSK is installed, the image "image.dd" is in the local directory, and a directory "files" exists for the extracts. Change the offset and disk type to suit. This particular image was a 1GB FAT16 USB drive image.

# for i in `fls -Dr -m / -f fat -o 63 image.dd | grep -v ".Trash" | grep -v "(deleted)" | cut -f 2 -d"|"`; do mkdir files/$i; done

# for i in `fls -Fr -m / -f fat -o 63 image.dd | grep -v ".Trash" | grep -v "(deleted)" | cut -d "|" -f 2,4`; do echo $i; icat -o 63 -f fat image.dd `echo $i | cut -d "|" -f 2` > files/`echo $i | cut -d "|" -f 1`; done

Monday, May 4, 2009

Idea for enterprise scanning

Pseudocode for an internal scanner. Attempts to combat environmental manipulation through self-integrity checking, but a better mechanism may be needed.

Assumed this operates in a client/server model with the server offering messages to clients in a one-to-many or several-to-many relationship. Ulitmately, the server should be able to post a request (hash list, updated files) and the clients should pull the list, self check, perform the tests, and report back. The central system should them be able to generate reports based on the results.

INteresting reports might include which scanned successfully, which didn't report, any anomalies discovered. All hashes are passed back to central, so the tool could be used for forensic anomalies, known discovery of artifacts, discovery of similar artifacts within a defined threshhold, or compliance applications (similarity or direct matching). The insider threat model could be integrated by allowing the tracking of defined critical documents within reporting systems.

Client structure follows:

internal scanner

pull updates and signatures. check sig, decode to mem, load hashes

provide non-DOM driver to access disk filesystem - driver client bindings
provide access to memory - Volatility

check self integrity of all components, static files
Walk VAD and dump all processes/dll injects to disk
identify self in proc dump and validate hash vice known

dump registry hives in memory
extract registry values for known hostiles - regripper

for each proc/file
perform static hash scanning >> hashfile
perform context piecewise hashing >> cphfile

compile xml/soap response
encrypt, sign, report back to central


Needed tools:

http://code.google.com/p/pyssdeep/
http://www.py2exe.org/
https://www.volatilesystems.com/default/volatility
http://www.regripper.net/
http://ssdeep.sourceforge.net/
http://www.indigostar.com/perl2exe.htm

Friday, May 1, 2009

Opinion on SMTP Honeypots

honeyd is an infrastructure honeypot that refers to other services. it's a little heavy. If you are trying to emulate the Interweb on an open access point for research, it's great. For this, you want something more focused, either a honeytrapd type of service (dangerous on your border) or a full-time script running in its own process(s) to capture and handle load. Look at truman's (http://www.secureworks.com/research/tools/truman.html) smtp script and consider reversing it's interally-focused intent to external. Add some support scripts for housekeeping and you should be good to go. Obviously, run in a dmz, with limited perms, on a box that is easily rebuilt and doesn't have other dependent, critical apps/processes. VM should be fine.



On Tue, Apr 28, 2009 at 12:28 PM, private investigation <xxx> wrote:
I tried to use honeyd but seems that honeyd cannot handle much of smtp request

So You Thought You Were in Control of Your Friend List

Check this tool out! Facebook Controller:

http://my.opera.com/quakerdoomer/blog/2009/04/30/fbcontroller-facebook-controller-the-ultimate-facebook-controller-without-the-pa

Nice, using social media against you to subvert authentication controls, do recon, and manipulate data. Great POC!

SSH Command Monitoring

This was an interesting post from the secureshell list. Thanks Richard!


Hi "J",

you can do that with your unix/linux onboard tools. just attach strace
to the sshd process of the user you want to monitor:

strace -s 4096 -e trace=read -p PROCESS_ID

than have a look for the shell prompt (e.g.):

read(10, "\33]0;USERNAME@HOSTNAME:~\7".
.., 16384) = 22

now you know that the FD (file handle) is 10 for the users ssh session terminal.

then you can do something like that:

strace -s 4096 -e trace=read -p 10417 2>&1 | grep -E '^read\(10,' |
grep -oE '".+"'

and you should get an output like:

"uname -a"
"\r\n"
"Linux HOSTNAME 2.6.29.1 #1 SMP Sat Apr 18 11:22:05 CEST 2009 i686
Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz GenuineIntel GNU/Linux\r\n"
"\33]0;USERNAME@HOSTNAME:~\7"


well, this will only work if you have root permission on the server
running sshd.


have fun,
richard

Saturday, April 18, 2009

Open Source Security Information Manager - OSSIM

I've been playing with OSSIM (http://www.ossim.net) for the last week. The stand-alone installation from AlienVault was trivially easy, thanks guys! I was able to install a main 'trusted net' stand-alone and integrate a DMZ sub-sensor in an hour. The dashboard is pretty, with many reporting features and does a decent job of aggregating the infeed of data from the wide collection of tools it provides.

But...

Having put this Unified Threat Management (http://en.wikipedia.org/wiki/Unified_Threat_Management) device on the network, I find it to be the least secure thing out there. While AlienVault did an excellent job of bringing all of these wonderful security monitoring tools together, having the production interface on the main network acting as both collector, sensor, and admin access is a bad idea. It also uses so many products and services that it is terribly insecure itself. Having the main sensor in the trusted network isn't too bad for this, but having one of these in the more exposed DMZ makes me wary. OSSIM needs a lot of custom configuration to implement restricted access, split the collection interface to a promiscuous-only and have a separate admin interface. This can be done with taps to ensure only one-way traffic occurs, but that still leaves the service open to injection if one were to expect the box to be there. In all, the UTM sensor-with-everything idea needs to be rethought.

It's been fun to play with, but ultimately I'm going to explore running with some functionalized implementations that might prove more secure.

Tuesday, March 3, 2009

Suggestions for Security Training

I respond to questions from time to time about a recommend security training pipeline for SOC operators at all levels. Here is the general recommendation I've developed.

(Jr Sec Analyst) Year 1 goals
- Security +
- GCIH

(Sr Sec Analyst) Year 2 goals
- begin CISSP study (reading, not a bootcamp yet)
- GCFA if doing investigations
- or GCIA if focused more on network management of IPS

(Sec Engineer/ Sr Sec Analyst, Principal) Year 3 goals
- CISSP course and testing
- GREM if moving toward malware investigation
- OR GPEN if moving toward software assurance (recommend GCIA prereq)
- begin local research projects and security defense-in-depth expansion through pilots

(Sec Architect) Year 4 goals
- CISSP/ISSEP certification
- additional SANS courses
- demonstrated local research and expansion projects

I choose to emphasize the CISSP over other equivalent certifications (CISA/CISM) becuase of its better ROI in the DOD8570.01M requirements structure. Any employee you are going to have in government service that you plan to invest in for more than a year, you should pursue this certification to maintain compliance and competitiveness. Not that it gets you knowledge without having equivalent experience, but it's a marker you have to have.

I have also chosen to emphasize SANS training as they are considered an industry gold-standard, are vendor neutral, and teach underlying concepts in addition to applied practices. Their courses are not a college degree or an 'academic' environment, but it is good training for directly applicable skills.

I think Rob Fuller has an interesting perspective at his Room362 blog entry on security credentials.

Wednesday, February 25, 2009

Deobfuscating the Adobe 0-day

The folloiwng is a quick writeup of an analysis started on a PDF sample for the Adobe7/9 0-day. The exploit starts with an overflow, then attempts to run the javascript to drop a file c:/adobe.exe and execute it.

hexdump -C file.pdf > HEXDUMP_file.pdf.txt
less HEXDUMP_file.pdf.txt
[find the javascript near the end]

0x80301 - 525057 start of javascript exploit
0x821c8 - 532936 end of javascript exploit
=======
7879 - difference in decimal

Carve the javascript out.
dd if=file.pdf of=file.pdf.js.carve bs=1 skip=525086 count=7849

Add some stubs to cover for lack of spidermonkey functions. Not quite there, but gives the idea.

function document(){
this.write=printit;
}

var document=new document();

function address(){
this.length=0;
this.substring="";
}
var address=new address();
function nop(){
this.substring="";
}
var nop=new nop();
function jmp(){
this.length=0;
}
var jmp=new jmp();
function pointers(){
this.length=0;
this.substring="";
}
var pointers=new pointers();
function pointers1(){
this.length=0;
}
var pointers1=new pointers1();

Run and see if it prints the deobfuscated output.

./js 1.js
bt collectedfiles # ../scripts/js.sh 1.js
var address = unescape(r)
var jmp = unescape(r)
var nop = unescape(r)
var nop1 = unescape(r)
var shellcode = unescape(r)
1.js:84: TypeError: nop.substring is not a function

Only a few lines before a function missing. No luck this time, but its close. Keep playing.