That members of scumsec are outed and run into some of their victims down a dark alley.....
A dating website for US soldiers was hacked and its database leaked after it blindly trusted user-submitted files, according to an analysis by security firm Imperva. The report highlights the danger of handling documents uploaded to web apps. "LulzSec Reborn" hacktivists attacked MilitarySingles.com and disclosed sensitive …
..some real advice on how to properly secure a password-based system:
A) Store all usernames and passwords on an entirely different machine and an entirely different database. The "credentials" server will only handle authentication requests through a well-defined (proper grammar), simple TCP interface. All other services including X11, ping and so on will be disabled on this server. The server will be completely firewalled except for that specific port.
Application code will query this server for authentication purposes via a TCP socket and will then proceed to do the usual SQL against the "app" database.
B) Store a "retry counter" along with the password hash and lock the account for half an hour after five bad attempts. Lock for a day after 15 wrong attempts.
Then even passwords such as "apple15" will be quite secure.
If only there were some sort of system which did this? NDS, AD, LDAP, etc.
It seems to be a trait in developers to develop solutions to problems which have already been solved, in a much better more functional way by specialists in the subject. I speak as someone who specifies code to be created by developers for a reporting product. It is incredible the amount of times that we get problems in the report and the developers' solution is to just hack some script together, rather than ask the subject matter expert for a proper programatic solution.
@The crew is apparently "not as motivated" as the original LulzSec, according to Rachwald, adding that it has made little or no contribution to IRC chats and hacker forums.
So in otherwords they are making an attempt not to get caught, unlike the other fools? Stay low, do your business, get out safely.
I agree : leave the soldiers alone !
They're already in the line of fire on a daily basis, no need to add to their misery.
Besides, antagonizing them is a really stupid idea. Not only does a soldier have access to way more firepower than any script kiddie will ever get in his wildest dreams, but said soldier also has training that would make a script kiddie drop dead from exhaustion just thinking about it, and a group of well-trained, dedicated and loyal buddies to guard _his_ back while he plans to hit the aforementioned skiddie when the lump of blubber is least expecting it - like 24/7 actually.
So yeah, you want to antagonize the military ? How about hacking into the confidential files of a general-rank guy, instead of targeting the rank and file. I guarantee that you'll get a much quicker reaction that way, and much greater exposure.
Of course, said exposure just might be to the 2500°C blast (number drawn out of thin air) from a smart bomb but hey, you never specified what kind of exposure you wanted, right ?
Let's look at the article again:
Hackers uploaded a PHP file that posed as a harmless text document and then commandeered the web server to cough up the contents of its user and a hashed password database.
How should that be even possible? The story isn't really "the danger of handling documents uploaded to web apps". Dangers ahoy there are, but that's not the real WTF here.
The problem is that here there's no separation between code and data in the environment, which is bloody stupid. Scripts should only be run by the webserver in the directories that are assigned to code, and uploads should only go to directories that are assigned to data. Moreover, these directories should be completely distinct. If you mix the two, you are asking for trouble.
(And if the language or framework makes it hard to separate the two - I suggest use a new language or framework.)
Biting the hand that feeds IT © 1998–2018