Willie Stehm 1st Quarter

Ten Goals for First Quarter

1) Set up test lab using a minimum of three computers connect to a hub or switch [X]

2) Research and use packet sniffers to intercept packets sent by other computers through the network [X]

3) Research and document findings on how to crack password hashes [X]

4) Research general email security [X]

5) Intercept Gmail Log-in information to analyze [X]

• SHA hash function
• RSA Encryption

6) Intercept Gmail Chat messages through wireshark [X]

7) Attempt to intercept normal emails sent through gmail [X]

8) Make necessary cat5e cables to connect firewall to test lab and APS network [X]

9) Set up Firewall for our test lab [X]

• Research firewall operating systems

• IP Cop

• Install all necessary hardware components into our firewall
• Install IP Cop software and configure settings to fit our network set-up

10) Research Network Penetration testing [X]

First Quarter Goal Documentation

1) Setting up the test lab

• After doing a bit of research we settled on using the Xubuntu operating system. Xubuntu is a streamlined version of the Ubuntu operating system that is less memory intensive and thus better for older computers such as the ones used in our test lab. It also cuts out some of the unneeded bundled applications that come with Ubuntu, allowing us to add on only what is useful to us. While comparing hubs and switches we decided to use a hub. Hubs unlike switches broadcast packets out to all ports. This enables us to easily intercept packets, learn to analyze packet data, and learn about network security as a whole. Our final network set-up can be seen in the picture to the right.

Our test network as we set it up.

2) Packet Sniffers

• Under the recommendation of Mr.Bui we started using a program called wireshark (formally known as ethereal) to start capturing packets sent over our test lab network. Using the im client Pidgin, we set up test accounts and started talking to each other over the network. These packets were relayed to the Pidgin server and then sent to the other account. Using our hub and concurrently running wireshark, we were able to filter the captured packets to only view those related to Pidgin and the AIM protocol. The results were amazing. We intercepted packets containing everything from log-on info to message contents, buddy info, updates on when the person was away or idle, and even password hashes being sent at the log-in.

3) Password Hashes

• When signing onto AIM through Pidgin on one computer, we were able to capture a packet containing the log-on information as it was being sent for verification. The packet captured contained the password hash 51e3ed91700bee528a11e333ab25e6d2 as sent from Pidgin. After a bit of research on the AIM protocol we found that the password algorithm used in the aim protocol is MD5. MD5 turns the password into a one way 128-bit hash before sending it AOL for verification. Since MD5 is designed to be a one way algorithm it makes it very difficult to reverse and thus recover the password from the hash. Although difficult we found two ways that this could be done. The first is through the use of a Rainbow table. Rainbow tables take the hash value provided and compare it to thousands of known hash values and their corresponding plain text value. For our situation this option isn't exactly feasible as each hash value can have millions of possible combinations and requires extremely fast computers to crack. The second option we found was to use a password cracker such as Cain and Abel. Password crackers use vast word lists and compare individual words to the password hash hoping to find a match. The downside to this method is that the word list used must contain the password in order for the program to find a match. If the password is not present in the word list the search will come up inconclusive. Using the hash value we obtained I ran Cain and Abel at home comparing it to a default word list. Just as described in the downside, the default word list I used didn't contain the password so the program comparison thus came up inconclusive.

4) General Email Security

• With our brief stint into Pidgin security our group decided to move on and look into email security. After a bit of research and discussion with Mr.Bui we found that in general, most email hosts encrypt their login information and their messages. The most common method for encrypting login information is with SSL or TLS. SSL, short of Secure Sockets Layer, was invented by Netscape and accepts many different encryption ciphers. It was designed to make all sorts of communication over the internet more secure and it has succeeded all over the board making ease-dropping on certain information near impossible. Recently SSL was update and renamed TLS, short for Transport Layer Security. TLS works almost exactly the same way as SSL does except it incorporates stronger encryption algorithms and work with a greater number of ports. Unlike with login information, there was no real common way that email hosts encrypted email messages. We found that there were a number of different encryption algorithms employed today all of which depended on what the email host chose to use. To further look into this we decided to experiment with gmail and document our findings on their login information, gmail chat messages, and actual emails.

5) Intercept Gmail Log-in information to analyze

Screenshot of a captured packet on wireshark that displays google's log-on security.

• After our great success with intercepting packets while using Pidgin, we decided to move on and try our luck with gmails login information. As all of us already had gmail accounts we decided that this would be a good email client to test. For our fist test we did exactly what we did for the Pidgin log-on. While running wireshark on one computer someone else attempted to log-on to gmail using their username and password. From the intercepted packet that was being sent to google for verification we were able to learn a great deal about google's security. As shown in one of the highlighted regions in the picture to the left we found that google uses a SHA hash function combined with RSA encryption. The SHA hash functions almost identically as MD5 except it uses a 160 bit hash value versus a 128 bit one. This makes SHA hash functions even more secure than MD5 and thus harder to crack. Combined with SHA hashes google incorporates RSA encryption into the mix. RSA is one of the first encryption algorithms and uses public and private keys to encrypt information. The public key is obviously public and available to everyone. The private key is kept to ones self and used to decrypt the message. To do this the message is first encrypted with the public key and then sent out to the desired recipient. The recipient then decrypts it with their private key and is able to read the message. Google uses the combination of these two to encrypt login information and thus making intercepting someones username and password near impossible.

6) Intercept Gmail Chat messages through wireshark

• Unlike intercepting login information, intercepting gmail chat information was relatively easy. Once logged in, google no longer encrypts the information that flows between the email client and the outside. As Aj chatted with one of his cousins we were able to see the messages in real-time as he sent them. There was absolutely no encryption and the messages were displayed in plain text in packets that we intercepted in wireshark. We were also able to she her responses in the form of incoming packets. All status updates were also openly visible. Individual packets were sent when a user was typing, idle, or just moving their mouse. We all found it kind of creepy that these types of things were in no way encrypted and someone doing the exact same procedure we were doing would be able to view all this information.

7) Attempt to intercept normal emails sent through gmail

Screenshot of a packet containing the contents of an email.

• With gmail chat messages being in no way encrypted, we were very much curious to see if actual emails were. Much to our surprise, emails just like gmail chat messages, were not encrypted at all. Again using wireshark we were able to view sent and received emails, their senders, and their destination, all by viewing intercepted packets. Overall we concluded that while gmail is very secure while signing in, past that their is absolutely no security and plenty of room for people to intercept information. The moral of the story is never send sensitive information over unencrypted mediums such as gmail.

8) Make cat5e cables to connect the firewall to our test lab and APS network

• After we documented our findings on email security, we decided to build our own firewall and start heading more in the direction of firewall and network security. In order to do this we would have to set up a machine as a firewall, connect it to our test lab, and then connect it to our outside network, in this case the APS network. We quickly realized that we had all the essential supplies to do this except for the cable necessary to connect all the components. All the cables that we found in the classroom were either broken or way to short for our needs. Although while searching for cables we came across a giant spool of unassembled cat5e cable. We decided as a fun way to refresh our memory from cisco class that we would assemble our own network cable to use. To do this we needed the supplies as follows:

• Network cable
• Splitter
• Crimper
• Cable heads
• Cable tester

• To start we first cut a length of network cable long enough to suit our needs. Second, using the splitter, we cut about an inch of the protective plastic coating off each end to expose the four pairs of twisted wires inside. Once the pairs of wires were exposed we untwisted them, straightened them, and then ordered them in the correct configuration for a cat5e cable. Cat5e cables require the wires to be ordered left to right as green stripe, green, orange stripe, blue, blue stripe, orange, brown stripe, brown. After we put them in this order we cut the tips and carefully inserted them into one of the cable heads, making sure that they stayed in order and that each wire made contact with the pins at the top of the cable head. Finally once the wires were in place we took the crimper and crimped the cable head into place, permanently securing the cable head to the network cable. Once everything was completed we used our cable test to ensure that everything went right and that the cable functioned as desired. As with all our work it worked perfectly fine and it was onto setting up the firewall itself.

9) Set up Firewall for our test lab

Network map of our classroom.

• Once we finished assembling the necessary cable it was time to get down to business making the actual firewall. We pulled a machine of the back closet and inspected it to make sure it had the necessary hardware aspects. At the time the machine didn't have a single network interface card or NIC present. Thanks to Mr.Love at the career center we obtained a few NICs and installed two into the machine. We needed two NICs because one would serve as the incoming, unfiltered (except by APS) line of traffic and the other would serve as the outgoing, filtered internet to our test lab. With these installed we were able to then move onto installing the software portion of our firewall. We decided to go with IPCop as our operating system as it is a simple, easy to use, open source operating system, and Mr.Bui uses it so we can easily get help if we have any questions. The installation process was very straight forward and besides a slight problem getting the computer to recognize both NICs, it went off without a hitch. We configured the NICs to work in the way explained above with our red card handling the incoming unfiltered traffic and the green card handling the outgoing filtered traffic. Once we had this configured we connected our new firewall to the outside APS network as shown in the network diagram to the right. Our firewall connected to the APS network through DHCP also known as Dynamic Host Configuration Protocol. This means that IP addresses are automatically assigned to our firewall and computers at the beginning of each session. The class network on the other hand uses static IP addresses meaning that they use a permanent IP address that never changes.

10) Research Network Penetration Testing

• Now that our firewall is up and running, my next goal is to research network penetration testing, also known as pen testing, to analyze our network and try and find any security holes. This will allow me not only to see how secure our network actually is but also to gain a better understanding of network security as a whole. Penetration testing itself simulates an attack by an outside user and tries to find breeches in the network's security. The point of it is to find these security flaws and fix them before an actual outside malicious user does and exploits them to their advantage. While I don't expect our test lab to be attacked anytime in the near future, I believe this to be very beneficial to learn about network weaknesses, how to exploit them, and above all how to fix them.