Lab 2 *COMPLETELY* complete

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

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… =)

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.