While heading back from South Carolina, I got bored (again) so I fired up the laptop and decided to wardrive Charlotte while driving through it…
The netstumbler file is somewhere around here…I’ll post it when I find it 
Materials: Compaq Presario laptop (2135US), Belkin wireless card (F5D6020), Kodak Digital Camera (C743), assistance from Rebecca.
Home of a couple of large bike rallies each year, Myrtle Beach is not only huge, but full of things to do. I highly recommend Godfather’s pizza – it’s the best pizza in town by far! Just before we left, I had to whip out the laptop and partake in a bit of wardriving. This one is a two parter…
Part 1:
Part 2:
Myrtle Beach, South Carolina netstumbler files one, two, and three.
Materials: Compaq Presario laptop (2135US), Belkin wireless card (F5D6020), Kodak Digital Camera (C743), assistance from Rebecca.
Just a quick drive through Asheville, North Carolina yielded a few wireless APs…
I put that netstumbler file somewhere…I’ll post it if I locate it
Materials: Compaq Presario laptop (2135US), Belkin wireless card (F5D6020), Kodak Digital Camera (C743), assistance from Rebecca.
Wow, what a beautiful area Carolina Beach was – definitely worth visiting if you’re in the area. The beaches were clean, the houses were gorgeous, and there were tons of wireless APs.
Carolina Beach, North Carolina netstumbler file.
Materials: Compaq Presario laptop (2135US), Belkin wireless card (F5D6020), Kodak Digital Camera (C743), assistance from Rebecca.
Taking a quick drive through Wilmington, North Carolina, which is just before Carolina Beach. Still have South Carolina in my sights…
Here is the Wilmington, North Carolina main netstumbler file and the tail end of the drive.
Materials: Compaq Presario laptop (2135US), Belkin wireless card (F5D6020), Kodak Digital Camera (C743), assistance from Rebecca.
Castle Hayne seemed like a fairly decent size city, so I decided to take a break from highway driving and fired up the laptop for some wardriving.
Castle Hayne, North Carolina netstumbler file.
Materials: Compaq Presario laptop (2135US), Belkin wireless card (F5D6020), Kodak Digital Camera (C743), assistance from Rebecca.
Well what else is a person supposed to do in Washington, DC other than see all the sites? Wardrive it of course! For more info on the wireless APs found, check out the netstumbler file. There are three videos – part 1, 2, and 3 because YouTube apparently only allows videos to be 10 minutes each.
Part 1:
Part 2:
Part 3:
Washington, D.C. main netstumbler file. Here’s another netstumbler file for Ft. Myer, Virginia (just across the river from D.C.)
Materials: Compaq Presario laptop (2135US), Belkin wireless card (F5D6020), Kodak Digital Camera (C743), assistance from Rebecca.
After seeing enough of New York, I decided to head south and wardrive Scranton, Pennsylvania…and run a stop sign 
For more info on the wireless APs found, check out the netstumbler file.
Scranton, Pennsylvania main netstumbler file and the highway file taken as I was leaving Scranton.
Materials: Compaq Presario laptop (2135US), Belkin wireless card (F5D6020), Kodak Digital Camera (C743), assistance from Rebecca.
Continuing my road trip, I decided to wardrive Binghamton, New York. For more info on the wireless APs found, check out the netstumbler file.
Binghamton, New York netstumbler files – first pass and second pass.
Materials: Compaq Presario laptop (2135US), Belkin wireless card (F5D6020), Kodak Digital Camera (C743), assistance from Rebecca.
While taking a road trip down the east coast, I decided to whip out the laptop in a few places. The first stop was Niagara Falls, New York. For more info on the wireless APs found, check out the netstumbler file. More videos to come shortly…
Niagara Falls, New York netstumbler file.
Materials: Compaq Presario laptop (2135US), Belkin wireless card (F5D6020), Kodak Digital Camera (C743), assistance from Rebecca, and don’t even get me started on gas…
Verizon Business has released a report that touches on what they found after looking through 500 forensic investigations involving 230 million records, and analyzes hundreds of corporate breaches. These breaches include three of the five largest breaches ever reported. Here is a few items they discovered:
There’s also some very good information in the article regarding how to protect your network and data. I would strongly encourage any network/system administrator to, at the very least, browse this part of the report.
As most people in networking know, ICMP and UDP transmissions are connectionless. However, not everyone quite understands what that means. Basically, if you send a ping request to another computer, you can spoof the address you’re sending from to make it look like it’s coming from somewhere else and the reply will actually go to the spoofed address. In this video, I will demonstrate spoofing ICMP packets to another computer on Davenport University’s network and across the internet making the packets appear to come from somewhere else. Keep in mind, this isn’t specific just to Davenport’s LAN – I could send these packets to any computer on the internet (as long as they accepted ICMP and/or UDP packets) and would get the same results.
This does have potential for abuse. A person could set up multiple machines to send large ICMP packets to another machine and they’d have a hard time figuring out where the packets are coming from in their firewall logs. In turn, this could potentially create a Denial of Service situation and would be fairly untraceable. I’ve heard this called a DRDoS attack (Distributed Reflective Denial of Service), spoof attack, and a ping flood before. Yes, it’s a spoof and ping flood, but with that twist of being less traceable.
I experimented at Davenport University with my laptop and a Davenport workstation. I was able to spoof packets from a machine within the Davenport network that appeared to be in Grand Rapids, Michigan called “grgw“. This is a server I had found in another experiment that also appeared to be running an SSH server. Fun stuff. I apologize for the bad video quality and “shakiness” – that’s what I get for trying to type with one hand and shoot video with the other
Solution: Block ICMP packets at your firewall or router from the internet. Ping requests aren’t necessary if, for example, you know of a service that’s always running and you could connect to as confirmation that the host is up.
Materials used: Spoofer – Compaq Presario laptop (2135US), spoofee – HP Compaq DC7600C with Ghostwall firewall (to prevent a required reboot on a Windows machine), Kodak Digital Camera (C743).
I meant to go back and follow up a little more, but for now I’ll post my findings so far. Honestly, Davenport has their act together for the most part – I only discovered very minor things that are easy fixes and do not pose an immediate security threat.
Back on March 12th, I needed to use the library for a short while. I used the map command to see what I’m already connected to for the heck of it. Afterwards, I started playing around in My Network Places – specifically the Novell Connections. First I played around with a share called Midland_4x, but nothing was too interesting there. Of course another one of the first things I had to check out was the part that said “STAFF” Still nothing interesting really. I played around in the tree a little longer and finally found something that caught my eye – something that appeared to be a unix-based server with SSH. It used the default port (22), but ended up being either down or filtered by the firewall. Then I found another server that looked like it was for grad students that had somebody’s resume on it. The whole directory appeared to be world readable/writable. Two other things I’ll have to check out later are a front page to their Novell OpenEnterprise Server (Novell and Suse – good stuff!) and what appeared to be an OpenSource Project page. Nice 
I wasn’t sure what to make of their BMC Service Desk Express page or the APC InfrastruXure Manager page. Looks like I’ll have to do some more research on those when I get some time. One thing that should probably be addressed is Apache being installed and running on several Novell servers. As you can see from the screenshot, the default index page is still up, which tells me that the administrators may not know Apache is running. As we are taught in several classes, unused services should never be running. /etc/init.d/apache2 stop
About a week later I went back to look for anything else that might catch my eye. I found what I was looking for in the “Documents and Settings” folder. If you surf to C:\Documents and Settings\, you’ll find the names of everyone who had logged into the computer. You’re also able to poke around in their folders, which show information such as downloaded programs, personal files saved to “My Documents”, and their “Favorites” amongst other things. While it could take forever to look for anything of interest in all of those folders at the library, all you have to do is output the tree command to a text file for later viewing. In defense of Davenport, they’re not the only one’s who have this issue – Delta College does as well. They allow viewing of cookies and recent documents, which could reveal some information about themselves or their online identities including hotmail, student email addresses, projects they are working on (assuming that’s a project), facebook identity, and more.
Overall, I was pretty happy with what I discovered…which wasn’t a lot
I previously discussed Delta College’s Linux email vulnerabilities, so I thought I’d discuss other vulnerabilities from the past as well. I have been frustrated with the responses I have received from Delta regarding security since back in 2003. The responses from all but one person have been “well, it’s our server and we’ll configure it how we want to”. Hey, I completely understand except for one tiny little detail – your server has MY PERSONAL INFORMATION attached to it as well as THOUSANDS of other student’s personal information. That and you’re a publicly funded school, so you should probably take the proper measures to make sure your student’s information is adequately protected. On the bright side, that, to me, means that they don’t mind the information I find being posted publicly.
eLearning is a wonderful tool that allows students the flexibility of not having specific class hours. It allows students that work during the day the ability to work on a class in the evening if a regular classroom setting isn’t available in the evening. It’s very similar, though not as functional, as the Blackboard Acedemic Suite. I had emailed the eLearning manager about a year and a half ago regarding potential security risks that could affect all students using the eLearning web site. The more “minor” risk of the two is the ability to use any HTML tag in the post. This should be restricted to using only the following tags: bold, italicize, underline, a href (links), and the rest should be stripped – PERIOD.
A more major flaw is that students are/were able to post using their teacher’s name. This is not done by changing the font colors, but is actually a flaw in the eLearning software itself. Again, it could easily be fixed if they blocked HTML tags except for the few I’ve suggested. As of this posting, I’m unsure if the flaw still exists as I haven’t had an online class at Delta in a couple of years.
Everything looks very secure as far as changing your password at Delta. SSL login and 3 pieces of “personal” information make it difficult for someone to brute force their way in to be able to change your password. I had went over this recently.
Delta’s strongest links are webmail, MyDelta, and their signup page. This isn’t because they’re using specific server software or a specific OS – that’s irrelevant in the overall security. The reason they’re strong points in Delta’s network from a client standpoint is that they implement SSL for encrypted logins. More recently, after analyzing some packets while a friend logged in to their eLearning account, I found that logins are encrypted even though the front page is not (normally) using SSL unless the address is altered to use SSL (https vs. http).
One of Delta’s weakest links would have been educator (eLearning) because the login was not encrypted. You used to be able to sniff passwords from fellow students or even your teachers. A certain teacher showed up in another class I used to take to check Educator before he went to his other class each day. I was able to capture his login name and password in clear text because eLearning did not implement SSL at the time. This was dangerous since students could alter their grades or other student’s grades if they were to log in as the teacher. It is also dangerous because Delta’s idea of security is sharing the same password across all Delta resources both encrypted and unencrypted. Hence, if you sniff the password from the unencrypted sessions, the encrypted sessions mean nothing.
Another weak link is their Redhat Linux Enterprise server – telnetting to xserver is unencrypted and leaves the door wide open for login/password interception. This had been discussed once before. This could easily be fixed by implementing OpenSSH (they used to have it running) and using a good, solid SSH client rather than NetTerm, which is currently installed. When I had downloaded and installed NetTerm years ago, by default it used to have a FTP server built in that was on when installed and allowed anonymous login sessions. That’s not a good position to put students in regarding the security of their own machines.
When I had notified Delta about xserver’s issues, I was blown off and then disallowed access once the semester was completed and have not been able to log on using my account since. This was not a standard operating procedure at Delta as all of my fellow students still had access to xserver after the class was finished and on into the next school year. Most of the issues raised were not fixed until sometime during the summer of 2005 – well over a year after being told about the issues in the first place.
Unfortunately, xserver still remains insecure.
Delta has definitely shown more of a reactive stance than a proactive stance when it comes to security. If the solution to a security issue is simple, it can be tested fairly simply, and implemented in a fairly short amount of time. In fact, in the case of the SSH installation on xserver, it already *was* installed, then Delta removed it. Why they would do such a thing is beyond me.
Since Delta College is now offering a degree in Information Security and Technology, they’re losing credibility in my eyes. If Delta can’t secure their own network with some good security measures, how can they be considered a credible institution for this new program? Are they ready for possible identity theft because students have social security numbers, phone numbers, addresses, and credit card numbers associated with their Delta ID?
I guess the most offensive part of this whole situation is that when I approached Delta faculty about these security issues, one particular faculty member had responsed in an almost threatening manner and never bothered to fix some of the most serious misconfigurations until 14-16 months later. Yes, that’s over a year and the remaining misconfigurations still exist that threaten the security of the server. That’s right – their way of fixing the problem is to remove the problem – me. Unfortunately for them, I know other students that attend Delta College and allow me to look around at xserver every so often under their account (and supervision – I insist upon it.).
Anyway, since telling the faculty does nothing more than singles me out, I decided to present this information in a presentation to two classes I previously had and here.
Solutions: What Delta College can do to remedy these situations would actually be fairly simple:
For eLearning:
*Set up a whitelist of HTML tags that users can post with. Reference www.slashdot.org for an example of the correct way of doing this. Slashdot’s code is open source and is freely available – it’s known as “Slashcode“.
*A link could redirect to a cloned page such as the “session has expired – please enter login/password” set up to steal passwords.
*A student could “embed src” an offsite page within Delta’s eLearning area to make it appear to be a part of eLearning. This could then be changed after the malicious activity is complete.
*The links at the bottom of the page could be hidden and malicious links could replace the legit links doing a “font color=”white”" font change or a !– hidden tag.
For xserver (Linux server):
*Install SSH on their Redhat server (xserver) by logging in as root and issuing the command “urpmi openssh-server” or installing it via Redhat’s GUI interface for package management. For Debian distro’s it would be a simple “apt-get install openssh-server” to install OpenSSH. When installed, it would automagically be available for all users.
*Require students to use the SSH client from SSH Communications (freeware) for xserver connections as well as FTP transfers. This would be better than requiring both NetTerm (used to be very insecure) and WS_FTP to be installed. One application to cover both functions and the login is now encrypted.
*Test and upgrade patches to their Redhat server – try any patch. The last time I had created a VNC session on their server (yet another issue…), not a single patch had been issued to xserver since the initial OS installation.
*To remove the ability for running X-specific binaries (xchat, gftp, vncserver), all they’d have to do is create a user group like “student” and allow them only to access/execute the files that are required to teach the CST-126 and CST-133 classes. Either that or just uninstall unnecessary programs using Redhat’s GUI package management system (up2date, yum, or whatever).
For FTP:
*Last I knew, alpha.delta.edu was a Windows machine running IIS and the FTP server associated with Windows Server. Either find a way to enable secure file transmissions to this server, or install the software and/or operating system that allows this type of transfer to occur.
Materials: An internet connection and in some cases, physical access to a Delta College computer.
As I was making some purchases in Menard’s yesterday, I happened to visit a kiosk that had about 4 PCs sitting there with a screensaver on. I couldn’t really tell if they were for employees only or not, so I walked up to one and moved the mouse. Unfortunately, it asked for a password and I wasn’t about to try to start guessing. Instead, I hit CTRL+ALT+DEL and saw the option to reboot. So I rebooted the machine and walked away. I came back about a minute later to find the machine updating. Not just patches, updates, and the like, but rather new pricing, new products, and other store-related updates. I took a couple of screenshots with my camera phone (by the way, Motorola Razr phone cameras suck) of the updates taking place and a list of completed and upcoming updates. Sorry about the poor picture quality – Razr phone cameras have absolutely terrible quality.
Materials: Motorola Razr camera phone.
