Live data from Hacker News

Twin brothers wipe 96 government databases minutes after being fired

arstechnica.com

141–150 of 463 posts

Re: Twin brothers wipe 96 government databases minutes after being fired

#141
post #79

Earlier quoted context omitted.

Typically you store a hash of user passwords instead, then when logging in you hash the user password client-side and compare the hashes. This acts like a one-way function that protects the password while letting the user authenticate themselves.

Hashing passwords client-side is generally a bad idea, since it means that the hash effectively becomes the password. For example, if I have a database row that has the hash of the password and a bad-guy gets access to the database, they will get the hash. The benefit of a hash is that it is a one-way operation, I can't figure out the plaintext from the hash, so my account is safe. If the password is hashed on the cl…

You actually want to one-way passwords both client-side, for transport, and again server-side, for storage/comparison.

Otherwise, there's a hole, between the end of the TLS connection and where the server-side encryption happens, where the password is in plain text. Think logs and load-balancers and proxies.

While the client-side hashing doesn't help protect your site a lot (as you say, the hashed value the client sends effectively becomes the password), it helps protect the users who use the same password across multiple sites.

Notice in this case, that's exactly what the brothers are accused of doing: using credentials harvested from their site to log into other, potentially more lucrative accounts.

I didn't see if that's the hole the brothers exploited but it very well could have been.

The client-side encryption may have been all that was missing in this case.

Re: Twin brothers wipe 96 government databases minutes after being fired

#142
post #24

Earlier quoted context omitted.

Or if you don't want to booby trap your code, buy one of those tiny devices that make a cricket noise randomly every 5-15 minutes, and hide it somewhere in the restroom. https://annoyingpcb.com/

These are too obvious - 5-15 minutes gives your victim way too many opportunities to narrow down the location. What you really need is one that chirps once every (multiple of) 20-28 hours (with weighting towards 23-25 to keep it roughly around the time you set it going and an infrequent skipping of a day.) Also with different volumes and, ideally, different chirps. Occasionally a double chirp just for extra insanity…

Next time I'm bored and need a project, I'm building that ;-)

Re: Twin brothers wipe 96 government databases minutes after being fired

#144
> Muneeb and Sohaib Akhter, now both 34, had been in trouble before. Back in 2015, the brothers pled guilty in Virginia to a scheme involving wire fraud and computers. Muneeb was sentenced to three years in prison, while Sohaib got two.

After their stints in jail, the brothers worked their way back into the tech world. In 2023, Muneeb got a job with a Washington, DC, firm that sold software and services to 45 federal clients; Sohaib got a job at the same company a year later.

What in the actual fuck. I'm all for giving people second chances. But maybe some ringfencing?

Re: Twin brothers wipe 96 government databases minutes after being fired

#145
post #79

Earlier quoted context omitted.

And how exactly do you want to store passwords if not in plain text (and then encrypted of course)? 5k is a lot, the authorization process is broken, but this is not related to how the passwords are stored. The only solution is correct access segregation and a bastion

Typically you store a hash of user passwords instead, then when logging in you hash the user password client-side and compare the hashes. This acts like a one-way function that protects the password while letting the user authenticate themselves.

People shouldn't be downvoting this...

Hashing client-side is a good idea. You must also hash server-side, for storage/comparison.

Otherwise, an insider may be able to harvest the original password, from logs, proxies, load balancers, etc. that requests pass through after the end of the TLS connection, on the way to the db.

They can then try the credentials on other, perhaps more lucrative sites. That's what the brothers are accused of doing here, so client-side hashing (or just simple encryption) may have been the missing piece of security that would have thwarted the credential stealing.

Re: Twin brothers wipe 96 government databases minutes after being fired

#146

Earlier quoted context omitted.

> When you are talking about access like they had "make firings as abrupt as possible including terminating all access immediately" not doing this is incompetence. You're proving my point—employers take the most extreme lesson and it's considered expected practice. They absolutely should have immediately terminated the credentials that granted unilateral access to sensitive databases. (Ideally those would never exist…

The first option is flipping one switch. The second option is flipping some switches now, and flipping the rest later. Of course the safest (first) option is the correct option from a liability standpoint, which is all a company should operate on since it's first responsibility is to protect the company for those that are still there. There's plenty of ways to communicate with ex-colleagues that don't involve company…

> Of course the safest (first) option is the correct option from a liability standpoint, which is all a company should operate on since it's first responsibility is to protect the company for those that are still there.

Isn't this an unrealistically black-and-white mode of thinking? Humans are complicated and have many values and perceived responsibilities. It's not healthy for them to throw them all out and act as if they only have one responsibility that needs to be maximally upheld at all costs. They should balance their actions thoughtfully.

Re: Twin brothers wipe 96 government databases minutes after being fired

#148

> At 4:58 pm, he wiped out a Department of Homeland Security database using the command “DROP DATABASE dhsproddb.” This article is hilarious. The two bickering brothers remind me of the guys in the Oceans movies played by Casey Affleck and Scott Caan. It’s amazing they got this close to sensitive data.

> At 4:59 pm, he asked an AI tool, “How do i clear system logs from SQL servers after deleting databases?” He later asked, “How do you clear all event and application logs from Microsoft windows server 2012?” So many red flags, I can't even.

> In the space of a single hour, Muneeb deleted around 96 databases with US government information. He downloaded 1,805 files belonging to the EEOC and stashed them on a USB drive, then grabbed federal tax information for at least 450 people.

Maybe whoever runs infosec at that place should also be fired?

Re: Twin brothers wipe 96 government databases minutes after being fired

#149

Earlier quoted context omitted.

There is a middleground, but it requires conscious effort to prop-up, support, and maintain over the long haul: off-boarding centers. I worked for a Big Tech company that actually did this, and it made the transition a lot easier. You could still access corporate resources necessary for the transition (HR, benefits, internal job postings, training offerings, expense reporting, etc), check-in with colleagues 1:1 (who…

Your last sentence sums it up. I was blown away by the system you described that would allow for such a humane transition through such a difficult time. At least process wise it seems like a good place to work.

It really was. I’d gladly go back, too, but they’re not hiring IT folks with my skills atm.

Re: Twin brothers wipe 96 government databases minutes after being fired

#150

Earlier quoted context omitted.

I love how this leaks out the fact that the DHS is running production databases on operating systems that are months away from end of extended support. Windows Server has 5 years of mainstream support, 5 years of extended support, and then an extra 3 years paid Extended Security Updates (ESU) support. For 2012 and 2012 R2 that ends in October 2026. The three years of ESU exists only for organisations like government…

It can be quite politically valuable to kick the can to the next administration.

The day-to-day operation of large government bureaucracies is surprisingly immune to elections. The same people stay in the same job for decades, the "churn" only happens at the highest levels, and even those positions tend to outlast changes in the current political party in charge.
Post reply on HN