Hackers shoveled snow for company, were rewarded with network admin access | Hacker News Reader

Hackers shoveled snow for company, were rewarded with network admin access

theregister.com

93 pointsike_usawa79 comments

”Finally, the company should have enforced a strong password policy that would have prevented our heroes from finding dozens of accounts with “winter2023!” as the password.”

Capitalize that “w”, and you’ve got a password that will pass most PWD policies. Why do they think it was “winter2023!” to begin with? In 90 days when the PWD expires, well, it will be spring of the next year, so…

The better idea is to require passwords with some real entropy, and get rid of expiring passwords. It’s not 1999 anymore.

1. Open a web browser and do a search

2. Read until you find a sentence that you like.

3. Use it as your password

I like the last line of your comment

My password is now password

Hacked

Should have been "use it as your password"

That's cool. Yours comes up as stars (*). Must be a HN thing.

hunter2

doesnt look like stars to me

"That's the best password ever!"

Now you might want to open a pr like this one: https://github.com/danielmiessler/SecLists/pull/155

Not enough numbers or special characters usually.

I loathe two things in password requirements: special characters and not allowing spaces. C'mon, it's 2026. Require 20 characters and call it a day.

"password is to long, max length..."

(╯°□°）╯︵ ┻━┻

I couldn't decide which sentence of Alice in Wonderland was my favorite, so I just used the full text.

Alibaba Cloud in 2026 lol

Use one specific special character/number as word separator.

How about mixing up band names? Take the end of "Florence and the machine" and mix it with the start of "Rage against the machine" and you now have the totally unguessable "Rage sharing the machine". It's a different machine see?! Nobody would know that!

The The but the first The is from The Who

That's crazy! Imagine what The The and The Who would sound like? Not The The and The Who, but the The The and the The Who your comment alludes to. Or would the original ones be called The The The and The The Who?

I swear if the ghouls running things had abit more decency and allowed people to actually access and controll their passkeys then that would be the future, everyone would adopt it. The experience is so nice with key pair exchange for ssh. Its just that there i have thr security of knowing exactly where my secret is and how i can manage it, its just a file and i can move it like a file

Nobody wants the risk of getting locked out because of apple and googles walled garden bullshit

Letting users pick their own passwords has always been a mistake. If passwords are needed, the system should choose them.

just directly give them a post-it for their monitor

As a person with memory issues, this is a recipe for me writing a password down where somebody else can probably find it.

but post-its are vulnerable to the wrench attack!

If your machine or service is connected to the Internet, 631U)VN0Onl? written on a post-it note is generally going to be better than hunter2 not written down.

Expiring passwords are one of my biggest gripes, and I still see them everywhere

Expiring passwords and length limits. Why can't my password be a 5KB long? My password manager has no limits. Are people storing them in plain text in 2026?

I wouldn’t trust enterprise internet security boxes to not trip on such long text fields.

And content limits. Why can't my password contain the % character? No special characters? What makes a character "special"? Why can't it contain emoji? So many password systems go to great lengths to remove potential entropy and randomness from passwords with their rules. The usual excuse is "blah blah blah legacy systems" which is not a good reason.

Personally, I wouldn't use anything beyond ASCII in a password. I don't want encoding bugs to lock me out of my encrypted partition or bank account, thank you very much.

Probably because there is some mildly decent reason (or very good, I don't know) to avoid them and it really doesn't matter enough to worry about getting around it.

Why would you want emojis in your password? It's a piece of text not meant to be seen, emojis are meant to be seen. Just randomly generate some characters and get on with your life. I don't understand why you care about this at all, it's such a pointless thing to complain about.

To me it signals bad engineering in the underlying system which doesn’t exactly encourage trusting the system with my data.

I think simplicity is good engineering. Bending over backwards to support pointless usecases isn't good engineering. Almost nobody would use this and the ones who would don't need to. Why put in the effort?

I agree, content limits are a royal PITA. Do you know how long I had to search to find a password manager that would accept my password with its doodles, sign language, and squirrel noises?

I ran into a website for work that would let you create a long password, but silently truncate it to 12 characters before saving. Mind boggling.

This is the best. Especially when the password is being autotyped by the pw manager and so you never see the truncation and now have a bad pw saved in your manager. Alongside a restrictive password policy with no ui explaining what the policy is.

This happens on some HP printers too, the web interface lets you happily enter lengthy passwords, but doesn't bother telling you it truncated the entry at 16 or 12 characters.

Blizzard/battle.net used to do this (still does?), lol

I unfortunately had the infuriating experience dealing with a (government, of course) site that did this. To add to the experience, not only did it silently truncate at registration, but it did NOT truncate on the login fields. And of course, it has a lockout after several failed attempts. UX gore at it's finest.

Happened to me a few times. And then your password never works and you can’t understand why.

> Why can't my password be a 5KB long?

Probably because that's just unnecessary. A few dozen characters is plenty, anything beyond that is just excessive.

> Why can't my password be a 5KB long?

You should switch to Windows, Microsoft got you covered[1].

[1]: https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Arch...

Never seen that bug before, thats a dozy!

Unbounded length anything is a denial of service vector, even if they do hash. I can assure you that even if your password manager doesn't impose limits, you can most certainly hit some if you try hard enough. It is also completely pointless. Two dozen or so ASCII letters and numerals will let you encode all the entropy you could possibly want.

Expiration is self-evident. Long lived tokens you can just whip around will whip around. The number one group of people who are hurt by expiration are those not using a password manager anyways. Autogenerated and autofilled passwords can expire all they want, it's a non-issue.

Special characters are dumb and unnecessary. They also pose a fun challenge when you happen to run into a situation where you can't input them anymore all of a sudden.

People cannot participate in cryptographic schemes, only machines can. These gimmicks do not help fix that. It's "theatre", as they say.

Good security policies should have an upper bound on password length, but also those upper bounds should maybe be like 100 characters or so. There's a couple reasons for this. First being is that hashing does take some compute resources, second being that there is some security/usability tradeoffs here, etc, and third being that after like 30 characters or so, the effective (key phrase here) security gains become marginal.

> Why can't my password be a 5KB long

Because that opens you up to an entirely new class of attack. You have to set the limit somewhere and if you set it at INT_MAX, then a malicious user could find a O(n^2) path in your password validator and input a 4GB password that locks up the machine. Or they could create 1000 users in a row with 4GB passwords and fill up your storage.

> Or they could create 1000 users in a row with 4GB passwords and fill up your storage.

Not an issue if you’re storing passwords properly. You don’t store the actual password, you store a (hopefully) salted hash of it.

My company does it to our phone passcodes. 90 days.

Well, I’ve only got 10 fingers, so looks like my time there would be limited to 900 days.

Due to corporate IT working its fingers into everything vaguely computer related, I now have to annually change the passwords that operators use to log onto the HMIs on my OT network (which has no connection to the greater Internet.)

That means I now get calls after hours for a couple weeks (allowing for all shifts to cycle through) from operators who are locked out of their ops stations. I can't send the password via email, obviously, and word-of-mouth is inconsistent at best. So I'm left with the sticky note under the keyboard or stuck to the monitor, which the operators won't read anyway.

One good thing about expiring passwords is that it forces you to use something that you probably don't use for everything else in your personal life.

I worked some (terrible) place that did that and wouldn’t allow you to use your last 3 passwords. So what we were doing is that when it was time to rotate password, we would change our password 3 times in a row and on the fourth time we would just use the same password as before. This way our password never changed (the requirements for passwords were ridiculous) and the box could be checked in the audit.

Also the same company: we ran a version of our artifact repository that had a 10.0 CVE for almost a year. It was too much work to update it, couldn’t spare the resources.

Replying to my own post: wait a minute, why are there so many accounts with the same password in the first place? Oh, because "dozens" of people are tired of changing their password every 90 days, and someone piped up on an email thread (with the subject line: "Changing passwords all the time is bullshit!", I'm sure) and said, "I just set it to $SEASON$YEAR'!'. Easy to remember, fits the policy."

And now you have a system that is far less secure than if you just ditched the expiration policy to begin with.

Being overly suspicious of everyone is a terrible way to live. Maintenance should have the autonomy to do as they did here - and security correctly followed up. The right response should only be technical imo. A meeting room should not lead to this level of network access.

> Maintenance should have the autonomy to do as they did

Really? We're talking about letting strangers in through the literal back door.

A better approach is to train everyone to be polite and helpfully walk the person to reception, who can arrange access.

Yeah, true.

Agreed! As a friendly favor, could you please post your full name, ZIP code, credit card number, and the 3 digit security code on the back?

- Love and peace, your neighbor on HackerNews

(which is to say, I think you know that you can be friendly without being foolish - but if not I'm going to really enjoy the gift of that credit card :))

Maintenance employees are the weakest link. They aren't paid much and don't believe anything is important.

Be nice to them and they'll be nice to you back.

Since they came in through an open door, a fake badge that passed quick casual visual examination would have seemed potentially helpful here. I'm surprised the pen testers didn't craft such badges. Perhaps it was difficult to get a sufficiently high res image of a real badge from an employee entering or leaving the facility (although, if the front desk is manned, it might be possible to walk up to the desk with an innocuous question and snap a pic of the receptionist's badge if it's visible)?

I've never worked anywhere that stressed keeping your badge concealed until the moment of entry and concealing it upon last "scan" point on exit. If followed, such a policy would slightly reduce the risk of fake, but visually adequate, badges -- but compliance with such a policy would probably be very low in most commercial situations.

The company also should have restricted network access to the port in the conference room so that an unknown device like a Raspberry Pi could not make an Ethernet connection from that spot

Bad take - the actual problem is that there was a trusted network in the first place. This kind of network access control is trivial to bypass, and trusted devices can get compromised.

It's not my field, but at least at my work the network can somehow tell the difference between an authorized user and not. It is not simply using the MAC address.

A guest device connected to the ethernet port in the conference room has the same access as a device connected to the guest wifi, a staff laptop has it's usual access.

Probably a RADIUS server setup.

Basically staff machines get a certificate to present to the server and the server controls the network.

So, if your machine does nothing, it's on the guest vlan and has limited access. If it presents a valid certificate that network port is reassigned to the staff vlan and you get full access.

If someone leaves, you just revoke the certificate and they have guest access again.

Not rocket science once you know it :)

Still better to do that same thing (cert based auth) at the application layer instead of the network layer.

Yes, you can do it by MAC address instead but that can be changed so you can spoof a legitimate device.

Edit: oh wait, you mean have the applications check the certificate? Yes, but then you need support from the application. Does your printer do that, for example? You need to make sure everything does. You can of course do both.

Reverse proxy

That's great when you have control of your applications. For most corporate IT you're stuck with COTS applications and whatever their built-in auth functionality is. Sure, you can probably bolt a reverse proxy in front (if you're lucky enough for it to be a web app and not a thick native code client) but you get to argue with the vendor when they refuse support because you're not using their recommended configuration.

802.1x certificate-based authentication at layer 2 is a good defense in depth strategy.

Use envoy or some other reverse proxy and do per-app auth there

Even if you can't authenticate at the application level, it's still much better to encrypt/authenticate traffic on the wire (using a VPN or something like Tailscale) instead of 802.1x auth.

How is an overlay network "much better" (or meaningfully different) than a device-based certificate and 802.1x when the user is accessing an application delivered over HTTPS using a publicly-verifiable certificate authenticating via SAML w/ MFA (Entra ID)? The source subnet attests successful device authentication in the 802.1x example but that's irrelevant beyond, perhaps, a firewall granting access for the device to terminate a TCP connection to the server's TCP port 443. That's no different than the request coming to the server from an authenticated overlay network, to my eye.

I guess if you want to tie the network layer authentication to the user make it 802.1x with a user certificate. Either way you know the request is coming from authenticated endpoint and the user still authenticates to the application independent of the network layer. In all cases HTTPS protects the traffic from MiTM end-to-end.

Probably 802.1x, but it's easy to bypass if you have access to an authorized device. This kind of authentication has to be done at the application level, treating the network as a perimeter doesn't work.

> There are a lot of lessons here, but they start with training every member of the team to be suspicious of people coming from the outside, without badges, no matter what they say or do. Schloss noted that, if someone looks and acts like they belong in a space, most people will treat them that way.

> “First and foremost, what most people believe is crime is not crime. It's a Hollywood myth of what crime looks like,” Schloss told us. “I call it the ski mask bias. Everyone assumes you're not getting robbed until a person comes in with a ski mask and a gun yelling.”

I call this "Trained By Hollywood Syndrome". It's a huge problem, and far beyond mere computer security.

This made my day for the third time today for every time I checked the homepage.

What always gets me about these red team attacks is the same thing that gets me about internal phishing test emails.

My company sent an internal phishing test last week. Several people immediately reported it to a cybersecurity engineer, posted about it in Slack, saying they were surprised that such a sophisticated phishing attack was happening.

I too was surprised - Google is usually much better about catching these kinds of things in the GMail filter before they get through. Oh well, sometimes one slips though. Reported it and moved on

Come to learn that the only reason it made it through is because we let it through _on purpose_.

By analogy to these red team attacks: _theoretically_ someone could rent a car, pose as an employee, and set up a Raspberry Pi in the network.

But who would go to all that trouble?

Theoretically, someone could craft a perfect phishing attack, but who would go to all that trouble? Spray-and-pray, low precision, high surface area, attacks are the ones I end up reading about.

The only reason this attack vector was open is because the red team stood to gain a massive benefit from succeeding in the attack. What real-world actor would go to the trouble and stand to benefit as much?

Imaginary country called Nicha can’t buy lithography machine from imaginary company called SAML. Nicha can kidnap some scientists and torture them to get all the secrets. But it’s not elegant. Nicha can pay a lot for hacking and get the result in anonymous way. I guess 8 figures can be paid easily for these secrets. With that money “red team” can launch very nice multifaceted social hacking attack.

> But who would go to all that trouble?

I mean, a company I worked at had a significant amount of money stolen after the attackers spent 6 months sitting on their access waiting for the right moment to fake an (expected) reply to an email exchange. The original breach (or at least the breach of this executives account) involved a very targeted phish. When the potential payout is millions it justifies a lot of effort.

I remember at some point Google disallowed more phishing attacks from red teams. Nothing new was being learned. They always work.

Google solved credential phishing a long time ago using hardware tokens (gnubby - the predecessor to FIDO/U2F/Passkeys...).

There's other types of social engineering, but phishing is mostly an engineering issue.

> Theoretically, someone could craft a perfect phishing attack, but who would go to all that trouble? Spray-and-pray, low precision, high surface area, attacks are the ones I end up reading about.

I've been at a company that was well targetted. I forget which group it was, but they were got into a lot of customer service sites that week; not ours, but we had some near misses. Almost got me, sent me an email from the boss with 'The blog is down' and a link ... I was checking my mail on mobile as I was out the door, but of course mobile doesn't show any useful headers like from address.

"Theoretical" becomes "pretty much guaranteed" if standards sink low enough - the more effort you put in, the more problems you ward off.

Sort of like how a lock can be picked in 30 seconds, but still deters 90% of crime - a lot of criminals are just searching around to find out who is vulnerable, and most every company has something that's worth at least a bit (even if it's just stealing $500 laptops instead of breaching the network)

Reply on news.ycombinator.com