Nishant Kaushik has another good post on Identity management... this time talking more about Identity as a service. People should make it brain dead easy for developers to integrate enterprise identity management into your applications, regardless of which system you use. He also linked to his presentation. I liked it a lot... I think its a great idea... but something about it gave me a chuckle.
At present, there are at least nine identity "standards": CardSpace, LDAP, OpenID, SXIP, SAML, SPML, WS-*, XACML, XDAS... not to mention basic username/password authentication, custom modules, and proprietary systems like SiteMinder. And even the most commonly used standards are a pain to develop with.
The solution -- which I fully support -- appears to be to wrap all the "standards" in a functional, proprietary API. Then you only need to know one API, and have one repository, for all your identity management needs.
Makes you wonder why people bother to call them "standard," doesn't it?
I remember three years ago at Stellent, Sam White was so fed up with so many security standards, he sketched out a version of the Content Server that did nothing but authentication and authorization services. A bit ahead of its time, because it took till now for the market to beg for something like this.
Anyway, good luck to Nishant...
UPDATE: Gerald Beuchelt is upset because my list above isn't exhaustive, it mixes pure identity protocols with partial ones, and that I dared to include SXIP. Then he misquotes me. I told him to chill. Although I do empathize that he's frustrated... many of us are.
Some of you may have noticed that my "comments" form is looking a bit weird lately... that's because I'm getting WAAAAY too much comments SPAM, and needed to experiment with CAPTCHAs. These are little forms that attempt to distinguish a SPAM robot from a real live human. I'm testing out several varieties to see which ones have been cracked, and which ones are relatively OK.
Naturally, there are many many problems with CAPTCHAs... if the test is too easy, spammers win. If its too hard, people can't solve it, and you don't get any comments. Not to mention its tricky to make one that works for blind and color blind users. And even the best CAPTCHA can be beaten by a "porn proxy": an evil site would offer something good for free (like porn) if a random user solves 5 CAPTCHAs... then the evil site re-uses those solved CAPTCHAs to put spam on somebody's web site.
Others say CAPTCHAs are pointless, and the only real way to prevent comment spam is to make people pay to comment. This could be a micropayment of 2 pennies... or it could be a difficult problem to solve that costs the commenter 2 cents worth of electricity because the CPU is crunching numbers.
I love saying stuff like that...
This is along the same lines of the reCAPTCHA project... which uses the standard image recognition CAPTCHA, except these are images taked from actual books that computers can't read. In theory, you help digitize old books while you fight spam... but my log files says reCAPTCHA has either been hacked, Drupal's implementation is flawed, or reCAPTCHA is popular amongst "porn proxies." Too bad... it was a good idea.
Some sites, like Lifehacker, force you to earn a trusted user account before you can comment. I'm hoping such a solution isn't needed... and I can come up with something that is cross cultural, and fair to the visually impaired.
I'll keep y'all informed of what I eventually discover.
We knew it would happen some day... as soon as the Web 2.0 hype encouraged people to create REST and AJAX APIs, hackers would find fun new ways to abuse them... Today's security scare is brought to you by DNS Rebinding (Hat tip Artur Bergman).
The nifty things about AJAX is that it allows you to make XML requests back to the originating server. It won't let you make requests to other servers, only to the one you are connected to. So if you're browsing the google.com web site, you can only make AJAX requests to google.com. I always thought this same-origin policy was a bit restrictive, and probably wasn't as safe as everybody thought, so it always annoyed me. I usually choose remote scripting instead of AJAX for this reason.
Now it turns out you can completely hijack this same-origin policy with sneaky DNS settings... and an evil web site can use AJAX to connect to any resource behind your corporate firewall!
Lets assume you accidentally go to some evil web site, like evil.com. First, your computer translates evil.com into an IP address, such as 184.108.40.206. Normally, this IP address data is cached for a long time, but its possible to set up evil.com's DNS servers to expire the cache every 5 seconds. That means for every request, your browser needs to look up the IP address again.
So, lets say the hacker (or some robot) at evil.com notices you're on the site. It then changes the DNS address to something different... say 10.10.1.1, or any other IP address inside your corporate network. That means the next request you make to evil.com will be sent to an internal server instead.
Pretty evil, those guys at evil.com...
These attack forms are nothing new -- I covered a mundane variation of this in my security presentation at Crescendo 2006... but AJAX plus DNS rebinding makes this method even more attractive to hackers.
If you're running Stellent/Oracle, I'd HIGHLY recommend installing the HtmlPostAuthenticator component. If properly configured, it should really help mitigate attacks of this nature. This attack is also highly noisy, so unless the hacker knows your network very well, most intrusion detection systems should catch it eventually.
Anybody who knows web apps and security knows of the dangers of SQL injection attacks... many web apps are vulnerable to this. If you have a web form, and generate a SQL query with the data on that form -- without validating the data -- then you're open to attacks. People can inject whatever SQL they want into the web form, and trick your application into running their SQL instead of your SQL. This could cause data leaks, or even data deletion.
You can fix this problem simply by escaping all quotes in the data from the web form... as well as type checking dates and numbers. You may also need to count the parenthesis and remove SQL comments, depending on your application...
XPath injection works in an analogous way to SQL injection... the only different is that the injected attack has a different syntax. If your repository allows XPath query syntax, you'll need to do a lot more data validation to protect yourself...
Now, XPath is typically used to query single XML files. Very few people used it as a full query language to a database or content repository. In my humble opinion, that's for a damn good reason: XPath syntax is awkward and weird. Its totally a step backwards in both usability and performance... however, because of trendy new XML standards, XPath injection may be a bigger problem then you realize. You might be using XPath all over, or your repositories might allow XPath query syntax even if you don't use them.
Case in point, I'd highly recommend that anybody who uses that rotten JSR 170 protocol for content management PLEASE look long and hard at how secure your system actually is... You know who you are... I'd start by reading the XPath Injection Attacks article from IBM.
Bruce Schneier has a rather depressing article in Wired this month, about why bad security products drive good ones out of the market.
In essence, in a market where the seller knows a lot more about the buyer, and there are many options, the buyer bases their purchase decisions on the average product price. The high-end stuff -- which is the only secure option -- is just too expensive to justify. Pretty soon, nobody buys the good stuff, and we're all left with the lemons.
In a used car market, you can use economic signals to correct this market behavior, and drive people to make wise purchases... for example, an independent mechanics can spot a lemon rather quickly. Employ one to help you out, and you can purchase a good cars amongst the lemons.
Unfortunately, those independent experts are incredibly expensive in the software security field... and even they don't instantly know which products are the lemons. It takes weeks or months of intense analysis. Who has the money or time for that?
Other signals, like as encryption standards and company reputation, are useful... but they also are no guarantee. So crappy security products will always get to the market faster and sell better than effective security products.
So very depressed...
So I recently subscribed to the Consumer Reports Money Advisor magazine. Overall, its a very good read. Financial advice from them is usually much more reliable than pundits on the TV or (some) magazines.
This month they had an article about credit monitoring and fraud protection services. Overall, they are crap.
They're pretty expensive, and mostly ineffective. The odds that they'll catch the bad guy is low, and on the off chance they do, sometimes the insurance won't cover a pre-existing condition. Meaning if your identity was stolen 3 years ago in a database hack, but they just opened a credit card with your data last week, your insurance might not cover you.
The two pieces of advice that I thought were the most useful were these:
- Monitor your own credit rating for free, using annualcreditreport.com, and
- Tell the three credit bureaus to not give out your credit report
That second one was a surprise to me... but there are laws on the books in half of the states that allow you to "lock" your credit report for a small (~$10) fee. The advantage here is simple: if they can't give out your credit report, then nobody can take out a credit card or loan in your name!
I thought that was a great idea: its incredibly easy to get somebody's social security number, and open up an account with a stolen name. However, if your credit report is locked, then the credit card company will quickly reject any application.
Since no new accounts are possible, all you need to do is monitor your existing accounts. This is relatively easy, if you do the right thing and use very few credit cards. Also, the laws are on the consumer's side when it comes to credit card transactions. The laws are a little less nice when it comes to wiring money between banks, so opening up an bank account with some level of fraud protection might still be a good idea.
Just be sure to read the fine print...
An interesting case is working its way through the courts at the moment...
At exactly 5:45:34 on April 18, 2004 a computer taken from the office of the attorney of Melanie McGuire, did a search on the words "How To Commit Murder."
Ms. McGuire apparently searched both Google and MSN for undetectable poisons, instant poisons, and fatal digoxin doses.
Ten days later, her husband was murdered -- allegedly by Ms. McGuire -- and with a gun.
Apparently her Google skills weren't so hot...
In any event, it raises the question, what if during a criminal investigation that has nothing to do with you, suddenly a judge demands to see your company's web access logs?
Do you have the tools to search old logs for who did what, and when? How long do you even retain those logs? Do you have an official written policy about destroying those logs?
Are your old logs even "discoverable"? Meaning, is it legal for a judge to demand to see them? If they are only on backup tapes, then you might be able to fight it... otherwise the judge could force you to produce them.
And what if you don't have the right software tools for this? You may have to hand over all your company's logs to the judge, and let a third party specialist analyze them. And hopefully that specialist doesn't happen to work for your competition.
These are all interesting questions... and more like them will crop up as Records Managers get more interested in web sites...
In the case of Ms. McGuire, it was sufficient to look through her browser history to see what she Googled. However, she could have been a bit of a hacker, and deleted those local logs. The next easiest place to get that information is to ask Google. Get the IP address for her computer from her ISP, then ask Google for all items searched for by somebody with that IP address.
But would Google want to do that? What about the cost? The hassle? And the violation of Google's don't be evil policy?
Google has recently instituted an anonymous log policy. Ostensibly this is so they can protect your privacy, and conform with some European laws.
I think that its also bit selfish: they just don't want it to become standard operating procedure for cops to demand Google logs for all suspects. That would affect Google's profits.
You might want to come up with a similar policy... yes, you need access logs so you can track what's hot and what's not... but if you don't have an official policy of anonymizing that data after its useful, you might someday be served with a warrant.
I'm not making this up...
Some of their analysis included:
Articles like, "The Technique of Concealing Files from View" and "How to Protect Your Files, Even if Your Device was Penetrated," were written for the intermediate to advanced user, and describe a variety of methods and software that provide security. Links to download referenced software, such as the VMware virtual machine, and key generators to unlock features are also given by the editors. Another writer discusses PGP (Pretty Good Privacy) software and determines that its encryption is not adequate for the needs of the Mujahideen.
So... the jihadists have determined that encryption is not sufficient to secure their data. I wonder how long it will take Wall Street to figure that out! ;)
Seriously, when stuff like this hits the internet, it makes me wonder how much longer wars -- even little wars -- can be used to accomplish a lasting goal.
It makes me think that the writers of The Fifth Dicsipline are right... the only way for any group to survive is if it learns faster than opposing groups.
I'm reading into it a bit... but basically any culture that can embrace the wild and free marketplace of ideas on the internet will thrive... even if the immediate result is unrest, power shifts, or the threat of "foreign ideas" befouling the "purity" of the existing group. This applies equally well to countries, cultures, corporations, and religions.
Any group so dogmatic that they refuse to learn from anything unless it was written 2000 years ago, will likely find themselves left behind.
OK, you mean Amazon turkeys, I'm on to you!
I suddently noticed a lot of access denied messages in my error logs. Some one or some thing has been trying to edit my blog posts... luckily I keep my security patches up to date.
Anyway, I recorded the IP addresses, and used ARIS WHOIS to trace back their IP addresses, and guess what? Its Amazon.com.
I don't know if its a sysadmin who was mad that I posted info on security holes at Amazon.com (which they fixed nicely)... a hacker who is disguising their IP address... or a misconfigured web spider. It could be a taunt, an accident, or malice.
In any event, I'll be contacting them and my ISP in the morning. I hope I can schmooze a free book out of this...
As you may or may not know, a lot of cyber crime is waged from networks of zombie computers, also known as botnets. This scary name refers to the hordes of personal computers that have been infected with spyware, adware, or viruses. Such computers are frequently involved in denial-of-service attacks, or to allow criminals to send spam, hide files, or generally cover their tracks.
Yes, if you have a computer virus, your computer was most likely involved in a crime. Anything from blackmail, to piracy, to smuggling child pornography.
The original attackers are getting harder and harder to find. The number of attackers is growing, they are more organized, and the software bugs are getting worse.
So what's the answer? I believe the first step is to begin fining individuals who have viruses on their computers. Yes, they are innocent victims, yes once a system is compromised its difficult to recover, but we need bold actions to solve this problem.
Punish The Victim!
Isn't this punishing the victim? Yes it is. And it may be the only solution.
These reverse-punishment systems are not unheard of. In Italy, just after World War 2, there was a huge rash of kidnappings. It continued for quite a while, during which the police were powerless to help... perhaps they were even in on the kidnappings.
Anyway, in a bold move, the Italian government decided to solve the problem by making it illegal to pay ransom.
The government reasoned, kidnapping is horrible and should be stopped. However, the government had little power to stop the kidnappers... but they did have power over the hapless victims. Therefore, they made it illegal to pay ransom on the grounds that it puts money into the hands of criminals, and makes kidnapping more common.
Now, a lot of these zombie networks perform denial-of-service attacks against medium to small business, as I've covered before. This can knock a small business off the internet entirely. They then demand money from the businesses to prevent future attacks.
So, why not make it illegal for these corporations to pay ransom? Isn't that a better analogy?
It would be, except these attacks never make the news, nor is there ever a police report. The companies want to hide the existence of the crime at all costs. So, we're back at square one.
The blame lays in two places: companies releasing software for wide distribution before it's been battle tested, and computer illiterate people who never follow basic security protocols.
So shouldn't we punish the software industry? Absolutely, but that will yield only limited success. Windows got a lot better after Service Pack 2, although IE is still a wasteland of bugs... However, even if Windows was rock-solid, that would still not prevent a foolish user from installing a piece of malicious software, or running services they don't need.
One Possible Solution
Here's what I believe should be the first few steps in the solution:
- Create minor fines (say $100) for any individual who connects a virus-laden zombie computer to the internet.
- Allow waivers for these fines for security researchers.
- Make it a law that the zombie's homeowners insurance company must cover the fine without a deductible.
This will force insurance companies to pay the $100 fine, if the user has homeowner's insurance. This will relieve most of the burden off of the user, at least for a time.
Since insurance companies are now involved, they can make demands of their policy holders, or risk a raise in rates. For example, they might require a computer safety course, similar to an auto safety course. Or they might give a break if you own for one of those $30 firewall/router combos from Linksys. They would probably give you a nice bonus for owning a Mac...
People have said for years that we need to get the insurance companies involved if there is ever going to be any progress on computer security / safety. That's what it took to prevent fires due to bad wiring or poor construction. But getting them involved is not easy if we only focus on software companies...
To really get the insurance industry involved, we have to punish the zombies.
These innocent victims are making the internet a dangerous place, and a haven for criminals. The solution to this problem is complex, and I do not believe we will find it until enough money is involved. If the insurance companies had to pay $100 per zombie, they would start out by passing that fee along to the customer... but would then rapidly look for a solution.
Estimates of the costs of cyber crime range from 10 to 100 billion annually, and its only increasing. Spending a few billion on a workable solution is a no-brainer.
Say somebody sends you an email with a phony link on it. It looks like its your bank, but its just a scammer trying to get your password. Assume you give the scammer your password, and he steals thousands of dollars from you. Should the bank cover this fraudulent transfer, or should the customer have to?
Personally, I believe its in everybody's best interests for the bank to pay for the loss. This is not some anti-bank rank, its simple pragmatism.
If its the consumer's responsibility, then the consumer will most likely stop doing online banking at all. That means more work for the bank, and less profit.
On the other hand, if the banks are forced to pay for losses, they have the incentive to join together with other banks to combat the problem in general... that would be much more effective at getting rid of the problem, and would eventually lead to a safer, more secure, and more profitable bank.
Or maybe the better approach is insurance? The banks take out 'scammer insurance' against these kinds of internet criminals. Then the insurance companies give the banks an independent audit to see how secure they really are. If the banks have a web site that is less susceptible to phishing, then the premiums are much lower. The banks can add as much security as they wish, depending on how much risk they are willing to absorb.
This isn't a new concept... Bruce Schneier talks about it all the time. I just hope the banks don't make the wrong choice and go for the short-term profits.
In the recent past, malware hackers have been using Distributed Denial of Service (DDOS) attacks to hold web sites hostage.
The first step is to attack ordinary home users running unpatched versions of Windows 2000 and Windows XP. They then install applications on them that gives the attacker remote access to their computer. These victims are sometimes called zombies.
The hackers then use these zombies to attack medium sized web sites, at a moment when they cannot afford for their site to go down. Say, an online toy store right before Christmas. Or an online gambling site right before superbowl sunday.
The attacks are not sophisticated; the hackers simply get their army of thousands of zombies to request thousands of web pages. However, the effect is significant: small to medium sized web sites simply disappear from the internet. Too much traffic makes them unavailable.
Then the standard operating procedure is to stop the attack, and send a blackmail letter to the web site owner. "Give us $20,000 today, or your web site is toast." Most people comply, and never even tell the authorities.
Well, as ISP and routers are slowly getting better at dealing with DDOS attacks, the hackers have decided to take a different route. Blackmailing their own zombie army.
Instead of using the zombies to launch an attack, they simply encrypt important data on the zombie's computer. Once the data in encrypted, it is nearly impossible for the victim to get their data again without a decryption key. Then the hacker offers them the key, in exchange for a few thousand dollars.
Yikes... now that's mean...
According to an article on CIO magazine, these attacks are on the rise... and using much more sophisticated methods. The encryption keys are longer and stronger, and they may soon be nearly unbreakable.
How to protect yourself? Well, there are two obvious solutions:
- Get a Macintosh
- Make backups of important data
If you cannot get a Macintosh, then at least install a firewall, use Firefox for web surfing, and never ever ever install code you downloaded from the Internet without first doing a full backup.
I just read another interesting article about phishing. This time the victim was Citibank's Citibusiness service, and several of their customers.
In this case, Citibank used two-factor authentication to secure their site. This means that not only does the user have to supply a name and a password, but also a second piece of information in the form of a token.
The token is controlled by Citibank, so they can make sure its big and random. They then hack the password with it, and send that along to their authentication system. For extra security, the token/password hash would only be valid for one minute.
Sounds good so far... but a chain is only as strong as its weakest link. And the weakest link here is still the end user. So we have yet another case where security without usability isn't security at all.
The folks over at Secure Science Corp. noticed that some phishers set up a phony Citibank log in site, and send out a bunch of emails telling people to log in at the evil site instead.
You can guess what happened... when somebody clicked the link and logged in, the evil site prompted them for their user credentials. Once the hapless victim supplied them (along with the token), the evil site proxied the request back to Citibank. This made the user think he actually was on the Citibank site... however, in that one-minute windows before the token expired, the hackers were able to transfer a good amount of funds into their own accounts.
Citibank could have fixed this by restricting logins for a user to a specific IP address, but that means less flexibility.
There is no real solution to this problem... however installing phishing detectors on all email clients is a step in the right direction.
The following types of links signal a scam email:
- A HTML email with link to a known open web redirect (aka phishing hole)
- Example: links starting with http://google.com/url?
- A link containing an IP address
- Example: links to http://220.127.116.11/login
- A HTML based link to a site other than the originating email address, or mail server
- Example: mail from email@example.com that goes to http://randomsite.com/login
Most phishing scams these days look something like that. Unfortunately, the last one will yield a number of false positives. Sometimes you need to send an email to a friend that contain a URL to some random site. The scam filters will need to be as smart as the latest spam filters, and learn about scams as they go.
UPDATE: This was originally posted in June 2006. As of February 2007, Amazon, MSN, and Google have closed these security holes. However, as of February 2008 AOL is still vulnerable. If you run a large web application, please use the information below to make your redirects safe from phishing attacks.
One of the comments in the article mentioned that the technique is tricky to get right, otherwise you would have a security hole. Basically, a scam artist could send you a link to an evil site, but it would look like a legitimate link. You would click on it, and give your username, password, or credit card thinking it was legitimate.
These kinds of scammers are called phishers, and their techniques are highly successful.
Anyway, after that post I decided to look around the internet to see if any big sites were using this redirect trick. If so, then they would have to do it in the right way, otherwise it would be a security hole.
Guess what? Amazon, MSN, and Google all have this security hole.
My first stop was amazon.com. They added this new wiki feature so that the public could create a wiki for each book. The problem with open contribution on wikis is that if you make a link from Amazon.com to your site, then your site's Google rank will greatly increase. This may be legitimate, but too often it leads to spam-blogs, as mentioned before.
So, to prevent spam-blogs, Amazon uses a redirect trick. However, they did not do it correctly. Look at the link below. Where do you think it goes? It looks like Amazon.com, but its actually a link to my home page.
So what's the big deal? Well, lets say I set up a site that looked exactly the same as Amazon. Also assume I sent out a bunch of emails containing the evil link. I say in the email that somebody just ordered $10,000 worth of electronics from Amazon with your account. For your protection, we flagged it as a possible identity theft scam. Would you please log into our site, and re-provide your credit card number for verification?
hmmm... would you be able to tell that this email was a scam? The URL goes to Amazon, and I don't want somebody charging $10,000 on my card... Yes oh yes please let me log in to your evil site and give you my information!
Amazon is not alone... check out MSN:
Or this MSN link:
Or even Google:
Both Yahoo and EBay seem to do it right, or at least I wasn't able to discover how to redirect in under ten minutes of Google hacking...
Yahoo appears to use unique internal IDs instead of full URLs. That means that you cannot simply create a URL and use Yahoo to redirect to it. Your URL has to be registered somehow in their internal system, and then you can redirect to it according to its ID. Less flexible, but that's security for ya!
In the past, phishers would go so far as to hack into web sites, then send out emails directing people to phony pages on legitimate sites. A few years back EBay Germany was hacked like this. The hackers did not bother to try to directly attack EBay's user repository; rather they added a few pages to one of the web sites, and tricked people into logging in through their page instead.
In other words, EBay could have had the most secure data repository in the world, but it didn't matter. All the phishers had to do was trick people into thinking the secure EBay login was somewhere else... and they got all the data they needed.
With these kinds of open redirects -- or phishing holes -- laying about, the job is even easier for the phishers. Now they don't have to bother hacking into a site at all! They can simply locate an open redirect, and send out a URL like the ones above.
If you want it to be less abrupt for the users, you should implement something like what Yahoo does: use internal IDs for each URL, and have some kind of secure process for adding a link to the list of valid redirects.
7-18-06 Update: Amazon appears to have added a security token to their redirect page, so it is less hackable. They have added a 20-digit hexidecimal token to their redirect URLs. Now the only question is how long is that token valid? An evil hacker can still put an evil link in a comment on an obscure book's web page. That will allow him to generate the secure token.
Then the only hope is that the token will expire within a few hours, or that Amazon is monitoring how people use these redirects.
11-28-06 Update: The redirect links to MSN also appear to be fixed, which now just leaves the Google redirect hole. Hopefully they will follow in the footsteps of MSN and Amazon and add some security to their redirects.
2-16-07 Update: Google has finally closed their security hole by adding a simple redirect warning page... but countless more remain on the internet.
Well... I'll believe it when I see it, but some security researcher claims to have invented some completely undetectable malware. Malware is an all encompassing term for evil software, such as viruses, trojans, spyware, adware, and the like.
The details in the article are thin, so I'm not sure if I believe it... but he claims that the rootkit works by loading the entire operating system on top of the malware. This is similar to how applications like VM Ware can run an operating system in a virtual machine. Of course, this means that your security software is also running in the virtual machine, and therefore is completely unable to detect the state of the actual host computer. A virtual machine simply will not let you do that... because to allow access checks to the host is also a security hole!
Therefore, you cannot block this kind of malware without crippling the security and stability of virtual machine software!
Damn sneaky... I wish I had thought of it.
Spam-blogs (or Splogs) are becoming as annoying as spam email.
Sploggers set up sites with zero content, and just a bunch of ads. Then they spam the comments threads on popular web sites, and link back to their splog. This tricks Google into thinking that the splog is site with relevant information. This boosts the Google page rank of the splog, which means more ad revenue for sploggers.
Well... nuts to that!
People have come up with lots of techniques to block sploggers. Requiring registration, making people type in the letters they see on the screen, or typing in answers to simple math problems. All good.
This weekend, I came across a very interesting technique for stopping splogs. It goes beyond the basic tricks and eliminates the value of splog comments entirely. If everybody followed this technique, splogs would never work in the first place.