Tuesday, April 28, 2009

Lab 4.5 -- Simulated Chinese Firewall (Part Deux)

For the second part of lab 4, (lab 4.5), we are once again thwarting the simulated Chinese-firewall IDS, but this time the professor configured the IDS to detect small packets sizes. We will no longer be able to just break the offending words into very small packets and send the text file to Ta.

The first thing I did on this lab was to put myself in the sudoer’s file on Tha; we are still going to send our messages to Ta, but we will be using Tha as the staging server to send our packets. We received an e-mail from the professor that the performance on Tha was very poor, and that we should use a root shell. I decided to log-in to Tha with the root user:

# ssh root@Tha

In the second part of this lab we will be using libpcap and scapy in order to forge raw packets to Tha. I’ve never used libpcap, (a package capture program), or scapy, (used to manipulate and forge network packets), before, so I’m not completely sure of what I’m doing just yet…I‘m starting to notice a pattern with the labs at this point… ;)

I started by running sniff.py, (a tool given to us by Jong), to sniff on port 8092. (the port of my student number):

# python sniff.py eth0 tcp port 8092

I receive a message stating:

“…sniffing eth0 starting…”

…and it just hangs after that. I’m not sure if it’s actually doing anything, or if I’m using the .py file incorrectly. My SSH session would literally time-out before I would receive any feedback from the command above. I hope I’m not seriously degrading the performance of the server for everyone! Although it wouldn’t be the first time I’ve done this… :)

I’m going to e-mail the professor and make sure I’m using the tool correctly. There was another e-mail sent out that suggested we merge the sniff.py and lab4.py files in order to get the correct output from the “out.txt” file. This was also due to the degraded performance of Tha. I'm going to have to look at the code and determine how to merge the programs together.

As you can see, I really don’t have much to report on this week concerning the lab, but I hope to have it completed and have received another “Success!” response by the next blog post. I’m also still reading-up on both scapy and libpcap; that should definitely keep me busy the rest of this week.

Wednesday, April 22, 2009

Passing the "simulated" string filter censorship IDS

As stated in my last post, lab 4 simulates computer censorship by filtering certain strings from client requests, sending reset commands to both the client and the server being requested.

After Jong’s lecture, I downloaded the lab4files.tar.gz and extracted the file to access the serverv3.c code. I put the .c file on ‘Ba’ so I could test whether my python code would work before I tried it against ‘Ta’. I compiled and ran the server code with the ‘&’ switch in order to make the server run in the background so I could test my lab4.py code:

./a.out 9082 &

The ‘9082’string is the port the server will be listening on.

The code I wrote was basically the same code Jong gave us in lecture, but I broke the strings up with the ‘.replace()’ function in python:

**********************************
for l in lines:
l = l.replace("antithesis", "anti\nthesis")
l = l.replace("fundamentally", "funda\nmentally")
l = l.replace("consequence", "conse\nquence")
l = l.replace("illuminated", "illu\nminated")
l = l.replace("viewpoint", "view\npoint")
**********************************

I would search for a keyword in the string, and then replace it with a newline character in the middle of the word: “anti\nthesis” would become:

‘Anti’
‘Thesis’

Once the keyword was broken-up, I would use the ‘split()’ function and send the current string, up until the split, to the server:

L2 = l.split(‘n’)
For x in l2:
s.send(x.strip())
time.sleep(1)

This was allowing the keyword to pass to the server, and the string was re-configured on the server side in its entirety.

I ran this code on Ba, configuring my lab4.py code to connect via the local host:

s.connect(("127.0.0.1", 9082))

After running my lab4.py code I received a ‘success’ response from the server; this tells me the strings are being broken-up and re-configured correctly...but would it work on ‘Ta’ ???

I ran my code from Alef to the server running the simulated censorship and received another ‘success’ response from the server:

[tjcdeba@Alef ~]$ python lab4_code.py
"What is Prof. Crandall (a.k.a. Jed, a.k.a. J-Dub, whatever you prefer)'s favorite Von Clausewitz quote?\nSuccess!\n"

Looks like lab 4 is done…on to lab 4.5!

Wednesday, April 15, 2009

Lab 4 beginnings -- and a test coming up...

With labs 2 and 3 done,

** I probably could have done more with lab 3; I could have explored NMAP more thoroughly and maybe discovered other ports/exploits using different scans and techniques, but I’m happy I found the four machines on the sub-net configured by the professor.

I’m now concentrating on lab 4 and the test coming up this Friday (4/17). The test is going to be pretty hard, I think, with a lot of references to information from Homework #2. Thankfully it’s open-book/open-notes so I’ll be able to bring a lot of information and references from the web and from the book. I’ve re-done Homework #2 and I’m still a little shaky on filling out a transitive closure matrix. I’m going to re-read chapters 16 and 17, and I’m also going to read chapter 32 (It’s only 5 pages so it shouldn’t take too long).

For lab #4 we’re trying to overcome a simulated Chinese fire-wall scenario: the professor has configured a router that is simulating the way the Chinese government is, (sort of), censoring internet traffic into and out of the country by filtering words or phrases, and then sending reset packets to both the sender and the destination.

We had a very good lecture today, (4/15), on the technology of the Chinese firewall scenario by Jong Chun Park. He laid-out the scenario we would be facing in lab 4, and he gave pretty good instructions on how to over-come the censorship by “sending a sequence of packets which split the keywords.” He even gave us some python code in order to accomplish this:

import socket # client
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((“10.0.0.3”, 8080))
s.send(“hello”)
d=s.recv(1024)
print repr(d)
s.close()

He also stated that the censorship algorithm that’s employed here is not an actual Intrusion Detection System, but rather an iptable filter. I’m going to be working on lab 4 this weekend, and I don’t believe it should be too hard (I think Jong and the professor have pretty much done most of the heavy lifting on this one).

At this point I don’t really have that much to report on lab 4, I’m just trying to get everything together for the test and then I’ll be able to concentrate on the lab. I added myself as a sudoer on Tha, and I've downloaded the lab4 files from the class website. Other than that, I haven't really accomplished much on this lab. Oh, and I guess I should learn a little bit about python as well… =)

Wednesday, April 8, 2009

Come out, come out wherever you are....

For this week’s post I’m continuing to focus on my NMAP scans on the University’s virtual environment set up by the professor.

As stated last week I found a machine on IP: 192.168.33.2 with port 22 open using:

sudo nmap -n --scan-delay 1s -vvv -PN -p22 192.168.33.2-100

Wanting to investigate this machine further, I performed an OS scan using:

sudo nmap -PN -A 192.168.33.2

This revealed:
Running (JUST GUESSING) : FreeBSD 5.x|6.X (90%)
Aggressive OS guesses: FreeBSD 5.4 or 5.5 (x86) (90%), FreeBSD 6.1-RELEASE through 6.2-BETA3 (x86) (88%), FreeNAS 0.671 (runs FreeBSD 6.1-STABLE) (87%)

Earlier in the week I found a machine with port 80 open using:

sudo nmap -n --scan-delay 1s -vvv -PN -p80 192.168.33.2-100

But, another scan this evening, (at around 7:56pm), did not reveal any machines with port 80 open. This may be due to packet loss though we’ve been informed that the web server is not very stable so it may be down at the moment. I'm not completely convinced this is due to packet loss because a ‘w’ command reveals only about 8 other scans being performed at the moment.

We were informed that there is “probably” at least one windows machine on the network, so I decided to search for it with the command:

sudo nmap -n --scan-delay 1s -vvv -PN -p135,139,445 192.168.33.2-100


NMAP returned with:
Host: 192.168.33.40 () Ports: 135/open/tcp//msrpc///, 139/open/tcp//netbios-ss\
n///, 445/open/tcp//microsoft-ds///

The 135 open TCP port tells me this is *probably* a windows machine.

After running:
Sudo nmap –n –PN –A 192.168.33.40

NMAP returned with:
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
Device type: general purpose
Running (JUST GUESSING) : Microsoft Windows 2000|2003|XP (98%)
Aggressive OS guesses: Microsoft Windows 2000 SP4 (98%), Microsoft Windows Server 2003 Enterprise Edition 64-Bit SP1 (95%), Microsoft Windows 2000 Server SP4 (94%), Microsoft Windows XP SP2 (94%), Microsoft Windows XP SP2 (firewall disabled) (94%), Microsoft Windows 2000 SP3 (92%), Microsoft Windows 2000, SP0, SP1, or SP2 (92%), Microsoft Windows 2003 Server SP1 (91%)
Service Info: OS: Windows

After learning from other students in the class, (and from the professor), that there are 4 machines on the subnet, I decided to perform additional scans to try and locate the 4th machine. Another student in the class tipped me off that I should try scans other than SYN scans…so, after performing FIN,Xmas tree and Null scans, I found:

Host 192.168.33.22 appears to be up ... good.
Interesting ports on 192.168.33.22:
Not shown: 1694 closed ports
PORT STATE SERVICE
22/tcp open|filtered ssh
80/tcp open|filtered http
111/tcp open|filtered rpcbind

At this point I *believe* I’ve located everything on the subnet, though I’m going to continue scanning with different switches to see if anything else pops up. I’m also really enjoying using nmap, I think I’ll use it at work just to see what I can find….just kidding, of course =)

Wednesday, April 1, 2009

Who? What? Where? -NMAP- it is then….

For lab this week we are to use NMAP to discover machines, ports, and services on a subnet configured by the professor. The professor has put several machines running different services on a number of ports and we are to find out all we can about the machines on the subnet. This lab can only be done if the previous lab, (lab 2, the buffer-overflow attack), was completed because you needed to have root privileges on Ba. This is the first time I’ve ever used NMAP, and at this point there are so many things you can do with it that I haven’t even really scratched the surface yet. I began by reading a few of the MAN pages on NMAP, as well as some Google searching to begin understanding the tools I would need in order to complete this lab.

In the beginning things have been kind of slow because there are so many people doing scans that I would imagine there is a high probability of major packet loss. I ran the ‘w’ command from the terminal on Ba and noticed that there were 17 people on the server, and they were most likely scanning the subnet as well:



I found that port 22 (SSH) was open on IP: 192.168.33.2, so I directed an OS scan on that machine with the command:

‘Sudo nmap –n –PN –A 192.168.33.2’

I put the results of this scan into a log file, and it determined that machine was running FreeBSD 5.4 or 5.5 (x86) , though the scan was (89%) sure that this was the correct OS and version number. I’m still doing some scans on the subnet, but it’s taking quite a while and I need to have this blog post up by 12:00a.m. (it’s 10:00p.m. now, so I’ll probably have a few more scans complete in the next couple of hours).

I did notice something kind of funny when I was attempting to scan for ALL OS’s on the subnet, (Yea, I know, not a smart thing to do with so much traffic on the server); I got kicked off the server for “exceeding my allowed time on the server.”



I’m not sure what this really means because the scan was only running for about 30 minutes. Maybe the professor has some kind of time-elapse method that will stop your scan after a set time period; this is just a guess, I have no idea if it’s correct. This also taught me that I need to do more directed scans and not have such a broad view of the task.

At this point I haven’t been able to answer all of the questions for the lab just yet, but I hope to by the next blog post. It’s taking a while to actually filter through the data and mine it for the information I’m looking for. As I stated before, I haven’t had very much experience with NMAP, so I’m still wading my way through the process.

…and the battle continues….

Wednesday, March 25, 2009

Lab 2 *COMPLETELY* complete





Look for username tjcdeba in /etc/sudoers on Ba...and here's a screen shot just in case... =)

Wednesday, March 11, 2009

Oh sweet success!!!

Tonight was the first full night I was able to completely concentrate on Lab 2, and, surprisingly I was able to accomplish what I wanted to accomplish. With a little insight from the professor and a little clarification from another class member, I was able to put the pieces together to correctly complete the lab.

This lab was a buffer-overflow exploit, executed from one virtual server to another. The lab instructions were pretty thorough, and there were even some hidden hints in the code that allowed me to complete this lab. I was able to exploit an integer overflow vulnerability and gain root access to one of the virtual servers I didn’t normally have access to. Most of the code was written by the professor, so there were basically some “fill-in-the-blanks” for the students to accomplish in order to gain elevated privileges on the server running the vulnerable code.
From looking at the serverv2.c code, I noticed that there was a short unsigned int; this is where I focused my attack. From the server dump, I was able to get the memory address of the integer.

I was excited that I was able to follow most of the code, (I’m just now taking my first class in C, and I have not yet taken 341, which is a class on assembly), and disseminate what I was supposed to do in order to complete the lab. I was stuck for the longest time on one aspect of the code: we were to get a “magic number” that was an unsigned short int, which is then interpreted as a signed int, and then as executable code. It took me a while to figure out that the argument to the ‘printf’ statement was being fed into the vulnerable server code to execute our over-flow attack; this was the jump point to inject our malicious code. Once I realized this was the integer value of the JMP ESP in x86 machine code…I was able to exploit the vulnerability on the server and gain root access.

At this point I haven’t been able to update the sudoers file; I get an error that it’s busy and to try again later; I’m assuming someone else was updating it at the time. It has been locked out for quite a while, so I’m not sure if there is an issue with the file.

Overall I thought this was a fun lab, and considering the extreme failure on lab 1, I’m happy that this lab turned out differently. I’m also relieved that this was done before spring break!!! It’s miller time!!! Ok, maybe not for someone that has a full-time job and no real spring-break from work… =)

Wednesday, March 4, 2009

In my humble opionion regarding computer security...

In my opinion, there are several fundamental issues regarding computer security. One such issue is that systems are not updated as often as they should be in order to make code more secure against certain types of attacks. Because many popular programs are written in C and C++, it is only natural that exploits such as buffer overflows are a favorite among individuals trying to gain access to systems illegally; C and C++ provide no built-in protection against accessing or overwriting data in any part of memory. C and C++ do not check that data written to an array is within the boundaries of that array. It is also common knowledge that an attack such as a buffer overflow is very easy to execute on many platforms. In his article: Smashing The Stack For Fun And Profit , Aleph One gives step-by-step instructions on how to do a buffer-overflow attack.

I believe this is another fundamental issue regarding computer security: information is very readily available and is written in such a manner that anybody with medium-to-advanced computer knowledge can write a little code and gain access to information they shouldn’t have access to. With information on phreaking, double free() exploits and heap overflows being readily available to anyone over the internet, it is an absolute necessity for system and program engineers to be diligent in creating secure environments that can be more easily updated/modified to combat the growing number of individuals attempting to gain access to the information contained within these structures.

My last example of a fundamental issue regarding computer security is the storage of sensitive data with data that may be accessed by a larger pool of individuals with a lower need-to-know than that of the sensitive data. As an example, I work for a group that separates sensitive information from other, non-sensitive information by maintaining entire separate networks for each. There are even directives in place to specify cable separation between the two networks; cables going from one network must be a specific distance from cables going to the other network; this is to prevent cross-talk through the Ethernet cables. I believe that it’s a common practice to mix both sensitive and non-sensitive data in work environments because of convenience and cost effectiveness; it’s easier and cheaper to have one server with all of the company’s information, even though it puts the company’s sensitive data at risk. As an example, an individual running an attack on a company’s website can possibly gain access to sensitive personnel information if it’s stored on the same server. A better solution would be to have a local intranet that’s not accessible from the outside world to store sensitive information. The downside is that this type of setup can be expensive and inconvenient for employees.

In conclusion I don’t believe there are easy answers to any of the fundamental issues regarding computer security. I believe there must be a balance between convenience, cost and security, with security being the major factor in determining how a system is designed and maintained. I also believe that system maintenance and data separation are not practiced nearly enough by companies and individuals alike.

Wednesday, February 25, 2009

Goodbye lab 1, hello Lab 0

After the heartbreak of missing our opportunity to get some dandelion wine, and not being able to break the cipher given to us by the professor, I've decided to drown my woes in Lab 0.
We are to pick two puzzles by Matt Bishop and answer the questions; one has to be about an ethics issue.
For my first pick I chose the puzzle regarding a student that discovers a security flaw in the department's computer system. The student exploited the flaw and gained root access on the machine. The puzzle goes on to explain that the system did not provide sufficient mechanisms to prevent the student from gaining root access. The question is whether she actually "broke in" to the system, and if she actually acted unethically in exploiting the flaw in the departments security.
I believe this was a breach of ethics because the first paragraph states the student "exploited a flaw" in the system to gain root access; this does constitute a violation of ethics by the student because she gained access by means not usually used on the system. The student, after discovering the flaw, should have reported the issue to the correct personnel, and offered suggestions to fix it. In my own personal experience I believe this should be the default action when any security flaw is detected. If I were to exploit a security flaw I discovered on the network at my current employer without informing the proper personnel, I would not only be subject for dismissal, but I could also be brought up on charges by the United States government. I’m not completely sure the chairperson acted ethically; the student did bring a glaring security issue to the attention of the University. In my opinion, the student should have been reprimanded for her actions, and made to sign a waiver stating she would never again knowingly exploit a security flaw on the University’s network.
My second blog is regarding two MIT graduate students that bought a number of hard drives from the Internet, and were able to recover data on the drives.
The question is if the data being discarded on the disks is actually a security vulnerability. I believe it could be depending on who the drives belonged to. If this was an employee that stole the drives from their employer, and decided to make extra money by selling them on Ebay, then this could be a very big vulnerability. The drives could consist of personal employee information, or industry secrets. If this was just someone believing that the “delete” command actually removes the data, than I believe that person should gain more knowledge on computing systems before putting any kind of sensitive information on one. There has to be a level of personal accountability for situations such as these. If it’s a person putting his own old drives on Ebay, he should definitely verify they have been completely wiped with a utility such as BCWipe, or any other utility that will over-write each sector of a hard drive.
I can once again point to my own experiences to illustrate a point regarding this puzzle. Once a computing system comes into my work, the hard drive remains the property of my employer indefinitely. If there needs to be warranty work done on the machine, it is done without the hard drive (and in some instances without RAM as well). Discarded or defective drives are wiped, using a system that writes a ‘0’ to every sector on the hard drive, and the drive is destroyed. While that may seem kind of extreme, it will definitely prevent the spread of sensitive information.

Wednesday, February 18, 2009

Is the wine slipping away??? ...not sure..stay tuned

The team unfortunately didn’t get as much figured out this week as I’d hoped; though some progress was made. John and I were able to meet on Sunday evening and continued working on our algorithm, but we really wanted to get together with Jonathan and Ben to make sure we’re all on the same page. We haven’t been able to meet with Jonathan yet, (he just got into the class full time because of work constraints), but John and I did meet with Ben Lawry this evening. After we got up to speed on where we are in the project, we continued formulating our algorithm and writing code in order to brute-force K3; this is the obvious first-step in finding the key, and the one we’ve known about for a while now.
I received an e-mail from diabloo71@yahoo.com, which broke down his algorithm for breaking K3 and his, proposed, steps for continuing up the feistel structure to get K1 and K2. We compared his pseudo code to our own and I *THINK* we’re on the right track; we seem to have the same basic technique to solve the problem. We did receive new S-Boxes from the professor this evening, and they appear to be more linear and, in his opinion, easier to crack. We'll hopefully be able to confirm this when running our *working* code on the plaintext/ciphertext pairs...but I give no guarantees.
John and I did discuss the lab briefly at work today, and John made a comment that we should get threads on one of our work’s super computers in order to brute-force the entire structure…maybe not a bad idea when your employer has two of the top-10 super computers in the world. =)
We came to the conclusion that this would probably be too expensive and we probably wouldn’t even be able to run our code on the machines. Oh well….it was an idea.
Code is now being written on my laptop, which now has Fedora core 10 64-bit on it. I put the code on my personal laptop because I can now take it anywhere with me; I won’t have to find somewhere to SSH into UNM anymore. I aptly named the file: “rubberHose.cpp” for obvious reasons. I’d be lying if I said that I’m not getting a little pessimistic about actually completing the lab, but I’m sure quite a few others in the class are feeling the same way right about now. I’m going spend a great-deal more time on the project this weekend, and I’m now anxiously awaiting version 3 from the professor. ;)

Wednesday, February 11, 2009

I haven’t gotten very far with Lab #1. I’m really still trying to grok all of the information presented in class, which is extensive. I’ve read several postings and pages from the class e-mail list, and I *THINK* I’m starting to see where I should begin. The: “A Tutorial on Linear and Differential Cryptanalysis” paper was especially helpful. The link can be found here: http://www.engr.mun.ca/~howard/PAPERS/ldc_tutorial.pdf

I downloaded the sdes16.cc code from Professor Crandall’s website, but, it wouldn’t correctly compile on my Linux box; I get a compiler error that states: -- integer constant is too large for ‘long’ type --. This is probably due to me having a 32-bit version of Ubuntu running on my laptop; I should probably upgrade to 64-bit. I did, however, get the linear.cpp and pc.cpp to correctly compile and run. I’ve been going through the code the last few evenings and have begun writing a rough algorithm for my own implementation of Professor Crandall’s modified 16-bit SDES program. The Professor is allowing us to work in groups, so I’ve teamed-up with two colleagues from work that are also taking the class: John Montoya and Jonathan Mandeville. Jonathan has an extensive background in computer security and has a lot more experience with encryption than me or John. John is a CE major with extensive hardware and some C++ experience, and I’m a junior in the CS department with experience in several languages; this should be a good pairing. We’re going to be getting together this weekend or early next week and compare notes and algorithms so we’ll know what each of us thinks should be the direction to take to solve this lab.

We’re determined to get the wine….

Monday, February 2, 2009

RCR Course for class

I completed the RCR course entitled: "CITI Physical Sciences and engineering RCR Course For The Unaffiliated Learner". While most of the information presented had little bearing on cyber-ethics, I think a couple of points are very valid.

The first part of the course focuses on reasearch misconduct. The goal is to make the reader understand that if the researcher cannot be trusted, then the research results may be invalid. I can understand how this could be relevant to cyber ethics because if an individual embellishes his findings, his entire collection procedures and his reputation can be tarnished. If this were a criminal case involving specific information removed from an individuals hard drive, the information can be thrown out of court and the accused may walk; this is especially important in a cyber-forensics case. This module also discussed the importance of data storage; the "data must be stored in a safe and secure manner during and after the conclusion of the research project."

I also liked the module that discussed the importance of how "scientists balance the free exchange of some sensitive scientific data and information with the possibility that a terrorist or other threat to national security might use the material."

I think this is a very important point regarding computer security and computer forensics. It has been demonstrated that some scientists believe the value of their work transcends security: they will actively share information and specific data about their projects without regards to the sensitive nature of their work. The data obtained in the research is important, but oftentimes the methods used to obtain the data is as, or more, important than the data itself; this was painfully evident during the Manhattan Project. I believe this can be a key issue regarding cyber ethics in this class: the students taking part in this class should not only refrain from using the tools and skills obtained outside of the controlled environment of the class, but should also not publicly discuss their research or data-gathering methods with individuals not in the class.

In my opinion I don't think there was as much of a focus on ethical issues as it relates to computing environments; the modules appeared to focus on ethics and honesty in more of a lab structure. I would recommend either a different course, or possibly a guest-speaker with specific examples of how individuals did not make good ethical choices regarding some of the tools or information we will be learning about this semester, and the consequences of those choices.

Wednesday, January 21, 2009

Day 1 -- Nothing to report!

This is my first blog...umm....ever.....

This blog will eventually be filled with information regarding a CS class I'm taking at the University of New Mexico. I've been very interested in computer security, and my current job centers around it. I'm hoping to get a lot out of this class to further both my academic and actual careers.