Disaster recovery anyone?
I wonder if they were doing a DR test which went a bit awry? I wouldn't be surprised if this carried on into next week. After all this time it doesn't seem like a network issue.
21 posts • joined 20 Nov 2007
> and corrected the problem immediately
OK, so they got in touch with Google did they to get them to delete it from their cache? Or did they just delete the db table? Somehow I don't believe these guys when they make these simple errors that they don't notice but someone else does and they seem to know immediately how to fix it. Wasters.
to the developers of these sites. A day doesn't go by without hearing about more sql injection exploits. Just take at look at xssed.com as an example. And it'll be high up on the list of programming errors on sans.org and owasp.org's top 10 security vulnerabilities, I'm sure.
I attended a meeting with Mr Klein, the CTO of Trusteer, a while back. He asked how effective AV software was these days. He replied that it picked up only 40% of the viruses and malware out there. So I guess if Trusteer can show how good they are at detecting the bad stuff that AV products can't then that's priceless PR for his cause. After all he's in the market of selling his products to the banks!
Paris, because I'd rather she protect my assets.
> CookieMonster then injects images from insecure (non-https) portions of the protected website
So that means the vulnerability exists only if the secure site makes an http request. If the site always sends https, including requests for images and other resources, then there is no vulnerability. Agreed this would require a full scan of the site to ensure it was fully secure though.
There are loads of sites that accept usernames and passwords over an http connection before going to SSL, e.g. web mail apps.
Stop - because we need to think not panic.
Remember 3 words:
Treat all input data is evil. If you limit the number of characters accepted for each item of input data, sanitize it, perhaps to accept only alphanumerics, and validate against a regular expression or list of acceptable data, you're pretty well home and dry.
Managers are only interested in getting a product out the door. Security minded developers are more interested in stopping the company from hitting the national press with the latest ID theft story. Which do you think is more important?
Love heart because this stuff keeps me in a job.
It's nice that MS have come clean and implied their online services aren't secure.
Sure, all online services have vulnerabilities but where's the dividing line between an ethical hacker / researcher and someone who's looking for that vulnerability that their next trojan can exploit? How does this stack up against the Computer Misuse Act in a court of English Law?
I give them a big thumbs up though and wished others would follow suit. More people should take notice of what's posted daily on the xssed.com site too.
"an amazing amount of data" and "Network forensics show the hackers were able to access sensitive information, which they encrypted as they transmitted it back to their sites."
So The Pentagon has broken the hackers encryption to find out what data was gleaned? If they know how to do that and there are 70,000 malicious entry attempts per day, then how come it's gone on for so long?
"a known Microsoft Windows vulnerability" - don't tell me that Pentagon PCs are not fully patched with security updates...
Maybe they're preparing a subpoena against MS.
"Can you help me please? I can't send any emails" came the cry for help. Actually I'd setup his computer last year so he could still send emails using his Sky email address but emails that he used to send through his Tiscali email address have suddenly stopped working. After 1.5 hours of playing with his Outlook settings remotely came to nought so I gave up. He's not too cuffed about it.
This posting on Heise Security's site about frame spoofing shows that just checking the certificate does not give you a 100% guarantee that you're sending your credentials to the right site.
This article might be a bit old now (I haven't tested the links) but the fact that it's still happening (links below) show that this attack vector hasn't gone to bed yet.
My motto is if your bank uses frames on their credentials entry page, don't use their internet service or move to another bank.
In fact this applies to any site that requests user credentials. And to access my tiscali web mail, guess what? Credentials are sent in the clear. Great!
And slipping to No 8 are web application security exploits. This has been moving up the list over the past decade as network attacks have become harder to do. I'd have expected this to be placed higher. One only has to visit the XSSed site to see that there are loads of insecure sites (although the most valuable tend to be the ones secured by SSL).
I'd put Insider attacks higher than No 5 though. We just don't know how much of this goes on as it's likely to be covered up.
Don't you just love technology. At least my trusty Nokia 3210 phone isn't prone to internet and bluetooth attacks!
Hmm, so 25 million records fits on 2 CDs but 3 million names and addresses, and not much else, requires a hard drive. I kinda lost the plot here. Why does a hard disk need to travel across the big pond? Surely 1 CD with its contents encrypted would have been adequate? Is someone not telling us anything here?
For years we've been told not to write our passwords down and here's evidence that the message isn't getting through! I wouldn't advocate anyone doing this.
While I don't use the Barclays PinSentry device, I've used one in a development project. There is a security flaw with authenticating yourself with one of the devices. If you go down the pub and show it to your mates, and one of them remembers one of the numbers (he'd have to be numerically minded as they tend to be 8+ digits long), he could potentially sign in to your online bank account using it. It's a valid number and will remain so until the real owner actually uses the card reader and a new passcode in their bank's online site. OK, he'd also need to know your username and possibly your date of birth or something personal about you, but it would be possible.
Despite this, I'd use it if my bank introduced it. As more banks roll this technology out, there will always be someone else that has a reader if you forget to take yours to work. Then I'd have to watch out for the man in the middle scams. How many people are so paranoid that they check the certificate for the web site they're accessing these days? Count me in.
On BBC News this evening they said that the reason why *all* of the data was sent rather than just the names and NINOs was that it was too complex to extract just that data. Lesson number 1 in SQL:
select firstname, middlename, surname, NINO from ChildBenefits order by surname
OK, it might be a little more complex than this as it's probably an ancient ICL or DB2 database. Perhaps it's true they are under-resourced in the IT department or perhaps EDS said it would cost £3000 to do the job. Or perhaps the next batch slot to run the query was in 2008.
It's probably happened. Just that we haven't heard about it.
Now let's see. Ah, yes, Davey Winder's article in this month's PC Pro shows that full identity details exchange hands for $10 - $150 a time but bank account info is even more lucrative. 25 million records makes this a very nice retirement fund for someone, even after applying discounts. You'd have better chances getting a good return with this data than winning the lottery.
How can we trust a government that announces this fiasco and then says they've informed the banks. Shouldn't they be informing the credit reference agencies as well because fraudsters use these details to open bogus accounts and sign-up to mobile phone contracts. At the end of the day it's the consumer that has to sort out the mess when id-theft occurs.
I wonder how I'd get on prosecuting HMG if I suffered id-fraud? I hope the Information Commissioner throws the book at HMRC.
http://www.cabinetoffice.gov.uk/csia - for a hypocritical laugh.
Biting the hand that feeds IT © 1998–2019