This morning a security researcher identified that he was able to carry out a successful SQL Injection attack against donate.barackobama.com, the official campaign donation site of current President Barack Obama, and gain access to credentials such as user names and passwords for persons who have donated to the Obama campaign, as well as administrative user credentials. On his blog he goes on to postulate the further attack possibilities with admin access such as web site defacement, uploading phpshells, and so forth. The problem is that the researcher Unu didn’t find an SQL injection site on donate.barackobama.com, he found one on a calendar application at Roosevelt University. In the process of finding out how that would be possible, a real web site vulnerability on the Obama web site reveals itself.
“We have a table admin. And in this table we can see that the admin passwords are in PLAIN TEXT! The website is big, with many sections, and there are 19 admins. What else we need to get full access on the website? Nothing. After we log in as admins, we can virtually do anything we want with the website: upload PHPShells, redirects, infect pages with Trojan droppers, [and even deface the whole website],” – Unu
Speculative holes become apparent in reading the blog entry. The blog states and Pangolin shows that the database backend to the site is MS Access. Why would a professionally built web site (the site was built by a firm called Blue State Digital), use MS Access to store data? The Obama donation site, like the other sites built by Blue State Digital, is PHP based and appears to use the Expression Engine content management system (CMS) by EllisLab’s. Expression Engine uses MySQL, another problem. Finally, the donate.barackobama.com web site does not have user ids and passwords, it takes contributions directly from a form the user fills out.
Officials with responsibility around the web site responded similarly. Hari Sevugan of the DNC stated that “based on the number of incorrect assertions, we do not think that this information is credible. There has been no security breach”. Jascha Franklin-Hodge the CTO at Blue State Digital followed with: “After careful review, we are confident that the screenshot included in this bug does not contain any data from the barackobama.com or any other site hosted by Blue State Digital, the DNC, or Organizing for America. Microsoft Access is not used in any capacity on the barackobama.com site or servers.”
Not everybody agreed as of this morning. Chet Wisniewski of Sophos posted the following, based largely on Unu’s other successful exploits: The Tech Herald is reporting that they have spoken to the Democratic National Committee who deny Obama’s site was hacked. This is not surprising, and I believe is also incorrect. The usernames all match up with Obama staffers and campaign staff, which if the screenshot posted by Unu was mocked up would be a lot more work than most scammers would bother with.
So what site did Unu the researcher pop?
Here is Roosevelt University’s calendar. We were led here by the keywords showing up in the Pangolin screenshot. Fingerprinting the calendar application at Roosevelt University shows that it is an Active Server Pages application relying on an MS Access database. Errors on the calendar application reference the MS Access ODBC driver. So we’ve found the MS Access database in question. One of the admin accounts in the screenshots is id: webmaster pw: calAdmin…, or calendar administrator. Looking at the calendar itself on the Roosevelt U web site, the abbreviation CCL shows up, standing for “Center for Campus Life”. Looking again at the list of ids, there is a cclschadmin, likely Center for Campus Life scheduling administrator or something similar.
Why did Unu start at one site and end up popping another?
Google cache provides us the answer.
For some reason the following URL was valid before Blue State Digital made a fix to have only a specific allow list. The URL will load whatever page follows the /smartproxy/ subdirectory.
This not so smart redirect function is perhaps in place to allow webmasters to code pages that refer to resources like images, etc. without having to worry about content hosted on secure (with an SSL certificate) versus unsecure web servers and the browser error messages that come up with mixed content security. Or it may simply be to capture click metrics when people are leaving the site for outside resources. There are a number of reasons people set up such site redirects. Regardless, a web site should almost never allow a user to fill in where the site will redirect to under its own domain. We’ll get into why in the next section. There is a common resource being referenced in /home/bsdrelease/framework called smartproxy.inc.php. This is identified because on some of the sites created by Blue State Digital (assumed to be the /bsd), are outputting their PHP errors as shown below:
This allows us to identify other web sites with the same architecture. A quick google for /bsdrelease/framework brings up dccc.org, onewisconsinnow.org, udallforcolorado.com, progressivebookclub.com, progressnowcolorado.org, and other Democrat affiliated web sites. So any problem identified in one web site will likely work on the other web sites using the same common code base. In production web sites, PHP’s error reporting should be turned off.
So what’s the vulnerability?
It is not nearly as headline grabbing as the potential to steal login credentials from Obama donors, but until it was corrected at some point recently, the ability to redirect to any web site from donate.barackobama.com or any of the other sites mentioned above was not a good thing. Why?
First, it is a common technique of phishers or anyone attempting to get users to input information at a URL to try to make the domain look as legitimate as possible. When a bad actor can send out e-mails that are prefaced with the actual Obama donation site URL, but actually load any other web site to accept information, it makes masquerading as a legitimate web site that much easier.
Second and more important though is that the cookies from any of these web sites can be read by the site that is redirected to, because according to the browser you are still under donate.barackobama.com. On sites that don’t have credentials, like the donate site, this is not really an issue. But other sites in the family, such as my.barackobama.com do accept user registrations, and have login/password authentication. A cookie called PHPSESSID is set. If a bad actor can get a user to click on a link under the my.barackobama.com domain that actually redirects to his web site, he can read this session cookie, set it himself, and be logged in as that user on the barackobama.com web site. How hard would it be to get logged in users on the site to click a link? You are allowed to set up a blog on the web site, write one story and direct people to a link in the story.
Want to try reading your my.barackobama.com session cookie on another web site?
To add the bookmarklet, right click on this link and select Add to Favorites or Bookmark this Link. When on the redirected Google site, click the bookmark you’ve created, you should see your PHPSESSID from the my.barackobama.com web site.
This problem now appears to be fixed for the most part. Google as a redirect still works, but many other sites at this point will not, producing the following error:
ERROR: attempt to proxy page from a host not on the allow list. access denied.
This would indicate that a white list of allowed hosts has been set up.
Not the Same Server
The Tech Herald reported the following earlier today:
“Unu has apparently accessed a database on the same server that is unrelated to President Obama’s site…If so, we asked why an SQLi from President Obama’s site allowed access to the Access database…While this is pure speculation on our part, perhaps the DNC is correct. It is possible that Unu has in fact accessed the database for a different site entirely that resides on the same server”
The Roosevelt University website is hosted in Englewood Colorado by NTT America, the Barack Obama donation website is hosted in Washington, D.C. by Internap Network Services on behalf of Blue State Digital. The web sites are not hosted on the same server.
Unu, apparently from Bucuresti Romania, says that for him penetration testing and finding vulnerabilities is a hobby and a passion. His blog, a testament to the results of his hobby, is a compilation of the results of successful SQL Injection attacks against web sites like BNP Paribas, Credit Agricole in France, Royal Bank of Scotland’s WordPay, Poste Italiane (the Italian Postal Service) and others as well as examples of successful parameter manipulation and other web application vulnerabilities. He appears to practice a version of responsible disclosure in that he has notified the organizations mentioned on the blog and explained the problems. His blog, and its disclosures, are interesting reading for the security professional and thus we encourage you to have a look.
The site he publishes to is hosted on Baywords, a blog platform notable in that it was formed to combat what it sees as censorship by other platforms such as WordPress (the platform founders state they set up the service after a friend of theirs was closed down by WordPress for a TOS violation.
What is Pangolin?
Pangolin is an automated SQL Injection tool developed by NOSEC ostensibly to assist in penetration testing. The tool can be used to detect SQL injection vulnerabilities on a web application, and upon detection allow the user to perform certain operations such as DBMS fingerprinting, retrieving user ids and hashes, dump tables, run SQL statements, and so forth. NOSEC is a web site hosted by a firm now called Connaught Cup in Shenzhen, China.
What is SQL Injection?
SQL Injection is basically a code injection technique that attempts to get an SQL query to execute via data inputted into a field from the client to the application. For example, let’s say we have a piece of code like this:
SELECT id FROM logins WHERE username = '$username' AND password = '$password’
The fields $username and $password are coming from the browser. Our user normally logs in by entering John as user id and ‘Password1′ as his password (he shouldn’t have a weak password like that, but he does). The query analyzes it, sees the $username = John and checks to make sure password = Password1. The password statement evaluates as true, and the web application authenticates or logs in the user.
A bad actor comes along and inputs John as the user id ,but instead of a password he fills in anything’ OR ‘x’='x. Let’s see how our code evaluates this:
SELECT id FROM logins WHERE username = 'Joe' AND password = 'anything' OR 'x'='x'
Now the AND password portion of the query is always returning true, not just when the password is actually the correct one. That’s because we’ve changed the execution of the query, now it reads that password can equal anything OR x = x. x will always equal x, they are equivalent values, thus the password = statement evaluates to true and the web application authenticates the user even though a proper password was never supplied.
SQL Injections in practice get much more complex than this, but the basic premise remains the same, attempt to get the web application to execute a SQL query in a way unanticipated by the web site’s developers in order to get the application to reveal information or perform a database action.