Archive

Archive for the ‘DoS’ Category

DCECU ATM still has issues

January 28th, 2010 chad No comments

DCECU ATM issue still ongoing. Power box has a padlock, but it can still be turned off by anyone who decides to pull up and flick the switch. I called DCECU a few months ago (in addition to almost two years ago) telling them of the issue and they said they’d send someone out to see what they can do.

I no longer do business with DCECU as of April of 2009. The way I see it, they can send someone out to grab and drop off cash from a remote ATM, but they can’t put a lock on the power switch to prevent misuse. Seriously? Normally I would just say “oh well”, but it’s been almost two years now and the problem still exists. So now that I have moved my money and loans elsewhere, now I’ll say “oh well”.

Categories: DoS, Physical security Tags: ,

Meijer’s bottle return

April 25th, 2008 chad No comments

A couple of weeks ago or so I filled the trunk with bottles that needed to be taken back for bottle return. Not my favorite job in the world, but it eventually has to be done. While filling the machine full of empty 0.5 liter bottles, I happened to notice something that was kind of silly – the front door to the machine was unlocked and could be opened. I looked around and it turned out that all of the bottle return machines were like that. I was kind of hoping that this was just a fluke and that maintenance was being performed on the machines.

No such luck.

I went back a couple of days later to do some grocery shopping and found the same thing. This time I decided to open the door and take a look inside. There was another key (that could be removed) and a numeric keypad asking for an admin password – numeric password of course. Well, at least there was multi-factor authentication in place (outside key, inside key, password), but they already removed one of those factors by leaving the front door open. Not only that, but the receipts the bottle return prints out with the Meijer’s logo on it are easily accessible. If a somewhat smart theif grabbed a roll, they could be used for fraudulent purposes – print bar codes on receipt paper for bottle return money. Not good.

As coincidence would have it, a fellow student worked at Meijer’s and gave me a brief explanation as to why they left the doors open rather than locked – they kept losing the keys. So rather than make extra keys or make it mandatory to return keys to a certain location, they just forget the keys altogether and leave the front door unlocked. Apparently they already had the fake receipt problem described above with their Coinstar machine.

Don’t even get me started on the UScan self-service checkout machines…that’s for another post another time ;)

Solution: Simple – lock the doors. I went there again a few nights ago and locked all of them by pushing in the locking handles.

Materials: Voyager cell phone (camera).

Categories: DoS, Hardware, Physical security, Weird stuff Tags:

ICMP connectionless transmissions

April 22nd, 2008 chad No comments

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).

Categories: DoS, Internet, Linux, Network Tags:

Delta College password security

April 16th, 2008 chad No comments

Having been a former student of Delta College, as with any student, I was given a user name and password that was used for access to several services. These include network shares, email access, class registration through MyDelta, Educator (like Blackboard), FTP, and access to the Linux server amongst other things. So if I were a student and wanted to make sure that my password is secure, where would I start? Learn about the process and then find the weakest links of course!

First, as a new student you’re asked to go through the signup process, but when clicking through, you’re taken to the policy page first. Funny thing is that the page can be bypassed by just going directly to the sign up page instead. So yeah, legally, the policy is shaky ground since it can be bypassed during sign up. You enter all of your personal information in and you now have access with a single login and single password for all services.

So if someone wanted to hijack my account, what would they do? What plan of action would one take to steal my info? Well, if you click on the link that you lost your login name, you get directed to this page and are given this prompt. The same prompt is given if you click on the link that you want to update or change your password. Since nobody else should really know my SSN or Delta ID, and might only be able to figure out my birthday, it would make compromising my account more difficult. In essense, Delta is implimenting defense in depth. However, who needs a Delta ID when your login name is…your name. If your electronic account was created before Fall of 2002, your login name was your first initial, middle initial, and your last name. For example, John Q. Student would be jqstudent. After 2002, it’s simply your first name and last name (johnstudent). So hijacking your account via a “lost password” feature is too time consuming or too difficult. There has to be an easier way, right?

What about brute forcing the password with something like Brutus that does web-based password cracking? Probably not practical since Delta has a somewhat decent password policy in place and it would take forever to brute force the password this way. So that’s out of the question.

What about shoulder surfing at the library? Not really a bad idea, but it could be noticable by the victim. This method is definitely feasible, but could cause bodily harm or get you kicked out of the library. Then you would likely be watched closely during future visits.

What about services that could be exploited in some way or another? Maybe sniffing the password? Well, webmail is performed via SSL, so that make things difficult. MyDelta also uses SSL when you’re logging in as does Educator…finally after about a year or so after I made the suggestion to Educator staff. You’re not likely going to sniff anything while you’re logging in either. However, there are two services that are performed in clear text – FTP and telnet. These two services are only really used in a handful of classes, so you would have to devise a plan on how/where to sniff this traffic.

Telnet is used only for the Linux class (CST-126), but it’s also available online. Since their Linux server has a compiler installed, you could attempt to compile a sniffer from the command line, but that would likely be under your own account.

FTP is used mainly for uploading web pages in the CST-110, CST-133, and CST-210 classes. I’m not sure why you’d need to do that since the directory you upload to is world readable/writable by everyone, but that’s another post ;) So one could sit in a CST-133 class during the web site creation tutorial week, flood the router with false MAC addresses, and sniff the passwords as people log in. The other option is to sit in one of the wireless hotspots and hope someone logs in and needs access to the telnet or FTP server. You might be waiting a while for that one…

Worst case scenario was a few years ago when you could log onto the Linux server and grab the /etc/shadow file, which held encrypted passwords for the entire student body. I’m not sure exactly how this happened as the /etc/shadow file is normally only viewable by root, but it was likely because of a misconfiguration or fat-fingered-mistake such as “chmod 777 /etc/shadow”. In a nutshell, if you could copy this file to a flash drive, you could take it home, run John the Ripper on the file, and have some accounts to play with.

Anyway, the point is that if you are able to obtain a student’s password, you have full access to that student’s account. This includes access to all of the resources available that are specific to that student as well as the ability to add and drop courses they are currently enrolled in or signed up for. That would help if you’re having a hard time getting into a class because it’s full, eh? ;)

Disclaimer: Just as any post I make, I do not condone or encourage any malicious activity. I post the information I do to give people a little nudge in the right direction and take security a little more seriously. After all, there’s a lot of people’s trust in your hands and it’s your responsibility to keep the bad guys from breaking that trust. As usual, I have to rip on Collegis/SunGard because they’re the ones that handle Delta College’s IT sources including security. Unfortunately, they can’t seem to nail down the security part.

Materials: Access to a Delta College workstation and an Ubuntu Linux live CD.

Simulated Distrubuted Denial of Service attack

April 11th, 2008 chad No comments

For those that aren’t familiar with Distributed Denial of Service (DDoS) attacks, they can be very detrimental to network and system performance. They’re generally used for nefarious purposes including spam, blackmail, and extortion of mid-size and large companies. The reason for this is because it would be quite embarrassing for a company to have their systems unavailable because of crackers. It could also be detrimental to businesses requring online transactions and communications to stay afloat. Because of this, many people in control of the botnets can get away with fleecing companies for thousands of dollars as a “cost of protection/prevention”.

One way for a botnet to come into existance is through a worm – either a mass-mailing worm or a worm that takes advantage of a software/operating system exploit. Sometimes no user interaction is required for a host to become infected and contribute unwillingly to a botnet army full of zombie computers. “Storm” is the name of one well-noted example of how large and powerful a botnet can become at around 200,000 infected computers. More recently a botnet named Kraken has emerged that is reported to consist of over 400,000 infected machines and is undetectable with the majority of anti-virus scanners because of the obfuscation techniques Kraken uses. There are also reports that the worm has been spotted on computers in 50 of the Fortune 500 companies.

One way these botnets communicate centrally are in IRC channels. Personally, I have seen botnets on a few occasions and it fascinated me how easily they are managed and controlled. Everything from patching the code of the software used to gain control of the host to begin with to attacks being launched on web sites and IRC servers to complete removal of the software. All done remotely with a few commands.

The following videos are simulated environments I created showing the effects of a botnet to both a client and the server on an IRC server. Please keep in mind that there are only ~650-700 bots in this simulation versus a few hundred thousand in the previously mentioned botnets Storm and Kraken.

DDoS as seen from the client side:

DDoS as seen from the server side:

Solution: Honestly, there’s not a whole lot one can do if a botnet is large enough. Your biggest concern would be saturation of bandwidth. If you have a T1 line, it could take as little as a couple dozen zombies on broadband to take your connection down preventing others from using your services.

Materials: Client – Compaq Presario laptop (2135US), Server – older Dell 1000mhz machine, Kodak Digital Camera (C743), assistance from Rebecca.

Categories: DoS, Internet, Linux, Network, Software, Windows Tags:

Google hacking – is your network vulnerable?

April 9th, 2008 chad No comments

Google hacking has been talked about on several other web sites before, but most people just don’t think about the implications of not securing their services. Often the attitude of “it could never happen to me” takes precedence over an admin taking proper security precautions. After performing some simple Google searches, you too can gain access to everything from database information, personal emails, and even some free mp3s.

First, let’s start off with a simple database search and password search. These simple two searches can reveal configuration information about databases including login and password combinations. For example, nv-happydays.com showed three files that are downloadable including a two password.inc files and a WS_FTP log that revealed other sites. Luckily, all of the sites related to nv-happydays.com did not allow direct database connections.

If a database is connected to the internet and not properly protected, anyone can run a database query on (for example) port 3306 for a MySQL database server and find even more, and potentially sensitive, information. You should NEVER be able to publicly read a database configuration file – you should only see something similar to this. Otherwise, you have set yourself up to have many many files viewable by the world for potentially nefarious purposes.

blackworldnews.com was not so lucky about other files. These included their mysql.sql file, their inbox file (mostly spam just like everyone else), and their shadow file which was loaded into and proved to be crackable by John the Ripper in a fairly short amount of time. 8 hours, 47 minutes, and 31 seconds to be exact.

Another unlucky Googled site was wealdendun.com. Their mysql.sql file as well as their shadow file were found, and again, could be cracked by John in a very short amount of time just like blackworldnews.com.

Another search that turned up some interesting information was searching for backups. I found an educational institution that used BlackBoard (just like Davenport) had their backup files publicly readable. Also readable were usage statistics and more detailed usage statistics. No, not the most exciting stuff in the world, but I would think that these items should probably be limited to system administrators and not the whole world.

Solution: Fairly simple. At the very least, add the extension .php for any files that have .inc as an extension. Examples include, but are not limited to “password.inc”, “database.inc”, “configuration.inc”, or any other *.inc file. They would then be changed to “password.inc.php”, “database.inc.php”, “configuration.inc.php”, or *.inc.php instead respectively. Every *.inc file I have ran across has coding that starts with <? and ends with ?>. This is typically how php coding starts, but most browsers don’t go simply off of the code they see, they go off of the extension when processing files. If the extensions were *.php, anything in between the <? and ?> would get hidden even if one tried to view the source of the file. Another solution would be to add a black index.html file to directories that don’t already have an index file of some sort. Apache can also be configured to not to allow directory listings so these files are not viewable by search engines in the first place. To do this add the text “Options -Indexes” (without quotes) in a .htaccess file. Google it if you’re not familiar with htaccess files. However, if the files have already been exposed to search engines, they’ve most likely been crawled. In this case, you NEED to take the previous measures to remove access to your files and then IMMEDIATELY change your passwords.

Materials: A web browser and some free time.

Categories: Database, DoS, E-mail, Internet, Linux, Network, Windows Tags:

ATM security followup

March 16th, 2008 chad No comments

Physical security on remote ATMs don’t seem to be as up to par as they should be. As discussed in a previous post, their power sources seem to be wide open for tampering. While on the surface, it may seem more like just an annoyance that an ATM may be shut down and not working. However, there is a possibility that the power failure could either remove or trigger alarm functions that could alert someone that the ATM is being tampered with. Without knowing more about how the ATMs work, let’s assume that the power removes any alarm that is triggered.

With full physical access to a remote ATM location out of the view of the general public, potential theives could install hardware keyloggers, sniffers, take the money from the ATM, etc. Keyloggers and sniffers could capture all information a user enters or any transactions between the ATM and the bank. Packets could also be altered before being sent to the bank’s database, which leaves even more potential for account compromises. Since a lot of ATMs are made by Diebold, I’m sure their locks aren’t up to par considering what they protect.

So back to the main power shut off. After finding the ATM in Freeland that had the main power shut off in plain view and not locked to prevent people from flipping the switch, I decided to look around at other ATMs. One of the first ones I drove by was a local bank ATM in Midland. If you look at the main power switch, it’s covered, but not locked. Just down the road, there’s another ATM that had the main power switch covered, but again, it was not locked.

One possible solution would be to use locks on the power switch boxes. Either that or enclose the power switch inside of a door in the ATM itself somewhere.

Materials: About $3 in gas, Kodak Digital Camera (C743).

Diebold voting machine security

February 29th, 2008 chad No comments

Diebold Accuvote voting machines, as most people know, have had a hard time gaining and keeping any credibility in the world of information security. This is nothing new, but to add to the thought of how insecure these machines are, here is an image of the keys that some people have made copies of – just from the image itself. A group of students at Princeton discovered the Accuvote keys are actually a common office furniture key used for hotel minibars, electronic equipment, and jukeboxes.

But of course you don’t have to make your own key because Diebold will sell you one fairly cheap: “Replacement Access Keys”, part number GS-567311-1000, $5.90 for a set of 2. Order by phone at 1-800-769-3246.

So while taking physical security into consideration, one should also consider that just being able to take a picture of a set of keys can be just as effective as “shoulder surfing” while someone is entering a numeric password on a keypad.

Categories: DoS, Physical security Tags:

ATM security

February 13th, 2008 chad No comments

One important thing I have learned is that you should never take physical security for granted. If you have physical access to something, your options for compromising a potential target increase greatly. This runs true for everything from computers, to homes, to cars, to banks, and even garbage receptacles.

One day while driving through Freeland, Michigan, I happened to notice something a little out of the ordinary. I drove up to a credit union’s remote ATM to pull out some money for a trip and became a little concerned. It appears that whoever had installed this particular drive-up ATM did not make a conscious attempt to make sure it isn’t subject to a simple, physical denial of service attack. Note that there is nothing stopping the arm on the switchbox from being thrown to “off”. Granted, if one wanted to physically harm the ATM, they could always drive into it or something similar. However, this was much more simple – just turn off the power on the breaker switch and the ATM gets shut down. It was not locked in the on position, which is understandable, but it was not guarded or enclosed in any way.

This is an example of how physical security is commonly overlooked and should be taken into account whenever possible. You don’t park your car in a parking lot with valuables on the dash for the world to see and leave your doors unlocked. You wouldn’t take a vacation and leave your front door/garage door open while you were gone. You wouldn’t throw away an old credit card without first cutting it up with scissors. There are people out there who have the capability and motivation to cause harm. Don’t give them the opportunity to do so – take physical security into consideration whenever possible.

Materials:  About $10 in gas, Voyager cell phone (camera)

Categories: DoS, Physical security Tags:

Hotel security – Viking Arms Inn

February 2nd, 2008 chad No comments

While staying in Ludington, Michigan and taking a short drive through the town, I found that the hotel I was staying at had not changed their “passphrase” for encryption in quite some time:

Viking Arms Inn
SSID: Viking_Arms_Inn
Passphrase: abcabcabc1

Same as it has been for years per other previous guests. It would seem kind of pointless to have a passphrase if it never changes – especially if the passphrase is to be used by, or is available to, many people. Once a person stays there once, does this mean they have permanent wireless access?

While this is great for the casual surfer, it leaves the door wide open for abuse. Think about it for a moment from a malicious point of view. Other than the obvious searching for shared folders and possibly hijacking other computers on the open wireless network, there are even worse scenarios. If I were a virus writer, the smartest thing to do to prevent being caught is to release it from someone else’s network. If I were a spammer, I could have a field day on someone else’s network. If I were a real jerk, I could create a shell script to delete everything on every shared drive I gain access to while driving by at 40 mph.

Categories: DoS, Network, Wireless Tags: