UK Parliament website hack exposes shoddy passwords

A vulnerability in the website of the UK Parliament appears to be exposing confidential information, including unencrypted login credentials, a Romanian hacker wrote on his blog. The SQL injection vulnerability is on this page, the hacker, who goes by the moniker Unu, told The Register. By tacking database commands onto the …

[Martin 6]

Why have a passwd?

I don't have a lot of sysadmin experience - but if you are running a site likely to be such a target why allow network logins to the box at all?

Surely for the occasional need to change the logo of the current set of crooks you can send someone to the console?

[Frumious Bandersnatch]

I say we ...

extradite this Unu fellow. Then bring back hanging. That's the only way to deal with these "hacker" types.

[Moss Icely Spaceport]

Moss?

I see Moss is one of the users.

Surely HE wouldn't make such a mistake!

[Anonymous Coward]

If your site is vulnerable to SQL injection you deserve everything you get.

It's neither difficult nor expensive to scrub input data.

[Anonymous Coward]

Has little Bobby Tables visited the site yet?

And how long before he does? This is the kind of thing The Daily WTF would be all over in a heartbeat.

[Chris Miller]

I wonder

who set up the web site. Two obvious possibilities suggest themselves:

a) the teenage child of an MP in need of a summer holiday job; or

b) EDS (or one of the other usual suspects).

In either case a severe beating with a clue-stick would appear to be in order.

The really depressing thing is that I can no longer tell the difference between the handiwork of a clueless teenager and a major IT corp.

[Jay Castle]

Am I stating the obvious?

Has anyone else found that, despite the blurring, the password for 'fulera' is stupidly easy to see, especially with the Reg's helpful superhero hint?

It just jumped right out, soon as I looked at it!

Big fat FAIL to the Government, once again. Silly fuckers.

[Anonymous Coward]

Sad?

They have not got a clue have they?

[batfastad]

SQL Injection?

That really is shocking that a site as high-profile as a government site is vulnerable to SQL injection. It's the most basic type of attack that can be directed at web applications and the first thing I always make sure I've got licked. Proper input validation is essential.

Sums UK.gov up really!!

Anyone for a national database?

[SmallYellowFuzzyDuck, how pweety!]

My local theater uses good passwords

I was in there last year buying tickets for a show.

One old dear was entering booking information into the system and in front of everyone asked the person next to her what the password was.

"It's P-a-s-s-w-o-r-d" replied the other one.

[Anonymous Coward]

@AC

"Has little Bobby Tables visited the site yet?"

No but I think someone should copy the existing tables and then drop them all.

That will shake someone enough to make them close this security hole...

[The Vociferous Time Waster]

Bobby Tables

For those who don't get the reference...

http://xkcd.com/327/

...you should be ashamed of yourselves.

[ooooorange]

Senior-Schmeenior

Every time, I'm still amazed at how many "senior" developers are absoloute retards with no understanding of proper design or security.

[Bogdan Stancescu]

Mosaic doesn't work well with thumbnails

Brains work in strange ways. Looking at the mosaiced image in full res doesn't produce any hints as to what the passwords might be. But looking at the thumbnail as shown in the article, one can easily tell the arachnid superhero's name, and it's also very easy to guess which of the other accounts have the same password as the account name. Of course, it's too late to do anything about this now -- I'm certainly not the first to notice that...

[Anonymous Coward]

Good job GCHQ

In the last two months, XSS vulnerabilities in MI5 and the MOD. Last week I prove it was possible to turn the NHS website into a Weapon of Mass Destruction using XSS, now parliament is exposing herself due to SQLi.

According to http://www.gchq-careers.co.uk/default.aspx?id=3

"Our role is also to protect the Government’s communication and information systems from hackers, interference and disruption."

[Jon Thompson 2]

What do you expect?

Half of the government is still mandating IE6!!!!!!!

[Anonymous Coward]

Live box...

...showing php errors on the page. N00bs.

[Daniel 1]

Going native?

It's great to see that they're abstracting the data adapters, rather than using native function calls for everything. I mean, only spaghetti-coders use the native function calls in the raw...Oh, wait.

Failing that, maybe the Great School of "Use Native Functions For Everything" should teach its followers about mysql_add_slashes, before they teach mysql_fetch_array?

[bobbyC]

The source of all your problems

If you can't make a secure website, probably best not to leave the company name, "Reading Room", in a file:

http://lifepeeragesact.parliament.uk/css/styles.css

...assuming that they were also responsible for the development of the site.

[dunncha]

Nothing to Hide - Nothing To Fear

Its so obvious.

We are so confident that we have nothing to hide that we leave our websites open for all to inspect....

or

These are honey pot servers. They are designed so that Hackers can breach security on these minor sites and leave the more important sites along.

or

Ohhhhhh. Look over these TERRORIST!!!!! ... What webpage? Where? Don't know what you are talking about. Is that your camera sir?

Choose you own excuse and issue to increasing less gullible public

icon: Shouty: Do something different Vote for a change

[Anonymous Coward]

As of 10:44 02/09/08

They're "working on and [sic] fix"

[Lee Dowling]

WHY?

Allowing this sort of database access from a website is a COMPLETE no-no. Ignore whether the passwords were encrypted or not, that's not an issue.

But a website that allows modification of SQL queries in the URL string... you might as well just turn the machine off for the good it'll do.

Seriously, what's hard about submitting the page query data to the server (NOT as an SQL query, but as form entries), having the server scripting language sanitise that information down to the invididual elements on the submitted form and building its *own* SQL query from pre-defined stanzas that it concatenates based on the form data. If you have a brain, you even make correlate the form data against the login/form accessed to ensure it has access BEFORE you build the SQL query. In this way, it's impossible for someone to turn SELECT ALL FROM... into DROP TABLE or anything else equally as dangerous, such as accessing private fields with passwords in them. The worst that'll happen is they might find some concatenation of the pre-defined stanzas that reveals a *little* more information than you wanted them to.

This is like having a DOS command prompt in every page of your website, and the commands typed in are tacked onto the URL and executed as-is by the server-side. It's *that* dangerous and, yes, *that* stupid.

http://www.theregister.co.uk/?deltree_C:\*.* <-- would you allow that to even be POSSIBLE, let alone likely to actually execute (even if running on a read-only filesystem)? No. So don't embed ANY form of direct SQL in GET/POST queries.

[Graham Marsden]

As of 11:49 02/09/09

At least they've fixed the "and" typo! (Maybe someone there reads El Reg?!)

"This site is currently unavailable, we are working on a fix and should have the site available again soon. Thanks. "

PS AC above, nice time machine you have... ;-)

[Anonymous Coward]

@Jay Castle

Yep, I posted it as a comment, but it wasn't published.

QED, correct.

[Scott 19]

@Micheal 2

You first.

[Anonymous Coward]

@Michael 2

Actually, this kind of security stuff (i.e. preventing SQL injection attacks) really IS easy, for anybody with half a brain cell.

The fact that you seem to think otherwise suggests that you aren't qualified to be contributing to this comments section.

[Cucumber C Face]

Not just easy to avoid - avoidable by basic good practice

Even building SQL in your server side scripts (dodgy), the most basic input validation you should be employing simply to prevent your lusers generating errors with sloppy input / half baked urls will hose most injection attacks

i.e. your script should (even on a secure intranet and working on non-critical data)

1. enforce data type validation

2. truncate input strings of over 'n' characters

3. escape 'escape' characters (or filter them out) as appropriate

That these are not in place demonstrates lack of the most fundamental competencies.

Paris - because she regularly demonstrates a fundamental competency.

[Anonymous Coward]

is it just me....

or can anyone else still read the obfuscated passwords in the smaller pic?

[Ed Blackshaw]

@Michael 2

I really really REALLY hope you don't ever do any work that involves databases and the web. SQL injection attacks are THE best known, and most common web vulnerability. In most cases, it is trivial to sanitise ones database inputs e.g. if parsing a parameterised string into a database as the contents of a field, replace all single quotes with escaped ones - of course this varies with database back end and there may be other things that need to be escaped. Any programmer worth their salt would already be doing so without even thinking about it, particularly since it is the sort of thing that tends to get stressed quite heavily on any university level comp-sci course, web security seminar, etc. Most modern web-based languages provide functions that will do this for you as part of the language (PHP and PERL are two that spring to mind), so there really is no excuse.

Personally, if I were running a web site that points to any sort of database (I'm not, but I do do a lot of database work, and the same principle applies to any front-end on a database), if a SQL injection vulnerability were discovered, the first thing I would do is to take the entire site down. The second thing would be to find the programmer responsible and re-educate them BOFH style.

[Doug]

the website reflects poorly on Parliament ?

No, the website reflects poorly on the people who designed and configured the web site. What are their names again?, just so as we can avoid them ...

[Chris Miller]

Easy != Simple

It's easy to fix a single page that contains a SQLi vulnerability. It's reasonably easy to ensure that a new web site being built from scratch won't contain this type of vulnerability, though this can get tricky if there's a large team of programmers involved - you'll need some decent QA tools.

Now, what if you take over a large, complex web site with many hundreds of pages, lousy or absent documentation and poor structuring. Still think it's trivial to eliminate all input sanitisation errors? If you do, I hazard a guess that you've never been in this position.

[John Latham]

Salty hashes

Whatever about SQL injection and password strength enforcements, passwords should not be stored in clear text.

I would have thought that fcking obvious to anyone with half a brain.

Burn them! Burn them all!

[Anonymous Coward]

@chris miller

grep mysql_query `find . -type f `

or the relevant languages, that 2000 pages checked for fo code vulnerable to SQLi vulnerabilities, protecting against displaying XSS output, that's a lot more tricky.

[Anonymous Coward]

Once Upon A Time

It was the business of computer departments with committed staff, and the idea, especially in public organisations, of long-term employment.

Then the idiots in coloured shirts with white cuffs and collars came along.

Time for a *complete* culture change.

[Jon 52]

@bobbyC

Someone this lax on security probably just "borrowed" the css from another site and didn't take the name out.