Unu Cracks a Wall Street Journal Conference Site, Not WSJ.com

WSJ_ceocouncil_top

Unu, the security researcher from Bucharest Romania known for performing unsolicited penetration tests on brand name web sites with a concentration in SQL Injection is at it again, this time with a claim that he cracked WSJ Online. Per Unu: “Traffic Rank 88 in U.S., by Alexa ‘WSJ online coverage of breaking news and current headlines from the U.S. and around the world. Top stories, photos, videos, detailed analysis” …and a big SQL Injection’”. Unu did identify a Wall Street Journal branded web site that is vulnerable to SQL Injection attacks. But the site is not WSJ.com, is not on the same servers WSJ.com is on, is not a site hosted by Dow Jones-Teleratel but rather a conference site hosted by a WSJ vendor called MAP Digital, Inc.. The extent of the sensitive data breached appears from the screenshots to be the e-mail address and phone information for reporters associated with the 2009 CEO Council event that happened November 16th and 17th in Washington D.C..

The CEO Council?

We’ll let the WSJ explain:

The Wall Street Journal CEO Council met in November, 2009, to develop an urgent action plan for ensuring long-term global prosperity, with an emphasis on the shared responsibility of business and government. Council members developed recommendations for business strategy and government policy.

Here’s some video from the event:

Let’s Get Started

Unu starts us off with this screenshot showing a SQL injection where he was able to execute the load_file command for files containing data including database names for a MySQL installation and the etc/passwd file for the Ubuntu Linux installation. The /etc/passwd is a text file on Linux/Unix operating systems that contains a list of the system’s accounts. For each entry it lists information such as user ID, group ID, home directory, shell, etc. all needed for login to the operating system.

Successful attempt of load_file MySQL command.

Successful attempt of load_file MySQL command.


The above URL in the screenshot is the equivalent of executing the command shown below in MySQL, and if you can do it from the web site it is not a good sign as he elucidates (if you can read files you can usually write them as well as attempt to get a shell):

mysql> select load_file("PATH_TO_FILE");

Unbelievable?

In the second screenshot, Unu states the following: In the second picture we see a more serious problem. One of the users (ffi2009uk) is % the host and NOTHING in the password. This means that from any IP we can connect to MySQL server on his account without any password. Unbelievable !!!. Ok, assumes port 3306 is open on the machine, the host has been inaccessible for the https site so we’re not sure.

/etc/passwd file.

/etc/passwd file.


/etc/passwd File

Again most of what you’re seeing the passwd file. Most modern Unix OS installations like this Ubuntu install no longer have passwords in /etc/passwd, but rather a shadow file that is read/write to root and read to the shadow group:

~$ ls -l /etc/shadow
-rw-r----- 1 root shadow 971 2009-04-14 17:37 /etc/shadow

The x character next to each id in the screenshot indicates that the encrypted password is stored in the /etc/shadow file. In the past, weak encryption (ex: DES) was used to secure the password directly in the passwd file, and once obtained could be trivially broken with a password cracker like John the Ripper.

The seven fields in /etc/passwd are as follows:

  • login name
  • optional encrypted password (but almost always ‘x’ these days)
  • numerical user ID
  • numerical group ID
  • user name or comment field
  • user home directory
  • optional user command interpreter

Back to MySQL

Getting back to Unu’s screenshot, a new id is showing up (recall there are two other screenshots from Unu showing primarily what’s in /etc/passwd) called “ffi2009uk” with a wild card ‘%’ character. In the part of the URL we see, he did request this: concat(user,0x3a,host,0x3a,password) which would show ‘user:host:password’ if successful (0x3a is hex for ‘:’).

It appears Unu did get the MySQL user id table which would show host, user, and password where ‘%’ as host would mean “any host”, and I guess in this case there is one id (can’t see exactly what SQL query he ran from the screenshot): ffi2009uk. This was also the name of one of the databases from screenshot 1 (easier to remember that way?).

Plus FFI 2009 UK, is this another conference for someone else? Sure is, as shown by what appears to be the development version of the web site for the 12/7 – 12/8 conference in West Sussex, UK. Hmm…same type of web application, wonder what running schemafuzz.py against this would do?

Here’s an example of what the mysql.user table usually looks like (professional applications usually use one of MySQL’s built in encryption functions):

% ./bin/mysql -u root -p
Password:
mysql> SELECT Host, User, Password FROM mysql.user;
+-------------------+------+-------------------------------------------+
| Host              | User | Password                                  |
+-------------------+------+-------------------------------------------+
| localhost         | root | *CFA9B6705C7FB82E4CBDE4E1189F937A08227785 |
| someotherhost | root | *CFA9B6705C7FB82E4CBDE4E1189F937A08227785 |
| someotherhost |       |                 |
| localhost         |       |                 |
+-------------------+------+---------------- ---------------------------+
4 rows in set (0.00 sec)

Tool Used?

What tool did Unu use to find this SQL Injection vulnerability? It could be rsauron’s schemafuzz.py based on the ordering of the screenshots Unu provided and the way the URL is constructed in those screenshots.

About Those Reporters

One of the more interesting tables Unu enumerated by doing a UNION and SELECT statement on one of the tables via the URL is a table of contacts for reporters of which he says: In the next picture we have personal data, address, phone number of the members of the press..

Table of press contact information.

Table of press contact information.


While the names and phone numbers of reporters might seem like a data breach, a lot of time reporters already have this information available online. We checked a few from Unu’s screenshot:

  • Susan Heavy, FDA & Health Correspondent, Reuters – Both phone and e-mail already available online.
  • Bob McNaney, Reporter, KSTP-TV(ABC) – E-mail already available, alternate phone number available.
  • Rob Wells, Washington Bureau Chief, Dow Jones – Both phone and e-mail available
  • Joann Lublin, Management News Editor, Wall Street Journal – Both phone and e-mail already available online (separately).
  • Kathy Shandling, North American Rep., Global Water Intelligence – E-mail not online but easily discernible because @globalwaterintel.com always uses first initial + last initial in other examples found. Phone number available via Google Phonebook.
  • Ok, I’m getting bored with this…

The point is names, positions, business addresses, phone numbers, and e-mail addresses of reporters (persons who generally make themselves available to be contacted) are not sensitive information.

The Penultimate

Next we hear about the CEO’s, and see a screenshot with CEO user names including those of Henrik Slipsager (ABM Industries), Evan Greenberg (ACE Limited), Mike Szymanczyk (Altria Group, Inc.), and Morris (maybe Mike Morris of American Electric Power?).

wsjceo.users table.

wsjceo.users table.


Notice anything about these id’s and passwords? The first three look like default passwords (sequential) meaning: the person never logged in, logged in once, or that you can’t change your password on this site. We couldn’t tell from what MAPDigial has posted online.

  • CEO-00…
  • CEO-03…
  • CEO-04…
  • CEO-29b..
  • CEO-6d6c.

Anyway, its not clear what data is exposed via this if any, from the tabs on the site it looks like you can register, review the program and event details, and so forth. Unu doesn’t let us know what happens when one of these id/password combinations is used, but the Wall Street Journal may tell us tomorrow.

You could probably annoy some CEO’s by sending them messages through the web site, if this generic page MAPDigital shows as an example is the same you would get on the WSJ CEO Council site:

Go ahead, ask a question.

Go ahead, ask a question.


It might have been more interesting if Unu grabbed the “registrations” table we saw in the first screenshot, then we’d have the contact information of almost 100 CEO’s (or at least the administrative assistants who registered them). Too bad, I see Rupert Murdoch attended, I would have liked to have gotten his phone number so I can ask him about news syndication on the Internet. Maybe Unu will send it to me. Working off of the generic screenshots at MAP Digital’s web site, here is what would have been filled in:

Metameeting, generic registration page.

Metameeting, generic registration page.


And I hope that they are not storing the information gathered via the form shown in this screenshot in any of their MySQL database for other clients (the WSJ did not have the ‘Payments’ tab in the screenshots Unu showed):

If this is in that MySQL database, Houston we have a problem...

If this is in the MySQL database of other clients, Houston we have a problem...


I wonder if they are PCI compliant…

And Admin…

Finally Unu shows us that an admin account is right there as well.

admin:map99...

admin:map99...


But if its not WSJ.com, what is it?

As alluded to earlier, the server itself appears to be owned by a company called MAP Digital, Inc., which hosts or “powers” other Wall Street Journal conference sites such as https://insightexchange.wsj.com//index.php (up until today) as well as event sites for J.P. Morgan, Deutsche, Morgan Stanley, Phizer, and NYU according to their web site. MAP Digital creates “Conference 2.0 solutions with metaMeetings” a suite that manages among other things: Online and Onsite Registration. The footer from the Insight Exchange web site reads as follows:

WSJ...powered by MAP Digital.

WSJ...powered by MAP Digital.


Below are the quick look ups we did based on the url’s for both the Wall Street Journal Online and the ceocouncil.wsj.com web site to show that owning the box would not provide access to the same resources the newspaper web site is hosted on.

ceocouncil.wsj.com:

whois -h whois.arin.net NET-64-124-160-64-1 (:~)

CustName: MAP DIGITAL
Address: 56 Ludlow, Gr. Flr
City: New York
StateProv: NY
PostalCode: 10002
Country: US
RegDate: 2004-12-29
Updated: 2004-12-29

NetRange: 64.124.160.64 - 64.124.160.127
CIDR: 64.124.160.64/26
NetName: ABOV-N318-64-124-160-64-26
NetHandle: NET-64-124-160-64-1
Parent: NET-64-124-0-0-1
NetType: Reassigned
Comment: Abuse Contact Farid Khan, 917-202-4415 [email protected]
RegDate: 2004-12-29
Updated: 2004-12-29

wsj.com (one example):

whois 205.203.132.65 (:~)

OrgName: Dow Jones-Telerate
OrgID: DOWJON
Address: 4300 North Route 1
Address: Bldg. 1
City: South Brunswick
StateProv: NJ
PostalCode: 08852
Country: US

NetRange: 205.203.96.0 - 205.203.159.255
CIDR: 205.203.96.0/19, 205.203.128.0/19
NetName: DJTLRCLIENTS
NetHandle: NET-205-203-96-0-1
Parent: NET-205-0-0-0-0
NetType: Direct Assignment
NameServer: NS6.DOWJONES.COM
NameServer: NS2.DOWJONES.COM
Comment:
RegDate: 1995-05-02
Updated: 2004-02-11

But it says Wall Street Journal, aren’t they responsible?

One could argue this a number of different ways, here is our take. When your brand is on something, your obviously taking some ownership of what’s there and will end up answering questions if something goes wrong. Unu has not offered proof that sensitive data was exposed during his exercise where he successfully showed that the ceocouncil.wsj.com web site is vulnerable to SQL Injection attacks. That must be considered in the risk evaluation of this exposure.

The site is the work of and hosted by a vendor company. The site has serious web application related security flaws which would likely lead to exposure of the box the site is hosted on. They may want to hire Unu to help them clean up this mess. We have no idea what else is on that box, but we can tell you that the Wall Street Journal the newspaper is not. So the ‘sexiness’ of what was found is certainly minimized when you say: “The product of a vendor company used by the Wall Street Journal once a year for a conference is poorly designed from a web application security standpoint as demonstrated in these screenshots of a successful SQL Injection” as opposed to “The prestigious Wall Street Journal exposes CEO passwords”.

But, you say, the Wall Street Journal is responsible for the products the vendors it hires makes. Yes, they are to a point and at different levels (what does the contract between WSJ and the vendor say, will people be able to draw the distinction between what site was attacked, etc.).

Those who have worked in corporate information security are familiar with conversations like this:

  • Business Person: Hello CISO, can you check out this vendor product we want to use?
  • CISO: Sure, hey vendor, send me your last security test results.
  • Vendor: We don’t have those.
  • CISO: Ok, then my team is going to test what you’ve got.
  • Vendor: We can’t let you do that for .
  • CISO: Ok, I’m going to recommend we don’t use this vendor.
  • Business Person: But they are the only ones who responded to our RFP and make the application we want.
  • CISO: What data is involved?
  • Business Person: No PII (personally identifiable information) if that’s what you mean?
  • CISO: How embarrassed will we be if say a Romanian shows that the site is vulnerable, or if someone defaces it.
  • Business Person: I don’t know.
  • CISO: I recommend we don’t use this vendor, but you can sign off on the risk of using them if you feel strongly about this, because the overall risk to the organization does not rate this at the highest level of risk.

Ok, this is a little tongue in cheek, but you get the idea. Security pros can sit around being sanctimonious about how vendor security and due diligence should work but inside we know the practical limitations and difficulties of real life business situations (time lines, risk posture, business person’s opinion), remember that hindsight is 20/20, and recall that vendor due diligence and imposition of security standards doesn’t always go so smoothly. Or put another way, most security folks won’t stake their career on blocking a vendor built conference web site from being launched into production even if they are uncomfortable with the vendor’s approach to security (except if they’re collecting credit cards, then all bets are off).

Who’s Unu? (from a previous post)

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 SQL Injection? (from a previous post)

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.

Finally

Don’t get the wrong idea from this and the Barack Obama donation’s site blog post, we like Unu. Part of us sometimes wishes we lived in Romania so we could test sites with impunity. Unfortunately we’re limited to playing in our lab. On balance much of what Unu reports is mostly true. We do wish he would provide more details in his blog posts, and maybe he could give his finger a rest from all that wagging, but keep posting because we enjoy reading it.

Update

Steve Ragan over at The Tech Herald received an update from the Wall Street Journal stating that the problem has been corrected and that WSJ sent an e-mail with the copy below to every registered user of the web site:

“We are writing to inform you that there has been a security breach on the Web site for The Wall Street Journal’s CEO Council (http://ceocouncil.wsj.com). Rest assured that no credit card or other financial information is stored on the site, so the data that was exposed is limited to contact information only. No financial information is ever kept on the CEO Council site. We wanted to notify you immediately about this situation as a precautionary measure.”

“The Web site is hosted by a third party and is not on our internal systems that host the majority of the Journal’s Web operations. At this point, we have had the vendor shut down the vulnerable parts of the site. The security and privacy of our members are of utmost importance, and we take it very seriously. You have our assurance that we have taken every measure to correct the problem and prevent it from happening again.” – Wall Street Journal representative.

References:

Filed Under: SQL Injection

Tags: , ,

Comments (6)

Trackback URL | Comments RSS Feed

  1. Rob says:

    Great analysis & absence of hyperbole for a pretty high profile site hack. Thanks.

  2. Steve R says:

    Nice breakdown. I’m still waiting from the WSJ communications people to get back to me. However, like before, I’m going to move your comment up to the article as a brief update.

    -Steve

  3. DAve says:

    “What tool did Unu use to find this SQL Injection vulnerability? It could be rsauron’s schemafuzz.py based on the ordering of the screenshots Unu provided and the way the URL is constructed in those screenshots”

    Why u talk if you don’t know ? :) Please ,shut up.

    P.S.: I was dropped on my head as a child.

  4. Prefect says:

    Dave - Well, its a good tool for finding SQL Injections on MySQL. The pattern of requesting concat(user,0×3a,host,0×3a,password) matches what the schemafuzz tool does. The ordering, check for load_file first, is how the schemafuzz tool works also. That said, we can’t guarantee it was that tool, we just think it was, so we mention it.

    Now that we answered your question, can you answer one for us?

    Why do learning disabled jackasses post comments on blog posts asking stupid questions and making asinine suggestions?

  5. [...] vulnerabilities on major sites including recently two Kaspersky international properties and a Wall Street Journal conference site has demonstrated an attack on an Intel web property, [...]

  6. We really enjoy what you write about here. We try and visit your blog every day so keep up the good writing!