Hydan steganography software on Ubuntu 7.04

First off, I finished the SANS 504 class, and it was one of the best security classes I have taken. And, it didn't hurt that Ed Skoudis taught the class. If you ever have a chance to take this class, I wholeheartedly recommend it. I haven't started studying for the exam, I plan on it; however the class alone was worth the money. I took it in the @Home format, which meant I got to learn from the confines of my home. Don't worry about that format. The software that facilitates the class is excellent. You hear the professor fine, see the slides that are presented, and, can interact via an online chat feature. Plus, the class is recorded, so on the off chance that you should miss one (I didn't) you could grab the audio at a later date.

7.04 laptop, and the The class recommends an XP laptop with VMWare on it so that you could run Red Hat linux for the linux portions of the class. I did 90% of the class on my UbuntuXP exercises I completed on a separate XP computer. (That went for the capture the flag game at the end, as well.) Almost all of the linux tools discussed in class were able to be fetched from the Ubuntu repositories, either from the package manager or using "sudo apt-get install...."

I was unsuccessful with one tool in particular: the Hydan steganography tool. This tool I have only found in a .tar.gz format. I downloaded the latest version, extracted it, and followed the directions in the readme. Basically, it was just cd to the hydan directory, and "sudo make." (Actually, it was just "make," but with Ubuntu I needed the sudo command.) However, I received the following errors:

cd libdisasm/src/arch/i386/libdisasm && make libdisasm
make[1]: Entering directory `/test/hydan/libdisasm/src/arch/i386/libdisasm'
gcc -I. -O3 -ggdb -c -o libdis.o libdis.c
gcc -I. -O3 -ggdb -c -o i386_invariant.o i386_invariant.c
i386_invariant.c: In function ‘disasm_invariant_modrm’:
i386_invariant.c:45: warning: incompatible implicit declaration of built-in function ‘memset’
i386_invariant.c:52: warning: incompatible implicit declaration of built-in function ‘memset’
i386_invariant.c:55: warning: incompatible implicit declaration of built-in function ‘memset’
i386_invariant.c: In function ‘disasm_invariant_decode’:
i386_invariant.c:155: warning: incompatible implicit declaration of built-in function ‘memset’
i386_invariant.c:165: warning: incompatible implicit declaration of built-in function ‘memcpy’
i386_invariant.c: In function ‘disasm_invariant’:
i386_invariant.c:233: warning: incompatible implicit declaration of built-in function ‘memcpy’
gcc -I. -O3 -ggdb -c -o vm.o vm.c
vm.c: In function ‘vm_add_regtbl_entry’:
vm.c:17: warning: incompatible implicit declaration of built-in function ‘strncpy’
gcc -I. -O3 -ggdb -c -o bastard.o bastard.c
bastard.c: In function ‘addrexp_get’:
bastard.c:22: warning: incompatible implicit declaration of built-in function ‘memcpy’
bastard.c: In function ‘addrexp_new’:
bastard.c:40: warning: incompatible implicit declaration of built-in function ‘calloc’
gcc -I. -O3 -ggdb -c -o i386.o i386.c
# make .a
ar rc libdisasm.a libdis.o i386_invariant.o vm.o bastard.o i386.o
ranlib libdisasm.a
make[1]: Leaving directory `/test/hydan/libdisasm/src/arch/i386/libdisasm'
gcc -Wall -Ilibdisasm/src/arch/i386/libdisasm -g -DVARBITS -c -o hdn_common.o hdn_common.c
In file included from hdn_common.h:12,
from hdn_common.c:9:
hydan.h:24:25: error: openssl/evp.h: No such file or directory
hdn_common.c: In function ‘hdn_disassemble_all’:
hdn_common.c:32: warning: pointer targets in assignment differ in signedness
hdn_common.c:37: warning: pointer targets in passing argument 1 of ‘x86_disasm’ differ in signedness
make: *** [hdn_common.o] Error 1

I'm not the best at interpreting the make errors. Anyone out there have any ideas? What I'm not sure is if the error is because of Ubuntu, or if there is something else wrong.

I think I'd make a lousy hacker

We're at the practical portion of the class. Last night, and tomorrow night, we're playing capture the flag. It's really pretty cool, and I've never done it before. But, I've come to the realization that I'm not that great at it. I have captured one flag so far, and I've seen a second. I admit, it was pretty cool to break into that first server and capture the flag. For a while, I had shell access to a second server; but the password I used last night doesn't seem to work today. I don't know if the password was change by someone else or what.

One thing that has been great to see, is everyone elses tools littered around the place. I've enjoyed going from directory to directory and seeing, and analyzing, the tools I've found. Many people have not even bothered to hide their tools.

The game ends tomorrow. I'll keep plugging along, but I don't have high hopes. At some point in tomorrow's class, answers will be revealed to us. I'll try them out over the weekend to see what else I can learn.

Keyloggers (continued)

Irongeek has another video up regarding keyloggers.

Webkinz, NeoPets, Club Penguin, etc. internal security

I sat down to type out a quick post questioning the security of these sites, as my youngest has been enjoying Club Penguin of late. In going through the security blogs I read, I came across the following posts:
Martin has a great post
and
Brian's post from the Washington Post.

Martin's post was along the lines of what I was going to post. But, I was going to go a step further. There are laws regarding data breaches and customer notification if there are data breaches. How do those laws impact these sites? What happens if those sites suffer a data breach. Do we get notified? It seems that every stuffed animal maker has a online site related to the animal. My kids are huge into the Webkinz. My youngest likes Club Penguin, but my oldest has moved on to UB Funkeys. They've been on Ty's Beenie Baby site if I can remember correctly. And I know my oldest has been on NeoPets; but I think that will stop for a bit.

Local school district considers security

The Board of Education for my town has a committee that was formed almost two years ago called the Tech Advisory Committee. It consists of members of the school board, the technology staff, and a few volunteer community members; most of whom have kids in the district and have some tech experience. I think there are three of us in that category now. We are steered by the Supervisor of Curriculum, Instruction, and Technology. Generally, the meetings have a few topics that the school district is interested in, and our group serves as a sounding board for those ideas. We weigh in on what we have seen in our respective companies, and we give opinions and brainstorm. A couple of projects I've seen accomplished:

• The backup process was overhauled and outsourced (to some degree) freeing up time, space, and actually saving some money.

• The school system dropped a costly T1 line and switched to Fios, saving lots of money, and not seeing any apparent degradation of service.

• We've made recommendations on architecture and technologies.

Through it all, the district has been cognizant of security and considered it in all phases of its projects. Sure, the threat vectors have been different than your typical business; but there are threats none the less. It has impressed me that the decision makers are considering security up front, and not as an afterthought; or after a major/minor incident. Can they do better? Everyone could do better, but they are light years ahead of what I see day to day.

I enjoy being part of this group, and I'm glad to see the group be effective in its mission.

WMIC update

I have since found two great articles on WMIC. They can be found:
here
and
here.

The first article is probably the best piece of documentation I have found on WMIC.