Week 1

After attempting to use a number of different blog programs (Gatsby, jekyll, ghost), I finally found one that was pretty painless to setup and even integrates with github pages! I’m currently using Hexo which I had never heard of before but has over 26k stars on github. Very cool. It’s all written with markdown and it’s trivial to create new posts and publish. Anyway enough about my setup, let’s get started.

Learnings

Windows

It was immediately apparent that a fair amount of the class would be using the Windows environment. I’m pretty unproficient when it comes to the windows terminal, but I googled around and found powershell was installed on the windows VMs for the class! Although not completely similar to the unix shell, programs like ls and cd make it feel a bit more like home.

Tooling

I really enjoyed getting comfortable with the tools, specifically fakenet became a pretty handy tool to see what the network traffic looked like during the attack. I was pretty confused for hours about why a the fakenet html page kept ending up in my computers /etc/hosts file. I slept on it and the next day I suddenly realized this was fakenets response to a request. This meant that the virus was attempting to request something on the network and add it to my local etc/hosts file.

It’s moments like the above that have me really excited about this class. I very much enjoy the problem solving aspect .

Another tool I found really useful was the antispy program. From an untrained perspective, it seems to be a compendium of generally useful information about the currently running processes, registries and open files. I found this tool to be incredibly useful when analyzing a evil.exe, especially pulling the strings from the program itself! From the strings information, we can see things like file names that the program was targetting and investigate those files directly.

The windows explorer I found to be pretty useful too, as it allows you to sort by date modified. If a the virus modifies a file it will likely show up as changed here, however I have no doubt there are ways for a hacker to sneakily hide the fact that a program was modified.

One tool I was not able to get any utility out of was the attrib tool. I will continue to poke around with this tool on the next lab, but every time I would try to use it, I got a blank response.

Capturing Transient Files

I couldn’t easily capture some files as they would create and delete themselves. I could see them perhaps pop up quickly on the process explorer but then they would disappear as they were deleted. I decided to write my own python script to capture these files when they appeared. The pseudocode went roughly like this

    define files to watch
    create temp directory
    while true
        for each file to watch
            if file exists
                log found
                copy it to temp direcotry                
                remove file from files to watch

I would run this program alongside the virus and it would capture the transient files qiute well. This program is simplistic though, as it wouldn’t have captured different stages of files if for instance any one of the files to capture was added to after its creation. I think for this next assignment, I’ll try and find a program that can do this for me more elegantly.

Overall Takeaways

The biggest takeaway for me this week is that virus and worms often do not have a single strategy of attack. For instance, it would appear that the sample from this week had the IE exploit as well as a directy UDP connection backdoor attempt. Robert Morris’ worm had three different programatic attacks and would then fall back to a password dictionary attack. My point is, next analysis I’ll be on the lookout for the bigger picture to contain most likely more than one avenue of evil.

Also, we have access to a linux VM on VSphere so I’m excited to perhaps analyze a virus/worm specific to a Linux environment at some point!

The Morris Worm

In lecture, the Morris Worm was referred to in a way that made it seem like most people had heard of it and know it’s history and nature. Well I certainly had no idea and was very interested to learn! I set out to read more about it and stumbled upon a video series from SourceFire called Chalk Talks. In the short series, the narrator goes over a brief history of Robert Morris the man, and then delves more deeply into the behavior of the worm.

The information for this section was gathered from the Chalk Talk Series as well as The Morris Worm Wiki and an article found on the University of Utah cs site about the worm by Donn Seeley.

Robert Morris was a graduate student at Cornell University who decided to experiment with some explitations he had found out about in the Unix system, namely fingerd, sendmail and rsh/rexec. He released the worm and a mere two days later, the video reports that roughly a tenth of the computers connected to the internet slowed down to a point where they became basically unusable. The worm would copy itself onto other computers and analyze whether a copy of itself was already running or not. If it found a running copy, it would randomly terminate itself or the copy. However, 1 in 7 times, it would keep both copies running and continue trying to replicate itself onto other computers. It was this behavior that resulted in the worm being harmful, as some computers became so bogged down with worm processes that they couldn’t function on other tasks.

Robert Morris was convicted of felony “Internet Fraud” and was billed a whopping 10k (that’s a lot of money now, but that was a LOT of money back in 1988!). He didn’t serve any time, but he did get probation and community service. He had a pretty successful career after, participated in founding a few companies like Y Combinator and is currently a tenured professor of Computer Science at MIT. He claims his worm was never intended to be malicious.

I found the finger exploit to be particularly clever and fascinating. The gets function reads bytes from a stream and stuffs them into a buffer. The finger daemon expects the finger client to send it a usename to request data about. Morris found out if he were to send a username longer than was intended (512 bytes) he could fill the gets string buffer, however gets would keep writing and end up writing to the file system. He was able to exploit this behavior in such a way as to trick the computer into returning from the gets program to a different byte address and it would then execute the sh program with a socket connected to the infected computer.

Now that the finger client has a direct socket connection to a running sh program on the fingerd server computer, it would send a copy of itself via the socket, then request that the copy be run on the new computer.

The worm had three different attacks: rsh/rexec, the finger exploit above and sendmail.

The rsh attack banked on the idea that the current user might have the same account and password on a connected remote host. Morris exploited the fact that users often dont want to remember multiple passwords so the tendency is for users to use the same username/password multiple times. If this failed, he would fall back to the finger attack. If the finger attack failed, the worm would fall back finally to a sendmail exploit.

The sendmail exploit was exploits a loophole in the way sendmail is commonly compiled. When compiled with the DEBUG flag, a client is (was?) able to send commands as a username that could be run on the receiving machine. THe worm would easily enough establish that the sendmail server was compiled with the DEBUG flag, then send a bootstrap copy of itself which it would compile and wait for a connection to fully create the worm.

The worm also had a second routine to infect computers involving a dictionary attach and exploiting simple user passwords, however my favorite attack is still the finger attack and exploit.

There are arguments on both sides that the worm was malicious or not. It didn’t delete files but it did however replicate quite quickly. 1 in 7 is not a realistic attempt to control the spread of the worm, and could be seen as a mere attempt to avoid instantaneous symptoms of infection. On the other hand, it has been noted that there are pretty basic coding errors that were found in the code, so the population control could have been yet another error or oversight.

Next Week

I hope to take some time to learn about the Stuxnet virus that was mentioned in lecture (as well as highlight some interesting points from the weeks material).