The Hacker Factor Blog

The Bush administration has taken a new tactic in the war on terror, following their success with the economy. Simply put: they are redefining the terminology.

For months now, we have seen the economy in a spiral. While oil companies report record earnings, gas prices are skyrocketing. At least some members of Congress are beginning to wonder why the oil companies are getting a tax break.

Similarly, the cost of food is out of sync with production costs. For example, in 2006 Rice cost around $8.75 per hundredweight. Today, it is over $14/cwt. It isn't that rice has suddenly become harder to produce -- we're still producing about the same amount of rice as 2006. The difference is in production costs. (Fertilizer and pesticides lead the cost increases.) The same is being seen with fruit, milk, and other food items.

And then there is the economy. The unemployment rate continues to increase, while consumer spending continues to decrease.

With all of this inflation, unemployment, and cost cutting, should we call this a "recession"? No says the Bush Administration. We're just in a "slowdown". Rather than addressing the problem, the Bush administration is addressing the terminology.

Similarly, rather than calling extremists "jihadists" or "mujahadeen", the administration has decided that we should call them "violent extremists" or "terrorists". (Uh, I thought the terms "jihadist" and "mujadaheen" came from the groups themselves. This is what they call themselves.) Similarly, the administration says that "Al Qaeda" is not a movement... even though there are independent branches like Al Qaeda in Iraq, Al Qaeda in Islamic Maghreb (formerly GSPC) and many other spawned-off groups. (If every group takes the name "Al Qaeda" or affiliates themselves with Al Qaeda, then it sure sounds like a movement to me.)

Even torture is being justified with a simple words change. (It's not "torture", it's "interrogation".)

We can take this to the next step. For example, TJX and OfficeMax did not "lose credit cards", they just "reallocated" the information improperly. And the 10,000 infected servers were not "compromised", they were simply "reused" for a different purpose. And I'm not saying that we should "impeach" the President for gross incompetence, applying illegal interrogation techniques, and domestic spying (uh, "information gathering"), I am simply saying that Congress should "remove him from office without his agreement".

Close to two weeks ago, I noticed that one of the web sites I frequent was infected with malware. The attacker injected a URL into each web page, directing visitors to a malicious web page which, in turn, infected their systems. I turned my findings over to the Internet Storm Center, and they correlated the attack with a previously-unidentified attack that had been reported by them a few months earlier. At last, the mystery was solved; the attack method was identified. (Along with the attack and source, I found an archive of payloads and an executable that turned out to be the tool that performs the attack. However, it was the ISC who identified the details about the infection tool; I just found the program.)

Since then, many other sites have jumped on the bandwagon. Some, like F-Secure and WebSense make no effort to identify that the ISC and myself initially made the discovery. (In academics, this is a no-no, but in the real world, this is called "stealing credit".)

In any case, all of these copy-cats seem to be inflating the numbers. So, how do news and security sites come up with the number of infected hosts?

According to the Guardian, they search Yahoo! for a single term that is known to be found on infected sites. They reported "more than 100,000 pages". The Washington Post's Brian Kreb reported "hundreds of thousands". Kreb's report is similar to WebSense, who used Google to report hundreds of thousands. But all of these numbers are smaller than what security company F-Secure discovered: close to a half-million infected sites.

The problem with all of these estimates is that they are based on a flawed and inflated system. For example:

• Duplicates. Search engines frequently report different pages on the same sites, or the same site going by different names. As a result, the same information is reported multiple times.
  
  
• References. The Google Ranking system is primarily based on who points to you and not what your page contains. Thus, if 100 infected sites all have hyperlinks to your uninfected site, then you will be included in the listing. If you do the search on Yahoo! right now, the second link goes to Oddbins Wine Merchant. Oddbins is not infected and neither is Yahoo's cache of the site. It is likely there by reference.
  
  
• Discussions. It has been nearly two weeks and this is hitting many public news sites. As more people talk about it, more web pages are created that include the appropriate search phrase. Just because I write the word "nihaorr1" in my blog does not mean my blog is infected.
  
  
• Unindexed. Not every web site is indexed by Yahoo! and Google. So there are likely plenty of infected web sites that are unlisted.
  
  
• Estimate. The biggest error comes from the fact that these different groups use Yahoo! and Google search engines to supply the estimates. Both of these search engines make a very rough guess at the number of results. As you continue down the pages of results, the estimates are revised. For example, Yahoo! is currently saying "about 178,000" results for the search term "<script src=http://www.nih[REDACTED].com". (I redacted the hostname because it is hostile to web browsers. Do any of the above searches to see the name, but beware: if you visit any of the result sites with a Windows system, then you stand a good chance of getting infected.)
  
  However, the "about 178,000" is only shown on the first few pages of results. Try viewing other pages. For example, page 30 shows about 108,000 search results and page 70 shows about 10,600 results. (These numbers constantly change, so don't be surprised if your search results differ.)
  
  Hmmm... Yahoo actually reports about 10,000 infected sites... Isn't that the same number that myself and the Internet Storm Center found ten days ago?
  
  I should mention that Yahoo currently returns 71 pages... at 10 responses per page, that is 710 results. Amazing how the initial estimate of 178,000 dropped to 108,000 then 10,600 and finally 710. Google has the same problem with estimates. The same search on Google currently returns about 38,800 results, but page 32 denotes the end of the results and reports 314 total. (Repeating the search with "omitted results" goes from "about 42,800" to "about 43,200" [yes, it goes up], but they stop returning results at 1000.)
  
  
• Variable estimates. Try this with Google: Do a search that returns a few thousand or millions of results (any search will work). Wait a few minutes, then reload the page. It is not uncommon for the estimate to change between reloads. This change happens because different servers contain different data that leads to different estimates. If Google returns 178,000 right now, it might return 165,000 when you simply reload the page. (The number may go up or down, and it may change by a significant amount.) As more searches are performed, the estimates are revised. This is similar to going from results page 1 to page 2 to ... Each subsequent search revises the results. This is different from a regular database where "SELECT count(*) FROM table" returns an absolute number.

Using search engines to generate these estimates can give a good ball-park figure, but should certainly not be reported as authoritative. To use this kind of estimate, you must first get past the initial "grossly inflated" number of search results.

So how many sites are likely infected? I think the number is much closer to 10,000 than 100,000. And F-Secure's reported estimate of "510,000" is totally wrong.

[Update 23-April-2008: According to a representative from CompUSA (see the comments to this blog entry), the current "CompUSA" (post-store closing) is managed by Systemax and does not use the same systems. They are unlikely to be vulnerable. However, this does not invalidate that the previous CompUSA was vulnerable, was compromised, and the risk must be reported. Considering the mis-information that I have already received from CompUSA (from CompUSA support and Mark Gertenbach, who appears to no longer work there -- go AT&T!), one must wonder if they really are no longer vulnerable, whether Systemax was ever in control of the systems that were vulnerable, and whether the vulnerability has actually been fixed.]

There are many different public computer security forums. I consider some of them to be very valuable and informative. For example, I regularly follow the Internet Storm Center, Security Focus, and the CyberSpeak podcast. Other forums include useful information and updates, but also have a significant amount of chatter. (While chatter can be entertaining, these forums can be ignored if you're short on time and in need for news.) Examples include the Fun Security (funsec) mailing list and the Bugtraq mailing list.

Unfortunately, there are also many forums that are, in my opinion, less useful. Yes, they may say something interesting, but useful information is usually few and far between. For example, the Full Disclosure (FD) mailing list seems to average one interesting posting per 100 email messages. So far this month, FD has had over 500 postings. Most of the messages are noise with no valuable content. A few announce vulnerabilities, but they do not provide details [example 1, example 2, example 3]. (Uh, isn't the forum called "Full Disclosure"?). Most of the formal advisories are in the form: "There is a bug. Go get the patch." These advisories do not include enough information to evaluate the risk or prioritize the threat. In fact, I could only find a few real "full disclosure" vulnerabilities on the FD forum: sighting #1, sighting #2, sighting #3.

(I usually ignore FD. If something interesting happens, I'm sure that some of my associates will point it out to me.)

Another forum that I usually ignore is "2600". (Eric Gordon Corley aka Emmanuel Goldstein is so full of himself, and his ego is only stroked by the army of script kiddies who worship him because they don't know any better.) I occasionally listen to the 2600 radio show. (To give appropriate credit, 2600 released their shows as MP3s long before they were called "Podcasts". So one would think that they would finally learn how to use the studio equipment after all of these years...)

Along with the 2600 radio show (which makes good background noise, but don't expect to get any real value from it), there is the 2600 The Hacker Quarterly magazine. Again, treat it like any zine -- written by kiddiez, mostly unedited, with ethically borderline content. (The "letters" to the magazine is the best part -- and they are always a few pages. Read them and think of Mad Magazine.) However, buried within the muck is always a rare gem...

And this leads me to my current rant...

I just picked up the Spring 2008 issue of 2600. Buried within the noise, between the "April Fools' Day" article by xinit (one of those, "it was funny, but you had to be there" stories) and "Downloading MP3s From www.allofmp3.com For Free" by He-Who-Must-Not-Be-Named (assuming it works, it sure sounds like financial fraud to me), is a very interesting article titled "Remember CompUSA" by silic0nsilence (Corey Mishler, better known for fuckpaypal.net).

The article clearly describes how to retrieve names, credit cards, expiration date, card security code (uh, isn't storing that forbidden by the PCI DSS?), and other information from computers on the CompUSA showroom floor. Yet, it was just three months ago that CompUSA assured me that they did not store credit card information and then demanded an apology from me when I questioned their knowledge of the PCI requirements.

Even though they closed most of their stores, there are still some CompUSA locations. Also, they run an online store. I strongly recommend against shopping there because (assuming the 2600 article is accurate -- and I don't see any reason that it isn't) their entire list of customer credit cards has just been publicly compromised. Security-by-obscurity does not work when the trick is printed in a magazine. Furthermore, people who read the magazine are likely to try the exploit and the exploit was known to "someone" prior to publication. Moreover, CompUSA is unlikely to know how many cards were accessed, so they must assume that all cards were stolen. (The TJX compromise was "up to 96 million cards" because they did not know the actual number and had to assume the worst case.)

Didn't I call CompUSA the "Next Big Thing" for stolen credit cards?

Earlier this week Slashdot had a blurb about a finding on the Daily WTF. It seems that the online sex offender's registry in Oklahoma had an SQL injection vulnerability where the entire SQL statement was included in the URL.

After being publicized by the Daily WTF, Oklahoma removed the one offending link (it was the "Printer Friendly" hyperlink). However, they did not fix the core problem. They are still vulnerable to SQL injection attacks. For example:

1. Bring up any of the listed sex offenders. For example:
   http://docapp8.doc.state.ok.us/servlet/page?_pageid=229&_dad=portal30&_schema=PORTAL30&offender_id=28627&delinquent_public=Y
   
   
2. Add a single quote to the offender_id. E.g., from "offender_id=28627" to "offender_id=2'8627".

You will see an SQL error, indicating an unprotected variable and an SQL-injection point.

ERROR: System unable to initialize name portlet

Please contact your system administrator with the following message:

DETAIL_NAME; portlet

ORA-06502: PL/SQL: numeric or value error: character to number conversion error

NOTE: By itself, this single quote is not an attack; it is a typographical error. This is no different than a user accidentally typing a character in the browser's address bar. However, if you make it do anything beyond generate the error, then it is an attack.

(I should also point out that you will see a different SQL error if you remove the offender_id number. They are not even checking for valid database results.)

Oklahoma probably has this same problem all over their site. They need to quote their variables, check for quotes in variables, and validate returned values. In PHP, there are many ways to do this. Here's a few options.

• $Value = intval($Value); Since it must be a number, make it a number (this is the safest option).
  
• $Value = str_replace("'","",$Value); Since single quotes are bad, remove all single quotes.
  
• $Value = str_replace("'","''",$Value); In PostgreSQL, use two single-quotes to quote a quote. There are similar tricks for other databases.

Perl, VBscript, Java, and other languages commonly used for CGI scripting have similar functions.

SQL in the URL

An SQL-injection point is any unprotected value that comes from the user and is placed directly in an SQL statement. Using this, you can query any database value, modify any table, or even run commands on the remote server. In effect, if you have an SQL injection vulnerability, then your system is wide-open. (Not just your database; your entire server.)

The compromise at the Oklahoma Sex and Violent Crime Offender Registry was/is not just an unprotected variable, they included an entire SQL query string in the URL. (I'm not making this up! This level of stupidity takes real ignorance!) Since anyone can modify the URL, this drastically simplifies the exploit. An attacker can change the "SELECT * FROM table ..." to "DROP table" (to blow away the data) or worse...

So how do you find these vulnerable systems? Google!
(Since the bad guys know about this already and are actively exploiting it, I see no harm in giving more details to everyone else. However, I am intentionally not including malicious SQL here.)

Google allows you to search for strings not just in web pages, but in URLs. All you need to do is search for common SQL statements in the URL. A few examples:

• allinurl: "select distinct" from
  Some of the results are web pages or forums discussing the SQL "SELECT DISTINCT ... FROM" clause. (They are roughly the first 20 results from Google.) However, most of the results are vulnerable web sites. medtelstore.com, umixit, and about 30,000 other URLs are all ready for exploitation. (Considering that some of the URLs are from the same sites, this is probably around 20,000 web sites.) Since most of these are online stores, real estate, or medical sites, expect there to be plenty of vulnerable personal information.
  
  
• inurl:select inurl:from inurl:"order by" -phpmyadmin
  Of course, not every SQL query uses "SELECT DISTINCT". However, many SQL queries use "SELECT [columns] FROM [table, conditions] ORDER BY [column]". As with the previous search, there are a few results that show forums or manuals, but most of the "about 340,000" results are vulnerable. (Due to multiple vulnerabilities from the same sites, 340,000 URLs is probably around 220,000 distinct sites.)

If you try these searches, you'll notice that some of the pages are offline or broken. This is less likely due to "they fixed it" than "they have already been exploited."

Although we could search for single SQL commands, like "SELECT" or "UPDATE" or "INSERT", most of the results will include false-positives. Forums, online manuals, and unrelated topics will all be returned along with the vulnerable sites.

Who is to Blame?

SQL-injection attacks are not new. This problem is not due to a "novel" attack. It is also not due to the language. Just as you can drive a very safe car on the sidewalk and cause damage, you can take any programming language and use it in an insecure fashion. The only person to blame is the software developer. In many cases, the same vulnerable software is used on many different sites. Again, it is not the web site's fault -- blame the programmer.

Programmers need to remember that input from the web -- whether in URL or POST data -- cannot and must not be assumed safe. Even using "HTTPS" will not save you from these attacks.

There are three steps for solving this problem.

1. Programs must validate user input. If you expect to receive a number, then make sure it is a number. (Don't just assume.)
   
   
2. Don't assume that the user will return valid SQL, even if the server passed them valid SQL that users are supposed to pass back to the server. Instead, don't give the user the option. The SQL statements should be kept on the server-side and never passed to the user. The user should only provide the minimal parameters for the SQL statement (see "programs must validate user input").
   
   
3. Don't pass database errors back to the user. There is nothing the user can do with that information. (And if they do know how to use it, then they are likely to know how to use it against you.) Unlike the first two options, catching all database errors is neither easy nor trivial. However, it will lead to a better user experience and a safer system. (Security by Obscurity does work!) Then again, this is not easy; the first two items are easy and must be done.

Sadly, I would not be surprised if the programmers who make these mistakes have no formal programming training (or training in secure web and database development) and are paid a minimum wage or charge very little for their software. Firing the programmer and replacing them with an equally (in)experienced programmer will not fix this problem. You get what you pay for. Instead, programmers must be educated and must correct these problems.

I am fully aware that not everyone has access to formal courses on secure programming for network services. However, there are plenty of public resources available. At minimum, web developers should read the Open Web Application Security Project (OWASP) Guide to Building Secure Web Applications and Web Services. (SQL injection attacks are covered in Section 15.) Ignorance is not an acceptable excuse.

I recently had the opportunity to travel (again). While physical security at airports is much stricter than the pre-9/11 era, it is definitely uneven. I accidentally got a big bottle of water past airport security in Denver. (I swear I forgot I had it, but they didn't collect it.) And my small baggy of liquidables (which I always place under my jacket on the X-ray machine tray) is never looked at. Sadly, the physical security screening is really a facade. Getting restricted items past even the most conscientious screeners really isn't too difficult.

I would not be so concerned if all airports were the same. Unfortunately, every airport is different. The Raleigh-Durham International Airport is one of the strictest I have been through. In contrast, the Mineta San José International Airport is pretty lax. But at least they try...

While physical security is still a work in progress, network security is a different story. Most airports don't cater to computer users. Sure, they have third-party wireless providers, but many airports do not offer free WiFi. And of the ones that do, most do not offer it everywhere passengers congregate.

Adding to the problem, most airports don't have enough electrical outlets. Good luck finding a power outlet at Washington Reagan National. The Denver International Airport has outlets, but they are few and far between, and most are not next to chairs. (If you plug in, expect people to trip over the cords.) In contrast, the Mineta San José International Airport in Silicon Valley has plenty of power outlets, right next to most seating areas.

So... let's pretend that you found a power outlet and managed to get a strong WiFi signal and a good network connection. How safe is your surfing?

In Chapter 8 of my first book, Introduction to Network Security, I provide many different methods to remotely tell if a host is operating in promiscuous mode. I even provide a program (arp_pd.c) that uses ARP packets in order to identify if a computer is in promiscuous mode and the operating system of the remote computer. (Different operating systems generate different responses to different broadcast ARP addresses.)

If a computer on the network is running in promiscuous mode, then they are likely collecting packets. While there are some legitimate purposes, most computers are probably scanning for passwords.

I wrote a small for-loop to run the program on the entire Class-C subnet that the airport's wireless network provided.

i=0;

while [ $i -le 255 ] ; do

  echo "# Testing 64.134.126.$i"

  arp_pd eth0 64.134.126.$i

  ((i=$i+1))

done

The result? There were THREE (3) systems operating in promiscuous mode (uh, three -- besides me). This is pretty impressive considering all of the people using laptops. I have seen coffee shops that are safer than the San Jose airport.

In contrast, Washington DC's Reagan National is much better. I only found one promiscuous system out of three trips. Then again, it was really hard to find a power outlet.

Of course, none of this includes evil twin attacks. Considering that none of the airports advertise their MAC addresses or which WiFi channels they use, anyone can start up a wireless hub and pretend to be the airport. I doubt that there are any airports looking for this.

The moral of this story? While we might be a little safer in the air, the air is not safe.

Thanks for Paul Hummer for the proof-read and reminding me to mention evil twin attacks.