Mine would be discovering an ODBC DSN used for reporting, where the password matched the user, and the user belonged to the database server administration group.
So any PC with this ODBC DSN could read/alter all data (and worse) through the report user, using any ODBC compatible tool. No authorization required, and authentication was as weak as you can get.
I was working in a public hospital, and the software was installed on nearly every PC in every government hospital in the state, with the database server containing all sorts of sensitive medical data (full patient details, lab test results, etc.)
Worst of all, we quietly reported the security hole, then officially, and it still wasn't fixed in the 2 years I remained working there, and that was 5 years ago.
A peer once tweeted his password by accident... that was a pretty bad security hole.
The worst hole I've ever seen was a bug in a web application where giving an empty user name and password would log you in as administrator :)
When I use Colloquy (IRC), the password field pops up, but I still have focus in the main screen so the whole world knows my password when I hit enter and don't realize it.
When I was 13 years old my school opened a social network for the students. Unfortunately for them I found a security bug where you could change the URI to another userID like "?userID=123" and become logged in for that user. Obviously I told my friends, and in the end the schools social network was filled with porn.
Wouldn't recommend it though.
Though this is not the worst security hole I’ve ever seen. But this is at least the worst I’ve discovered myself:
A pretty successful online shop for audiobooks used a cookie to store the identification information of the current user after successful authentication. But you could easily change the user ID in the cookie and access other accounts and purchase on them.
The company I last worked for had their FTP username and password identical to the name of their domain. They didn't quite bother with repeated warnings.
Needless to say, it didn't take a long time for the site to go under. No online backups so they basically had to rebuild the whole thing. But it doesn't end there. The new secure password after this incident was the same... with 123 added on.
Right at the start of the .com era, I was working for a large retailer overseas. We watched with great interest as our competitors launched an online store months before us. Of course, we went to try it out... and quickly realized that our shopping carts were getting mixed up. After playing with the query string a bit, we realized we could hijack each other's sessions. With good timing, you could change the delivery address but leave the payment method alone... all that after having filled the cart with your favorite items.
Web app on IIS, there was no file upload filter. So you could upload exe, and do smf fun ;)
Committing the database root password to source control by accident. It was pretty bad, because it was source control on Sourceforge.
Needless to say the password got changed very quickly.
Maybe a bit of an anecdotal story here (but since it's the worst security hole I found)...
There was a company which sold a custom CMS (for websites) to a number of companies/organisations (including ours unfortunately). They use quite a bit of (mostly 'LGPL') components they did not make. Lots of clients (including government).
Result: on every site they built one could (without entering credentials whatsoever) alter/delete/change/upload every single document/file and/or image on the website.
We reported this gaping security hole as soon as we found out so it may not have led to direct damage (but it could have easily).
True story from my early days at Microsoft.
You haven't known fear until the day you wake up and see the headline on ZDNet.com that morning is "Worst Internet Explorer Security Hole Ever Has Been Discovered In 'Blah'" where 'Blah' is code you wrote yourself six months previously.
Immediately upon getting to work I checked the change logs and discovered that someone on another team -- someone we trusted to make changes to the product -- had checked out my code, changed a bunch of the security registry key settings for no good reason, checked it back in, and never got a code review or told anyone about it. To this day I have no idea what on earth he thought he was doing; he left the company shortly thereafter. (Of his own accord.)
(UPDATE: A few responses to issues raised in the comments:
First, note that I choose to take the charitable position that the security key changes were unintentional and based on carelessness or unfamiliarity, rather than malice. I have no evidence one way or the other, and believe that it is wise to attribute mistakes to human fallibility.
Second, our checkin systems are much, much stronger now than they were twelve years ago. For example, it is now not possible to check in code without the checkin system emailing the change list to interested parties. In particular, changes made late in the ship cycle have a lot of "process" around them which ensures that the right changes are being made to ensure the stability and security of the product.)
Anyway, the bug was that an object which was NOT safe to be used from Internet Explorer had been accidentally released as being marked "safe for scripting". The object was capable of writing binary files -- OLE Automation type libraries, in fact -- to arbitrary disk locations. This meant that an attacker could craft a type library that contained certain strings of hostile code, save it to a path that was a known executable location, give it the extension of something that would cause a script to run, and hope that somehow the user would accidentally run the code. I do not know of any successful "real world" attacks that used this vulnerability, but it was possible to craft a working exploit with it.
We shipped a patch pretty darn quickly for that one, let me tell you.
I caused and subsequently fixed many more security holes in JScript, but none of them ever got anywhere near the publicity that one did.
Being an application security consultant for a living there are lots of common issues that let you get admin on a website via something. But the really cool part is when you can buy a million dollars worth of socks.
It was a friend of mine working on this gig but the jist of it was that prices for items in a certain now very popular online book (and everything else) shop were stored in the HTML itself as a hidden field. Back in the early days this bug bit a lot of online stores, they were just starting to figure out the web. Very little security awareness, I mean really who is going to download the HTML, edit the hidden field and resubmit the order?
Naturally we changed the price to 0 and ordered 1 million pairs of socks. You could also change the price to negative but doing this made some part of their backend billing software buffer overflow ending the transaction.
If I could choose another it would be path canonicalization issues in web applications. It's wonderful to be able to do foo.com?file=../../../../etc/passwd
I used to hack Novel Login (DOS prompt). I wrote a C program to simulate a login prompt and write to the file whatever the login/passowrd is and output the invalid password.
I had fun in the college days.
Mine would be for a bank I was a customer of. I wasn't able to log on, so I called customer service. They asked me for my user name and nothing else - didn't ask any security questions or try to verify my identity. Then instead of sending a password reset to the email address they had on file, they asked me what email address to send it to. I gave them an address different than what I had on file, and was able to reset my password.
So essentially, all a hacker would need is my user name, and he could then access my account. This was for a major bank that at least 90% of people in the United States would have heard of. This happened about two years ago. I don't know if it was a poorly trained customer service rep or if that was standard procedure.
Saw a door that somebody forgot to lock once...
Alternatively, saw some JavaScript which executed some SQL via an Ajax call. Only problem was that the SQL to be run was rendered with the page and then passed to the service...
The biggest security hole is that when web developer designed open-password field sign-up form. The password field shows what you typed and not blank it out. This way when you're signing-up form on public computers could see what you typed on password field. Many websites do have sign-up form like this.
I'm sure there are few website with low-security that password and logins of users are easily accessible to admins.
An online DVD-rent-shop in Sweden sent pure SQL-statements in the querystring.
If you selected for example category "Comedy" in the menu-frame, it then sent "select * from movies where category=2" as querystring to the movielist-frame, that then executed the SQL-statement and showed all movies matching the criteria.
Same thing when adding movies to your order.
Just change the query to "delete * from movies" and "Delete * from orders" would make the day for that company.
I saw this one in The Daily WTF.
<script language="javascript">
<!--//
/*This Script allows people to enter by using a form that asks for a
UserID and Password*/
function pasuser(form) {
if (form.id.value=="buyers") {
if (form.pass.value=="gov1996") {
location="http://officers.federalsuppliers.com/agents.html"
} else {
alert("Invalid Password")
}
} else {
alert("Invalid UserID")
}
}
//-->
</script>
Nothing can beat this IMHO.
I'll share one I created. Kind of.
Years and years and years ago the company I was working for wanted indexing on their ASP web site. So off I went and set up Index Server, excluded a few admin directories and all was good.
However unknown to me someone had given a sales person ftp access to the web server so he could work from home, this was the days of dialup and it was the easiest way for him to swap files.... and he started uploading things, including documents detailing the markup on our services.... which index server indexed and starting serving up when people searched for "Costs".
Remember kids, whitelists not blacklists.
From early days of online stores:
Getting a 90% discount by entering .1 in the quantity field of the shopping cart. The software properly calculated the total cost as .1 * cost, and the human packing the order simply glossed over the odd "." in front of the quantity to pack :)
I hope you can spot what's wrong here. (Terribly wrong, in fact):
String emailBody = "";
for (int i = 0; i < subscribers.Count; i++)
{
emailBody += "Hello " + subscribers[i].FirstName + ",";
emailBody += "this is a reminder with your account information: \n\n:";
emailBody += "Your username: " + subscribers[i].Username + "\n";
emailBody += "Your password: " + subscribers[i].Password + "\n";
emailBody += "Have a great day!";
emailDispatcher.Send(subscribers[i].EmailAddress, emailBody);
}
The last recipient was the happiest ;)
I inherited a client project to baby-sit: an ASP.NET project (built back on 1.1) that was 50% compiled DLL's (with no source) and 50% code-behind JIT compiled.
The entire site was supposed to be members only - except the original developer had built a back-door: simply submit the login form with a blank username and password, and you would find yourself logged in as a secret super-admin: do anything, see everything.
You guessed it: all of the authentication code was hidden away in the pre-compiled DLL. The worst thing was when I was informed "it was not on the list of bugs, and the client won't pay, so leave it". So I did, and it's still live today.
How about a online document manager, which allowed to set every security permission you could remember...
That is until you got to the download page... download.aspx?documentId=12345
Yes, the documentId was the database ID (auto-increment) and you could loop every single number and anyone could get all the company documents.
When alerted for this problem the project manager response was: Ok, thanks. But nobody has noticed this before, so let's keep it as it is.
Not changing admin passwords when key IT employees leave the company.
Stocking credit card information in a database with no encryption ( WHOLE information: number + expiration date + cryptogram). In addition, the database was used as a kind of CRM, so lots of sales people can access it with a not-secure-at-all password. (Who haven't changed it since I left the company 3 years ago.)
I don't know if this is the worst, since I've seen some that were pretty bad, but:
Years ago, a place I worked at brought in a system called FOCUS. Don't know if it's still around or not. It's great for reporting, and we developed and taught perhaps a thousand or two non-IT people how to produce their own reports. Very handy. They could do the basic reports, some could do the medium-hard stuff, and IT could help with the harder stuff.
All of the data for reporting was copied regularly to shadow databases in FOCUS' own format. For the more sensitive data, we set the secure option, which encrypted the data. All well and good.
So, one day my boss calls me in, and we've lost the password to one of the sensitive databases. It's going to be hard to reproduce the data in this case, so he asks me to see if I can break the security. I had no experience as a hacker, so it took me about 5 or 6 hours to hand him the password. I started by creating some test files, and encrypting them with different passwords. I found that changing one character in the password would change two bytes in the encrypted file, specifically, the high nybble of one byte, and the low nybble of another byte. Hmmmm, says I. Sure enough, they stored the password somewhere in the first 80 bytes of the encrypted, but obfuscated the password by splitting the bytes into nybbles, and storing them in predictable places.
It didn't take long after that to write a REXX script that ran under the VM/CMS system and would tell us the password of any encrypted database.
That was a long time ago - in the early nineties, and I'm sure they've since fixed this problem. Well, pretty sure.
Not strictly a security hole, more of a "feature" that lots of rookie server admins didn't know/care about at the time.
Around 1999-2001 I had lots of fun with Frontpage and unlocked Frontpage server extensions installed on public facing websites.
When you had Frontpage installed you got this nice handy "Edit in Frontpage" button within Internet Explorer.
When visiting a site, e.g. www.foo.com, If you clicked on the "Edit in Frontpage" button in Internet Explorer and the server admins hadn't done their job properly then Frontpage happily opened up the full directory structure of the virtual directory and allowed you to read/edit the contents.
This worked on many sites from little one man band setups to bigger public organisations.
I always fired an email off to the "webmaster" when found an open server and I once got a £50 gift voucher from an online retailer for alerting them to this.
Shocking stuff really.
DISCLAIMER - I need to point out that Frontpage was on the standard build PC I was given in those days, not of my own choice!
At a university no less, which will remain nameless, they had all their action queries being passed through the URL instead of form posted.
The thing worked a treat until Google Bot came along and ran through all of their URLs and wiped their database.
In 2007 a DOD website for a fairly large agency had a misconfiguration resulting in the IIS web server serving up raw code and the home page had hard coded username/password and database server information in it. Fortunately it was caught rather quickly but I did witness it and it was extremely shocking. Needless to say their website was taken offline by network engineers until the developers fixed the bad code.
I used to work for a point-of-sale company. Their software was used by a lot of pizza joints.
It was up to the customer to change the default passwords. The default information is printed in the user manuals and such. :)
Well, some kids who worked at one of these pizza joints guessed they hadn't change the root password (Unix/Linux based system). They then proceeded to buy him and his friends free delivered pizza to his house for close to a year before the pizza joint noticed. It makes me laugh everytime I think about that job. :)
Once noticed this on the URL of a web-site.
http://www.somewebsite.com/mypage.asp?param1=x&param2=y&admin=0
Changing the last parameter to admin=1 gave me admin privileges. If you are going to blindly trust user input at least don't telegraph that you are doing it!
A Norwegian pizza delivery had a security hole where you could order negative amounts of pizzas at their new and shiny internet portal and get them for free.
The Chinese filtering software -- Green Dam's official website has server mod_status info wide open for public amusement.
For the curious:
http://www.lssw365.net/server-status
For some reason, you might want to press stop button shortly after loading, or else it just says connection reset for some reason...
Plaintext shipment of username list to the browser for JavaScript autocomplete, coupled with the ability to view users data by tweaking the URL querystring with the unique user id, which could get gleaned from said autocomplete feature.
During a time I was having... creative differences... with a community site that I helped build, one of the other coders added a new PHP file that lists files in the approval queue that also had a link to delete each file.
Unfortunately, this script used the whole security through obscurity concept.
Somehow, a web crawler found this page and followed all the delete links.
Needless to say, scripts that modify metadata or delete files now require logins.
P.S. I had nothing to do with it and wasn't even aware of this script's existence until one of the then-current staff told me what happened. I actually work for this site again now, in part to make sure things like this don't happen again.
The least forgivable security hole, and unfortunately a very common and easy to find one at that, is Google hacking. Case in point:
http://www.google.com/search?q=inurl%3Aselect+inurl%3A%2520+inurl%3Afrom+inurl%3Awhere
It's amazing how many pages on the Internet, government sites in particular, pass an SQL query through the query string. It's the worst form of SQL injection, and it takes no effort at all to find vulnerable sites.
With minor tweaks, I've been able to find unprotected installations of phpMyAdmin, unprotected installations of MySQL, query strings containing usernames and passwords, etc.
Years ago a school hosted a learning platform website with the ability to upload .PHP files to the website which you could execute afterward, so they gave you full access to the whole website. Haven't been discovered by any other student and I think that mistake is still present.
News Headline that's in the spirit of this thread... on today's front page of /.
ISP Emails Customer Database To Thousands
A couple of years ago a friend gave me an old axe-head that he'd found, hoping to be told it was some ancient artefact. So, a search on Google for some likely website to help in the identification gave me a link to a museum website somewhere in the Midlands (UK).
Except the page it dropped me on gave me full administrator rights over the entire site. Being a responsible type, I changed the name of the account owner, just so they'd know I wasn't talking rubbish and sent them an email suggesting they plug whatever hole it was that let me in, before somebody more malicious found it.
Needless to say I received a very thankful email from site owner, who'd been assured by the developer that the fault had been found and fixed. Although you have to wonder about the abilities of someone who's that careless.
Surprised no one has brought up social engineering, but I got a kick out of this article.
Summary: malicious users can buy a few dozen flash drives, load them with an auto-run virus or trojan, then sprinkle said flash drives in a company's parking lot late at night. Next day, everyone shows up to work, stumble on the shiny, candy-shaped, irresistable hardware and say to themselves "oh wow, free flash drive, I wonder what's on it!" -- 20 minutes later the entire company's network is hosed.
It wasn't that bad in my case, because the data wasn't that sensitive:
I was given an Excel file overflowing with macros to update, each sheet was locked and the macros section was password protected. I was given the passwords, but I figured I may as well try to crack it anyway.
I found a program to do it in about ten minutes, and most of that was probably just download time. What was this miracle product that can break through Excel security so quickly and easily? OpenOffice.Org.
I'm not sure if Office 2007 has improved upon this at all, but it scares me how many non-technical people are probably using Excel for manipulating sensitive information and thinking it's secure. Then again those types of people probably don't even know about the "security" features it offers anyway.
I think the blank username / password field for superuser access is by far the worst. But one I have seen myself was
if (password.equals(requestpassword) || username.equals(requestusername))
{
login = true;
}
Too bad one operator makes such a big difference.
I was browsing a shopping website, and when I typed in my email address, I noticed the address entry page just had in the URL "?nOrderID=301".
Alight then. I change that number to 99, and guess what? I get the name, address and phone number of some lady who lives in Bend, OR.
I did email the site admin a few weeks ago, and he didn't sound very happy about it, but it still hasn't been fixed...
That, and for a while the company's I work for entire employee information list (everything about the employee from address to SSN to pay) was stored in a password protected Access database.
Use your favorite search engine and look up how to recover access database passwords. Yep.
Drag and drop it into this, and you get the password. A five letter dictionary word.
Last year, I discovered that the website used to handle our checks/statements for the company I was working for was riddled with SQL injection holes.
Needless to say, they fixed their holes pretty quickly.
For the master list of security holes (and other computer risks) visit http://catless.ncl.ac.uk/Risks
We had a customer that made it a requirement to auto-login based on specific HTTP referrer's. So you and I have to login, but if you clicked on a link from a specific website, you are automatically logged in under a default user.
We had an old computer cluster that wasn't running in one of the labs I worked in. A couple undergrads thought it would be fun to get it up and running so they could learn a little parallel computing. Well they got it running and it turned out to be pretty useful.
One day I came in and was checking out the stats...It was running at 100%. Now this was a 24 node cluster and there were only 3 of us that ever used it so it was a little strange that it was running at this load. I started playing with it, trying to figure out what was loading it...turned out someone had gained access and was using it as their own little porn server and spammer. I asked the undergrads what kind of security they put on it, they looked at me and said "Security? We didn't think it would need any."
I threw a password on it and that was that. The person that was using it as a porn server turned out to be a friend of one of the undergrads.
My vote's for Ken Thompson's "back door" into UNIX.
Here's a link where someone's learning more about it: http://stackoverflow.com/questions/781718/thompsons-trojan-compiler
The reason I think it's the worst is that this was back in the day when judges and such thought the best way to make progress against this sort of thing was to discuss it openly.
All that did was teach a bunch of script-kiddies a new and very powerful trick.
public class AuthenticationServlet extends HttpServlet
{
private String userName;
private String password;
protected doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
{
userName = request.getParameter("userName");
password = request.getParameter("password");
authenticateUser(userName,password);
......
}
}
Apparently as someone figured out during automated load testing, singletons and lack of synchronization can cause security issues.
Once I worked with a firm to which I had to share information through encryption. They provided me with a GPG key pair - both their public and private keys instead of just sharing the public key and the info that was highly confidential.
I had to explain them that this process was wrong and they realized that they had been doing this for a long time.
The worst security hole I have ever seen is when people don't use a master password on their firefox account even though they are having it save all their passwords. This means that anyone who can get to your account files can steal all your passwords. USE A MASTER PASSWORD.
I've heard that Turbo Tax used to send your SSN in a plain text file when you submit your return electronically. That doesn't seem like a great idea.
I also know of a company that stores credit card info in plain text CSV files on the desktop. They then get sent via FTP to the payment gateway....
The worst security hole I've ever seen was actually coded by yours truly and caused the Google Bot to delete my entire database.
Back when I was first learning Classic ASP, I coded my own basic blog application. The directory with all the admin scripts was protected by NTLM on IIS. One day I moved to a new server and forgot to re-protect the directory in IIS (oops).
The blog home page had a link to the main admin screen, and the main admin screen had a DELETE LINK for each record (with no confirmation).
One day I found every record in the database deleted (hundreds of personal entries). I thought some reader had broke into the site and maliciously deleted every record.
I came to find out from the logs: The Google Bot had crawled the site, followed the admin link, and the proceeded to follow all the DELETE LINKS, thereby deleting every record in the database. I felt I deserved the Dumbass of the Year award getting inadvertently compromised by the Google Bot.
Thankfully I had backups.
We had a nice one at a store I used to work at. Doors to non-public access areas had keypads, so you were supposed to have to enter a pin code to gain access. However, you could just press # and the doors would open, a fact that we liked since it was much easier to hit # than a 6 digit pin code.
Went to a pay site for car dealers that charged a lot for a membership. Just tried "test" for the username and "Test1" for the password. I was in.
Default login credentials, especially when the are admin/root and password.
Microsoft Bob
(Credit: Dan's 20th Century Abandonware)
If you enter your password incorrectly a third time, you are asked if you have forgotten your password.
But instead of having security, like continuing to prompt for the correct password until it's entered or locking you out after a number of incorrect attempts, you can enter any new password and it will replace the original one! Anyone can do this with any password "protected" Microsoft Bob account.
There is no prior authentication required. his means User1 could change their own password just by mistyping their password three times then entering a new password the fourth time -- never having to use "change password."
It also means that User1 could change the passwords of User2, User3... in exactly the same way. Any user can change any other user's password just by mistyping it three times then entering a new password when prompted -- and then they can access the account.
In PHP this was in the first include file:
extract($_GET);
extract($_POST);
It allowed overwriting of variables that were not called by _GET or _POST.
A friend of mine once knew of a site that passed SQL queries as GET arguments. You know some people had some fun with that.
The worst security hole is to use Internet Explorer's option to remember your passwords. What people don't realize is that tools such as this one by Nirsoft can reveal all your passwords.
At my first job I started out as an intern in the IT Security department. I was tasked with automating network and application access to various user accounts as each user moved around to different departments / roles. That being said I had access to some basic tools, such as Query Analyzer, and just a few databases, but not much else. The company generally kept everything locked down so there were always permissions to reset and grant and such.
At the job all part time people were given and required to use a small VB fat client application to track hours worked, and at the end of the week a button became available to show the logged in user the amount of hours that they had worked for the week and the amount that they would be paid that week.
Out of sheer boredom one day I stumbled across the directory that the small time tracking application resided in on the network, and noticed there was only one other file besides the EXE in that directory, a settings.ini file.
Sure enough, after opening the file there was the connection string in bright shining plain text; user, password, database name, server and all.
At this point I was thinking no way would this be the real information, but after firing up Query Analyzer, and entering the ini settings I was in to the main production database that had every piece of data anyone would ever need to give themselves a raise. Full read and write access to boot.
I ended up showing my boss a query of who made what and he calmly told me to forward it to the director of HR.
Let me tell you I have never had a faster, in person response to any other email in my life.
The next day I came into work the time tracking application had an update, and alas no more settings.ini file.
The worst I personally found was at a university which used machines running X for all the systems (including professors' offices). A single server hosted all these X sessions...
Amusingly, you could launch a new X application (clock being a favorite, but any X application would work) and choose the terminal it was displayed on. With a quick script, you could launch it on every computer on every lab/office on campus...
Of course, the application which really exposed this security hole was a fake shell login, the inputs from which were recorded to a file.
It ran for a week and scarfed up hundreds of student and professor usernames and passwords, and generated a couple of EXTREMELY unhappy administrators.
In signed code:
System.setSecurityManager(null);
(You can google code search for that.) Removes all Java security restrictions from all code running in the process. Possibly not thought through very well.
Windows 95 and 98 had the best bug ever. If you just pressed cancel you would be logged in with admin priviliges :) Had a great time at my dads work back then :D
"select * from LoginMaster where UserId='" + txtUserId.Text + "'
and Password='" + txtPassword.Text + "';"
I have seen this in a production web site, which is running MLM business. Above Sql Statement is VERY VERY vulnerable to SQL injection.
I will also list here HACME BANK. According to the site Hacme Bank is :
Hacme Bank™ is designed to teach application developers, programmers, architects and security professionals how to create secure software. Hacme Bank simulates a "real-world" web services-enabled online banking application, which was built with a number of known and common vulnerabilities. This allows users to attempt real exploits against a web application and thus learn the specifics of the issue and how best to fix it. The web services exposed by Hacme Bank are used by our other testing applications including Hacme Books and Hacme Travel.
My bestfriend's brother just finished his studies. He claimed a few days ago to everyone around he's a "webmaster" and "webdevelopper". I told him his sites were bad and unsecure. "Hack them" he answered. 10 minutes later I sent him the whole source code of his 4 sites :) He was doing something like
< ? include $_GET['inc']; ? >"
The more cheeky you are the more prone you are to attacks :)
On some Unix machines (certainly all SunOS) you could link a setuid shell script to a file called "-i". The shell script would interpret the filename as it's first argument and run "sh -i" = an interactive shell, with permission of whoever owned the setuid file.
Since most setuid shell scripts ran as root, to give you permission to do something that needed root access like eject a CD or load a tape. This meant it was trivial to get admin on most university Unix machines in the 1990s.
As a note for all readers, informed or otherwise: I just bought an 800 page, 2008 copyright book on the subject from a major - In the preface the author does a "hey, wait a minute .." in which it is noted in detail that more than one security professional with heavy credentials and field experience had been, ahem, rendered moot, ... big-time because they had seen some intrusion something or other that looked relatively novice.
Trying it as seemingly harmless there would be formal proceedings due to un-authorized activity. Being a professional, some of them were ruined.
The last intrusion I paid any attention to involved a major banking service that has been around so long that citizens rarely hear their brand name. All data was available un-enciphered across the shop - but, bizarre to the uninformed is that this banking entity had become a "clearing house" for ( i don't know statistics but it is over half ) of credit-card transaction processing for more than one retail-branded credit provider.
The intruders just placed a ( device ) at the drop. [ that's telco for the line from the world at the point of entry ] no fancy or sophisticated traffic monitoring tools, just the basic. I suggest everyone monitor all credit activity since Feb of this year: What was gained was valid cc#'s matched to valid names on currently active and valid credit accounts.
Unprecedented.
As usual, it's the person with no expertise in security running a shop from a position of management authority. The engineering term is "failure mode analysis" ...
Social Engineering:
<Cthon98> hey, if you type in your pw, it will show as stars
<Cthon98> ********* see!
<AzureDiamond> hunter2
<AzureDiamond> doesnt look like stars to me
<Cthon98> <AzureDiamond> *******
<Cthon98> thats what I see
<AzureDiamond> oh, really?
<Cthon98> Absolutely
<AzureDiamond> you can go hunter2 my hunter2-ing hunter2
<AzureDiamond> haha, does that look funny to you?
<Cthon98> lol, yes. See, when YOU type hunter2, it shows to us as *******
<AzureDiamond> thats neat, I didnt know IRC did that
<Cthon98> yep, no matter how many times you type hunter2, it will show to us as *******
<AzureDiamond> awesome!
<AzureDiamond> wait, how do you know my pw?
<Cthon98> er, I just copy pasted YOUR ******'s and it appears to YOU as hunter2 cause its your pw
<AzureDiamond> oh, ok.
From bash.org
Select * from user where user_id = '*userId*' and access_level = 0 or access_level = 1;
If the query returned any rows, they were admitted to the system. Parentheses around "access_level = 0 or access_level = 1" would have done what they intended. Instead, as long as there was some user with an access_level of 1, anybody could get in.
'Unified login' between two systems - which exposed the password as free text.........IN THE URL!!
This was a government project which had been 'offshored'. Luckily it was noticed v. early on. The scary thing is the developers didn't see that much of a problem with it - really makes you wonder.
This was a long time ago... but DEC's VAX system used to be shipped with the accounts:
login:SYSTEM password:MANAGER
and login:FIELD password:SERVICE
Most sysadmins would know about the SYSTEM account and most (but not all) would change it. However not everyone knew about the FIELD account which also had SYSTEM privileges.
One of the utility companies I have doesn't use autocomplete="off" in their credit card form.
Sure, they don't store your credit card info (a good thing), but imagine how horrified I was when I paid my 2nd months bill and my browser offered to fill in the entire credit card number for me...
When I first joined the company I currently work at, my boss was looking over the existing e-commerce web site of a prospective new client. This was in the fairly early days of both IIS and e-commerce, and security was, shall we say, less than stringent.
To cut a long story short, he altered a URL (just out of curiosity), and realised that directory browsing wasn't turned off, so you could just cut the page name off the end of the URL and see all the files on the web server.
We ended up browsing a folder containing an Access database, which we downloaded. It was the entire e-commerce customer/order database, replete with several thousand unencrypted credit card numbers.
"Pedo mellon a minno", "Speak friend and enter", on the gates of Moria.
The best error in the style of "web programming security 101" was a recruitment agency whose search page offered a "next page" link which was simply the SQL statement to fetch more job listings. You could easy change this URL to be any other SQL statement, including "drop table X". If you did that, their entire web site would die.
A company who sold computers had a website built with FrontPage with everyone having full access.
A "secured" website where every pages were encrypted but the login page!
login.jsp?type=user&redirct=/home.jsp&userid=12345&username=username&password=mypassword
This happened on a very big website. My jaw dropped when I seen this.
I hate to admit this .. but I found out how to hack VSS 2005 one day when I didn't have the admin password to a repository (the hate part is in having to use VSS :D )
If you create a local computer account with admin privileges that has the same name as the VSS account, and log on, VSS says:
"Hey great .. you are logged on to the computer with an account name that
I recognize as being the same as one of my accounts,
and your account has admin privileges on the computer ..
so I am going to bypass *my* security and give you admin
privileges to all of VSS!!!!"
That hack was about the first link I saw on google when trying to crack the VSS password
Of course it doesn't give you the VSS password that you are missing
The entire Classic ASP shopping cart "Comersus". The whole thing is a mess of spaghetti code and all the SQL statements are ripe for SQL injection since there Is no filtering done whatsoever. Sadly I had the misfortune of dealing with this "application" for almost two years and it was an absolute nightmare!
At my old uni, they stored users passwords in plain-text in cookies.
This in itself is horrible, but to add insult to injury, they stored them in cookies for *.university.edu.au. Now of course, all the students and staff's pages are on something like university.edu.au/~user.
<?php
var_dump($_COOKIE); // oops.
Who can forget the classic Windows 98 security hole?
Copying password text *** and pasting it into a word processor would show you the password on just about anything.
Hitting the cancel button on Windows 98 login screen would give you access to the system anyway.
1-800 dominos will give unlisted address's related to any target phone number. When prompted if you are calling about the phone number you called from select no. The system will prompt you for a new phone number, the system will then read back to you the name and address that's associated to this phone number. Enter in your target's phone number and you now have their name and address. This is pretty common with automated ordering systems and if dominos has fixed this there are literally hundreds more.
There are many sites that use a proxy file to pipe images or other files through. Without checking the path for validity.
So.
getfile.php?file=../../../../etc/passwd
or
getfile.php?file=../index.php (in plain text with all the passwords)
It's amazing how many sites still have this flaw. Just google for getfile.php and you can have a field day breaking into boxes.
Some friends were in a class together at university. They discovered the professor posted all the homework solutions, even for homeworks that were not due yet, had not been graded, or hadn't even been assigned. The professor just had links or solutions to them embedded in the class web page, and would comment them out in an HTML comment until the assignment had been collected and graded.
In one forum I've got readonly access to hidden threads and administrative interface just by replacing my username in cookies by admin's one, not changing password.
On a free web-host I tried, there was a logical error in the "Forgot Password" method for e-mailing you your password -- if you didn't enter an e-mail address (a secondary e-mail was optional), it e-mailed the password for the primary address for every single user who didn't provide a secondary e-mail.
I and hundreds of others one day received an e-mail with hundreds of usernames and passwords, with the passwords in plaintext.
Windows 95 had the option to require a password to unlock the screensaver. However, using ctrl+alt+del you could just kill the screensaver.
XSS is what I love to find on a web site.
Here is a link to a log of my findings:
All: http://xssed.com/archive/author=Dr.Optix
Only the specials: http://xssed.com/archive/special=1/author=Dr.Optix/
Have fun browsing them!
On a website I worked on, they used the username and password as combined primary key. The username was automatically your last name and not required to be unique.
Which leaves only one thing that could be unique...
Well simply a
exec unchecked_parameter_from_the_web
in Python to parse an dictionary literal which was given by the user. That was really scary.
Paraphrasing from memory here, but it's close...
<form action="secretpage.html" id="authentication"
onsubmit="return document.forms.authentication.password.value == 's3cr3t'">
Enter password: <input type="password" name="password"><br>
<input type="submit" name="Login" >
</form>
A guy I know used this to protect the "private area" of his web site. At first, he didn't want to believe me that even his browser had this wonky "view source" function.
Thinking about this, the worst security hole I've ever seen was when the guy who adminned the electronic door lock said "What do you mean, the lock doesn't know about public holidays"?
Yep, every Monday-FRiday that happened to be a public holiday since the door system had been installed saw the front door unlocked 08:00-17:30.
An application using faces and managedbeans. The bean used to edit the user already logged in was the same used by the self-register form, where two hidden fields were the only difference. Meaning? If you get someone's document number (equivalent to SSN in USA), you could actually change their password.
I once had a job where there was a security layer written in Java code that checked if the user had access to edit a DB table column. This is what the function looked like:
public boolean canEdit(User user, DBColumn column) {
if(true) {
return true;
} else {
return false;
}
}
My old school had the student's passwords the same as their username, PLUS it was easy to get their usernames (a number, ex 123233), then you could hit add column and find out the first and last name of the students, as well as their usernames. So it was easy to put random garbage in their accounts and make them think there was a "ghost in the machine"
A legacy app I ported a few years back used a 3rd party callback system for handling payments. Thing was, the callback script didn't check that the amount paid was equal to the price of the order, so it was possible to purchase any product on the site for £0.01 by using Firebug to edit the contents of the 'amount' field on the payment page.
The worst security hole I've ever seen was build into an earlier version of MS SQL Server, version 7.0 or 2000, can't remember exactly.
When installing this version of SQL Server, the installer would by default give the "sa" account a blank password !!! (the sa account is the SQL Administrator account, it can do anything on the server)
This gave basically anyone access to an SQL server that wasn't protected by a firewall.
But it gets worse.
At that time, many SQL servers were installed to run the service under "local system" authentication, giving the SQL server process unlimited control over the system.
Since you can create COM objects in SQL server you suddenly had complete access over the computer where the SQL server was running.
Many a site has been hacked this way.
Not a technical security hole, but a security hole nonetheless:
My banking card was recently eaten by an ATM and it took some weeks before I got it back. When it finally arrived at the bank, a woman from the bank called me to ask whether I wanted to pick up my card or have them send it to me via mail. She also told me that if they would send it they would disable it until I called them to confirm that it arrived safely at my home.
I got the card with a short letter with exact contact information including a note saying I needed to call to re-enable the card. I just called there, gave them my name and account number, BOTH OF WHICH WAS PRINTED ON THE CARD ITSELF and they re-enabled the card.
Basically, if anybody else had snatched that letter, they would have had the card and the number of the bank as well as all the information needed to convince the bank that it was actually me calling. So, not a very good security system there.
Our phones at work.
You have to log in using your 4 digit ID, then push # and enter your 4 digit password followed by #. But if you don't enter any password and push #, it logs you in.
Failphone fails.
I broke into http://dev.superuser.com/ by changing the domain of my ServerFault beta access cookie. (they've fixed it now)
I worked on a site that used the username and password as the row ID in a database. This was compounded when the username was automatically and unchangeably your last name. The site had 900 Smith's, each with their own unique password...
I was recently asked to code review a companies website, with an eye to my employer taking the website on as a maintenance project.
It didn't take me long to discover the plain text file sitting under the website root containing about 6,000 customers credit card details, including billing name and address and CVV code. It wasn't even imaginatively named!
That was the worst issue with that site, but it was also riddled with SQL injection problems as well.
We politely indicated these issues and the website owner bumped it back to the original developer for an explanation.
Not the worst, but bad enough to cause some real damage. You would be surprised how often this is overlooked. Especially when people are using some of these popular frameworks,
yourwebapp.com/items/edit.php?id=4
yourwebapp.com/items/delete.php?id=4
Not making sure that the owner of the items is the one requesting the page. Meaning, you can log into your account and then edit or delete anyone's items in the whole application.
A simple check can prevent a lot of damage.
$item = // find your item by the $_GET[ 'id' ];
if( $_SESSION[ 'user_id' ] != $item[ 'user_id' ] ){
// kick em out they dont belong...
}
I had Joe X's former home address, and needed to know his newer current address in the same city, but had no way to contact him. I figured he was receiving the usual daily pile of mail order catalogs, so I arbitrarily called the 800 number for See's Candies (as opposed to Victoria's Secret, or Swiss Colony, or any other big mailer):
Me: "Hi, I'm Joe X. I think you've got me on your mailing list twice, at both my old address and my new address. Does your computer show me at [old address] or at [fake address]?"
Operator: "No, we show you at [new address]."
In the 1970's Stanford had IBM 2741 hardcopy terminals spread around campus networked to an IBM 360/67. Account passwords were three characters. During logon, the password prompt would overprint a three-position blob of about nine random uppercase characters, so the subsequently-typed password would supposedly be masked by the blob. However, everyone typed their passwords in lowercase, which were trivial to discern against the uppercase background blob. That meant you could usually walk up to any terminal, peruse the hardcopy typically left behind by the previous user, and easily logon with their account and password.
I remember that the Common App website for applying to colleges had this "security" feature that announced it would log you off after a certain amount of time. But to that, they used an alert box which if you didn't actually respond to, would pause the countdown making your session indefinite.
Not the worst but one that was a good laugh was the Android OS reboot bug. When users had the G1 phones they could type "reboot" from anywhere on the phone (ie: sms or emails) and the phone would reboot.
There was a place where the administrator set up all users home-directories' in a shared FAT32 folder.
if( $session['role'] = "admin" ) //grant admin rights
Just one character off ("=" instead of "==" ) is all it takes to grant admin rights to anyone who is logged in. Your truly is guilty.
I have seen top-managers of a high-end French defense contractor using Skype for very confidential talks (for the record, Skype uses the long-time-ago broken RC4 encryption algorithm).
I guess that their ignorance can be pardonned as on the top of that they also used Windows and MS-Word (for the record, MS-Word keeps an history of all the documents previously written with this template).
This raises some interesting questions regarding where the tax-payer money goes -and if it is wisely used.
I once had the pleasure of attempting to secure a site (ASP Classic) which "required" a password to access the admin interface. Of course, if you just went to the address of one of the admin pages, you could do whatever you wanted, logged in or not.
And they wondered how they got hacked.
In a login for, there was an hidden field which let the "webmaster" choose the file to be included on success and failure.
Yep, /etc/password worked.
Or in a "log" directory, there was order-xxx.asc AND order-xxx.txt which contains card numbers including check number and validation date.
It is not security hole, but security shame of one of corporations marketing their own products as high security (and that is one of theirs main feature)
It is about "secure login" on pages for there partners. And here it goes:
First time you got password in plain text by email and once you log in you of course do not read blah blah on first screen, you just run for what are you looking for (doc or software) and then log out.
But here is the trick, next time, you are trying log in your password does not work any more, because you should have new password they post each time on website under your personal profile. So after exchange of few emails they send me (over email) list of approx 30 enumerated one time passwords and I can use it only once each time . (this took me one week and couple of emails to renegotiate for this list)
So I printed this list of passwords, stick it on wall in front of my desk and I black out one password using pen each time I log in. I do not care for if anybody walking by my desk see this list.
One security hole that makes me cringe is in a legacy application I was once maintaining there was a settings.ini file with the database credintials in plain text, and all user passwords are stored in the database in plain text.
Most other security holes I've seen were at my high school and college.
First off, I figured out I could shut down the internet for my school simply by doing a (very easy) ping flood attack. And not just my high schools internet though, the entire school system including part of the college. There was absolutely no rate limiting. They ended up fixing it after I demonstrated it. (as a side note, the "publicity" from that made me get hired at my first programming job)
The second, and one that had much more possibilities was this:
Ok, so every computer in the school was connected to a domain and such. So, when you logged onto a computer, it would copy down a generic user directory(including application data, etc folders) and then proceed with the login. Some people had their own logins other than the generic "student" account for one reason or another. Well, while I was browsing the public server where everything was shared on, I found a /users directory. Upon looking at it I discovered froma generic student account I had read-write to every users directory, including teachers, administrator, and the generic student account.
For April Fools I had planned to write a simple batch file or small program which popped up something like Class of 09 rocks! upon login of everyone just to demonstrate it, but I chickened out.. I also never told the administrator either, so the gaping security hole is still there probably.
I've heard about a programmer working at a bank, that - whysoever - calculated their internals (including account balances) with a precision of 16 positions after decimal point.
So this guy changed the bank transfer procedure to transfer 0.00001 dollars of each transaction to his own account, the rest to the original destination. I think they got him quite fast, but I have to admit that I found his idea quite good when I heard of it for the first time.
About 3 years ago I built a site for a somewhat large non-profit organization in our state. When it came time to deploy the application to their web host server, I noticed an odd file named "cc.txt" or something obvious like that in their public site. It was under their web root, was getting served, and was a csv file of all their donor's names, addresses, credit card numbers, expiration dates, and CVV/CVC codes. I cannot count the number of times I brought the issue up - first to my boss, then our company accountant, the client's IT director, finally the client's President. That was 3 years ago. The file is still being served, it can even be googled. And it's been updated. I tend not to respond to their donation solicitations when I get them.
My bank once detected a "suspicious transaction" on my debit card. They recommended I cancel it and get a new one.
While I was waiting for the new card, I needed to make a withdrawal. So I walked into the bank, gave the a woman my old card, and explained, "This card was recently canceled, but I need some money. Could you give some from this account?"
As I walked out of the bank, cash in pocket, I realized I had just taken money from an account using a canceled card without ever being asked to show any form of ID.
I once took over development of a system that was in use by 200 clients around the country, and it had hard coded passwords. Yup, the code actually said:
if password = "a"
And last year I left an automotive ERP company whose hundreds of clients all have the same admin password on their servers. I'm guessing they didn't change them all after I left.
When I was in middle school or so, the county school system set up all their "security" software to keep the kids off parts of the Internet or from changing configuration settings and installing junk. Besides the fact that the software was pretty marginal (some shell modifications which could be bypassed with a clever right-click in a File > Save box) they set the teachers' password to teach.
Yeah, that was real secure.
I once found a bug in a local Internet portal called ROL.RO (Romania OnLine - owned at that time by PCNET). They had a free webmail system. I wanted a certain (easy to guess which) username, but it was already taken.
By curiosity I went to the "forgot my password" page entering my desired (but taken) username. Then, upon submitting, I was presented with the security question which was blank.
Wow... let's see if they are lame. I made sure the answer textbox was empty, and I submitted
"CONGRATULATIONS, ENTER YOUR NEW PASSWORD".
I entered a password and hijacked the account.
What probably happened in their ... PHP scripts was that they compared the null from the database (in the answer - of course they kept it in clear text) to the empty string submitted by me. Having them "equal" lead me to the next step, the reset of the password.
Yes, lame.
When you lost your password and the recovery form ask for the username and your email. And does not verify the email and send in the password to the gived email.
edit/story:
It was on a local TV paid/subscription based website. It was easy to find username, somany peaple use first name. Today the tv channel has gone bankrupt(for other reasons, like lack of professionalism).
The fact that you can often bypass security or intended functionality altogether on most unencrypted applications or files by just using a file/process hex editor. Sure it's great to give yourself infinite gold or god mode on most games - online or off, but it's also great to just grab or edit values as you wish, including passwords. In fact sometimes all you need is Notepad. Luckily Notepad isn't on the list of federally controlled computer applications under the DMCA... yet.
Edit: I'm referring to exploiting the "Emperor's New Clothes" scenario with recognizing security defects with only the most simple of tools. A scenario so common throughout the programming or consumer community across any language or platform that it might as well be a universal standard.
A while ago there was a security hole in windows in the JPG image loading library. Infected by the image in e-mail. ack
A friend of mine did his login via GET. Needless to say he learned the lesson the hard way.
Testing some bank teller software, I called the tech desk to arrange a dialup IP session. 'Which system do you want to connect to, production or test?'
True story.
I've had at least 1 previous co-worker who probably qualified as that.
There's a bank that offer some services via its web site. The developers considered any one who had logged in as a valid user for the entire system, and they use URLs to identify the account number, so simply just changing the ID on the URL and you can view other accounts' balances.
It's really very bad for a web developer who think authentication and authorization are the same thing.
Also it's good that the bank doesn't transfer money via its website, otherwise some people will be rich ;-)
One of the simplest, yet really cost worthy is:
Payment systems that use engines such as PayPal can be flawed because the response back from PayPal after payment was successful is not checked as it should be.
For example:
I can go on to some CD purchase website and add some content to the cart, then during the checkout stages there's usually a form on the page that has been populated with fields for paypal, and a submit button to "Pay"..
Using a DOM Editor I can go into the form "live" and change the value from £899.00 to £0.01 and then click submit...
When I'm on the PayPal side of things I can see that the amount is 1 penny, so I pay that and PayPal redirects some parameters to the initial purchase site, who only validates parameters such as payment_status=1, etc., etc. and do not validate the amount paid.
This can be costly if they do not have sufficient logging in place or products are automatically dispatched.
The worst kind of sites are sites who deliver applications, software, music, etc.
The biggest security hole I've seen recently recently is the lock screen bug in iOS 4 (iPhone), granting anybody instant access to any iPhone (make calls, address books, call logs, photos).
http://www.pcworld.com/article/208813/ios_4_lock_screen_security_flaw_grants_access_to_contacts.html
The worst security hole I've seen was from a (very very bad) hosting company. And even worse it was just some months ago (summer 2010)! You had to first connect to your hosting package control panel (you needed valid credentials). Once logged in all you had to change was the id GET token from the URL and voilà, you're in the control panel of another user! You have access (save/edit/delete) to emails, files, databases. The ids were sequential so you only have to do +1 and you're in the next account. I hope someone have been fired for this!
It was one of the many WTF I've experienced with them! Fortunately I wasn't one of their customers!
You know how you read all the time about how a large corporation has had their customer's personal identification stolen? (And in fact it's happened to me twice that I know of - once from my health insurance company, once from my life insurance company)This is often from stealing the database backup tapes which are unencrypted and reading the unecrypted personal information stored therein.
Because the username and the password are the same, and it was happening for the production website not for a testing version.
I have seen a lot of customer projects which were sent to support and which contained IP addresses, user names and passwords to live SQL Servers databases.
The company I work for has so many security mistakes... Here are some of the worse:
Epic fail.
My friend once made a forum script in PHP. Passwords were kept as a plain text file named pass.txt. Of course that file was accessible for everyone.
Not controlling logical operator (OR) in Password data entry element. By using it, every one can easily pass the other where conditions. For, the select query will be like this one:
select *
from TheTable
where UserName=@id And Password=@pass OR 1=1
Visited the contact page of a pretty well known online store and scrolled down, searching for a phone number. Instead I found an upload form which accepted all file types and actually put the uploaded files in the root folder of the website, meaning that if one uploaded a file called test.php, it would be callable by the url mydomain.com/test.php :)
Since they used osCommerce (open source), putting together a script that would fetch out all database conection details and then download their complete customer data table would be a less then a five-minute job for anyone that had enough IQ to google things.
I contacted them and ended up with a discount coupon for my next purchase, and they removed the upload form within minutes.
I worked on a popular casino site. The flash front end is not just a mear dumb terminal. They had a visual bug of which incorrectly managed avatar images. During the time me and my buddy we fixing this - we fell upon a completely separate flaw.
We watched the traffic from client to server and discovered it was base64 encoded. Thinking it would help, built a simple python terminal script of which would tap into it. We found out the client would send commands and logic information to the server.
Within minutes I had the ability to simply type in the amount of chips I had, who won and what hand I had, simply by writing it in plain text!
Another major flaw - User passwords were encrypted, admin passwords were not using the same hole as before, I gained access to database info, found admin logins and took over the system.
I'd been informed that the our switchboard department's bleep system had a web front-end that could be used to send messages though it was ugly and not very user friendly so I wanted to have a look and see if we could use a form on our main intranet site and submit the values via our server to theirs.
There was a simple username/password form to access the system with User and Admin roles so I took a look to see how I'd impliment handling the security. I discovered the two following cookies being stored:
Username: [username I had used]
Admin: False
Just to make sure it was as bad as I thought I opened up Firefox, gave it the url, created 2 cookies, my username and Admin: True and lo and behold I had Admin access. Just to check it out I created a new user without any problems. To make matters worse having the username locally meant that the log would show my actions to be by any one I wanted to give it.
Security through obscurity doesn't work but it works far less when you give people everything they need on a silver platter.
There is a cloud-rendering library licensed for $2500 with limited work time (like one minute) until registered. And evaluation demo that worked indefinitely. Searching exe contents for a word "demo" revealed "[Product name] Demo" and hex symbols string nearby. Yes, that was login and password.