http://geocities.com/crewnewbie/tools/cbk.tar.gz
http://geocities.com/evikhobare/chanarybot.tar.gz

From my preliminary findings, they both contain the XHide process faker, one of them includes a remote-connect backdoor. I’d welcome any forensic insight into these, as I don’t have a whole lot of experience with doing process/machine forensics. There are still some processes running from the offending user(s), I am wary to kill anything. In the meantime I’ll be doing my own analysis and hopefully reporting on it here.

Advice? Suggestions?

EDIT: The system is a FreeBSD 6.2-RELEASE machine running on a SPARC processor.

Firstly, download the files here.
The static page for nsm-console is here.

I finally got around to releasing the next version of the nsm-console. This version incorporates a large amount of bug fixes and additional features, first, I’ll start with some of the features I’m the most happy about Most of these features are in the new Hex 1.0.2 release which came out yesterday (go download it now!)

• Categories
  • You can now toggle certain categories on and off, for instance, one category shipped with the new release is the ‘flow’ categories, you treat them just like a regular module. Simply use “toggle flow” to toggle the flow category (and all of it’s modules) on and off.
  • You can easily add your own categories to customize your work environment, all you have to do is create a file named the same name as the category name in the modules/categories directory.
• Directory analysis
  • When you normally run the nsm-console, you would specify a single pcap file to perform analysis on, now you can use the same “file” command to specify a directory full of files  instead of a single file. When the “run” command is executed, all the toggled module’s operations will be executed on each file in the directory (recursively)
  • To better accommodate this type of operation, I encourage anyone that is writing any modules to write them to output the results into an output file named something like ${PCAP_BASE}.tcpdstat.out (so if you had more than 1 file, the output will go into more than one file)
• The ‘exec’ command
  • I added the exec command because I was tired of spawning an additional shell in order to run a simple ‘tcpdump’. I hope this helps with the automation that I’m going to talk about below.

The directory functionality and the exec command isn’t in the current Hex release, but hopefully it will be in the next release.

Part of the reason I think nsm-console is neat is the ease of automation you can do using simple text files. For instance, if you created a text file called “automate.txt” and put the following lines in it:

file /pcap/data.pcap
output automated-output
toggle aimsnarf
toggle tcpdstat
toggle chaosreader
run
quit

Then, you can run the command:

./nsm < automate.txt > output.txt

Which will run all the commands in the text file automatically, placing all the output in output.txt, simple eh?

If you have any questions, comments or suggestions, feel free to leave a comment or send an email I’d love to hear if/how you’re using nsm-console

If all else fails, run “sudo find /opt/local/var/macports/build -name "wdg.*" -print” and it should print the locations of the files. NOTE: These files will only exist *after* attempting the build with macports, so attempt to build first (sudo port install ettercap-ng), and then look for the files. Hope this helps!

UPDATE:
After talking to people in IRC, I found the real root of this problem, wdg.h and wdc.h need to have #include <sys/types.h> included at the top of the file. At this time, I recommend you attempt the install using MacPorts by doing sudo port install ettercap-ng, let it fail, then go into the directory containing the macports build source, add the include into the 2 files, then run sudo port install ettercap-ng again, it will succeed and your copy of ettercap should work!

Thanks @ Raim in #macports and dmacks in #fink for helping track this down. You can see the bug here.

Original message below:

This is a continuation of the pthread error that I mentioned in a previous post

I finally got it working natively; you might be familiar with the following error when trying to compile ettercap-ng using either fink or natively:

gcc -DHAVE_CONFIG_H -I. -I. -I../../../../include -I/sw/include -O2 -funroll-loops -fomit-frame-pointer -Wall -I/sw/include -I/sw/include -I/sw/include -I/sw/include -g -O2 -c -o libwdg_a-wdg.o `test -f 'wdg.c' || echo './'`wdg.c
In file included from wdg.c:23:
./wdg.h:189: error: syntax error before 'u_char'
./wdg.h:189: warning: no semicolon at end of struct or union
./wdg.h:190: warning: type defaults to 'int' in declaration of 'border_color'
./wdg.h:190: warning: data definition has no type or storage class
./wdg.h:191: error: syntax error before 'focus_color'
./wdg.h:191: warning: type defaults to 'int' in declaration of 'focus_color'
etc etc, errors go on forever...

Well, after poking around in the code I was able to find where to fix the code so that it would compile. Open the directory src/interfaces/curses/widgets/ and edit the files wdg.c and wdg.h

Change all of the occurrences of “u_char” to “int” in these two files, you should now be able to compile without errors.

DISCLAIMER: I don’t know what kind of effect this will have on the curses interface, it will probably break the curses interface permanently, personally I use the text interface the entire time (so I run configure with --disable-gtk so I don’t have to deal with the hassle of installing the gtk/glib libraries), but at least you are able to compile, right?

I’ve tar’d up a patched version of the code and configure script (so you don’t get the pthread error). I am planning on hosting on navi.eight7.org, I will put it up and link to it when I’m able to access the machine (work firewall prevents it).

I’m still getting errors when ettercap tries to forward the packets, but I’m positive they are caused by linking to the wrong version of libnet, that has a different number of arguments to the libnet_write_raw_ipv4() function. If I get a fix I’ll post it here.

Download the script here.

Read about aimsnarf in the previous post about it.

Changes in this version:

• Trillian is now supported, as well as AOL’s AIM client. Most other clients should be supported too, I figured out the variable length/number of TLV fields in the packet, so aimsnarf is much smarter about decoding them
• Code cleaned up to be more readable
• Fixed some misc messages that were showing up, you still might see a few

Todos:

• Figure out what the heck iChat is doing, it doesn’t seem to be sending the same kind of data as all the other AIM clients
• Still do OTR stuff
• Maybe add support for different protocols?
• More testing!

If you find any bugs, send me a note or leave a comment. If you really want to help, you can send me some pcap data to analyze   If you have any feature requests, lemme know!

Okay, after reading Himanshu Dwivedi’s presentation[PDF] on iSCSI security (insecure-SCSI hur hur hur) I decided to try and replicate one of the attacks that he mentioned in the presentation. Following is how I managed to get the data shown of a different machine.

Firstly, I needed to get the initiatorname for the iscsi daemon on the target host. In this case the /etc/initiatorname.iscsi file is -rw-------, so I needed a way to find out the initiator name without root privileges. In this case I used wireshark (used to be ethereal) to sniff the traffic for a plain-text initiator name. Okay, so here’s what I did:

Fire up Wireshark (Ethereal) and set it to promiscuous mode, with a filter for port 3260 (the iscsid port), feel free to filter by host, etc. Run the live capture for a while, what you’re going to be looking for is a sequence of packets that look more like this:
…
iSCSI Login Command
TCP [PSH,ACK] <other information>
TCP [ACK] <other information>
iSCSI Login Response (Success)
…
I can’t say how long it’s going to take this, but it’s much easier to get when the iscsi service is being started on the machine you’re trying to sniff, therefore, if you can sniff while a machine is coming online from a reboot you will most likely have a much better chance of detecting this.

There’s another easier way of getting what you want just doing a string search. Search for the string “Initiator” below you can see a picture what you should be looking for in Wireshark:

Note the highlighted text at the bottom, this is what you’re looking for. Copied straight out you get something like this:
`
7LrEN@@
By"p/
InitiatorName=iqn.1987-05.com.cisco:01.87956e84f925InitiatorAlias=lava2163SessionType=DiscoveryHeaderDigest=NoneDataDigest=NoneMaxRecvDataSegmentLength=8192DefaultTime2Wait=0DefaultTime2Retain=0IFMarker=NoOFMarker=NoErrorRecoveryLevel=0X-com.cisco.PingTimeout=5X-com.cisco.sendAsyncText=YesX-com.cisco.protocol=draft20

All we really care about in that text is the part that is bolded, using this, we can manually set the /etc/initiatorname.iscsi file on a different Linux server to have the line “InitiatorName=iqn.1987-05.com.cisco:01.87956e84f925“. Don’t forget to change the /etc/iscsi.conf file to have the following line in it:
DiscoveryAddress=<ip of iscsi target host>
Fill in the host with the IP address that your sniffing showed (in this case, it was 10.5.140.229 as you can see in the picture)

After this step, if this were a real attack it would probably be a good idea to preform a DOS attack on the original target to knock it out of connection with the server (you don’t really want 2 hosts attempting to get the same information from an iSCSI target). Then start the iscsi daemon with “/etc/init.d/iscsi start” and you should be seeing the data originally meant for the other host.

This is really a simple attack and barely requires any technical knowledge of iSCSI to exploit it. It’s nothing special, but it does show that you really need to implement some kind of security in your network (CHAP or whatever else suits you).

What kind of security do you use for iSCSI? CHAP? None? Leave a comment and let me know!

EDIT: Blog O’Matty has an article on the Solaris iSCSI stack in the August issue of SysAdmin magazine if you’re interested. I find his articles to be very insightful and I highly recommend checking out some of the other ones at prefetch.net. Check it out!