Live data from Hacker News

The curious case of the Raspberry Pi in the network closet (2019)

blog.haschek.at

251–260 of 269 posts

Re: The curious case of the Raspberry Pi in the network closet (2019)

#251

Earlier quoted context omitted.

Obviously it's not a first step toward certificates, but it is a first step away from "anyone can casually plug in a hidden Pi."

Anyone who knows how to setup that RPi to do anything meaningful knows how to spoof mac

But would they be able to figure out a MAC to spoof without significant amounts of time in the data center/switch?

Re: The curious case of the Raspberry Pi in the network closet (2019)

#252
post #46

>And what do we do, when we want to find out a location associated with a wifi name? We go to wigle.net, enter the SSID (=wifi name) and it tells us where on the world it is found. I've always enjoyed having unique/personal SSIDs, but had never seriously considered this consequence. I wonder what the worlds generic SSIDs are.

This feels like something that's "security by obscurity" vs. "security by obscurity." Would you rather be obscure because you have the same SSID as everyone else so no one guesses which is yours or obscure because you have the same SSID as everyone else and no one knows which is yours, but it's easier to see what is going on inside the network?

One comes with more easily identifying you/your network while the other comes with being more easily hacked by readily available rainbow tables (I think, but am not sure, that WPA3 fixed this, but WPA1/WPA2 use the SSID as a salt for the password)

Re: The curious case of the Raspberry Pi in the network closet (2019)

#253
post #22

Earlier quoted context omitted.

Compute module has eMMC, and they haven’t been excessively costly because of it or reportedly unreliable in the way SDs are. But either way I suspect that the Foundation design team has some issues in designing power circuits rather than that SD cards being unfit or people are throwing in cheap ones.

Well, that was the issue with older Pis is that they were running powered by (micro) USB 2.0, which officially tops out at 2.5 W. While IIRC the 3rd Pi tended to top out at trying to draw 15 W - SIX TIMES MORE !!! No wonder that SD cards got destroyed in the process ! But AFAIK this shouldn't be an issue any more (assuming a non-counterfeit charger) with USB-C 3.0 (RPi 4+ ?) which starts at 15 W ?

I don’t know, but they did have brownout issues with 5.0V supplies, reluctance issues or something with official PoE HAT, and I’m not seeing PC-like multi phase MOSFET bridges on Pi to this day. It could be like there is some spike noises or something going into SD and killing it(emphasis on could be, it’s just my hunches).

Re: The curious case of the Raspberry Pi in the network closet (2019)

#254

Earlier quoted context omitted.

> Wow, imagine hating your boss so much you go to so much creative and illegal lengths (that can backfire against you) to track him, instead of using same skills legally to finding a better job. I once worked at a place where one of the founders would too often get the shits with someone or some team, and become a micro managing asshole for a few weeks. I wrote a python script to run on the wifi router to monitor for…

How did that founder feel about it? And what did the employees do with the information? Leave the building?

Not sure the micro managing founder ever found out people were using it to alert when he arrived. His asshole tendencies extended beyond micromanaging staff, and he ended up in a fight with the other two founders that resulted in him leaving the country with a warrant for his arrest of fraud charges within about a year.

People in his firing line would mostly use it to make sure that they were at their desk and had Jira open while waiting for something to compile, instead of HN or Reddit…

The managers-in-the-building website dashboard stayed running for at least several years after that, when I left, and it was still in regular use. People liked being able to do things like go “Hey, we’ve got the PM, Account Manager, and the CEO all in the office right now, let’s grab the tech lead security guys, and set up a 3 minute corridor meeting to make this decision.”

Re: The curious case of the Raspberry Pi in the network closet (2019)

#255

Earlier quoted context omitted.

We had a prod case where a server was being flooded with requests, and a downstream server kept falling over. We figured it was an attack of some sort and investigated, eventually traced it back to a computer inside our own network (we're a big computer, five floors of computers). It had an open file share, containing some Delphi books and from which we got the computer name too. So we walked over to the Delphi team'…

I'm surprised employees have sufficient access to prod to make this mistake.

They shouldn't have, a lot went wrong here.

Re: The curious case of the Raspberry Pi in the network closet (2019)

#256
post #93

Earlier quoted context omitted.

We had a prod case where a server was being flooded with requests, and a downstream server kept falling over. We figured it was an attack of some sort and investigated, eventually traced it back to a computer inside our own network (we're a big computer, five floors of computers). It had an open file share, containing some Delphi books and from which we got the computer name too. So we walked over to the Delphi team'…

Doesn't sound like a management failure to me. It sounds like there should be separate vlans for QA/test and Production to prevent this very thing (or potentially something more malicious like the spread of ransomware).

I'd say to say "Yeah, this was a long time ago"... but this could probably still happen.

Re: The curious case of the Raspberry Pi in the network closet (2019)

#257

Earlier quoted context omitted.

Seem pertinent to atleast get an affidavit from the ex-employee detailing what he as done, agree to hold on to the hardware as evidence, put liability on the employee for any time-bombs that might have been stored, ask him explicitly to give in writing all the activities he performed, etc. Just to have a thread to pull on, in the future, when something might go wrong.

We did get a hand written statement from him and the original evidence (hardware) is still untouched and locked away. In his statement he wrote that the pi logged to the SD card but there was no data on the SD card (well not on the data partition) and I'm pretty sure that was a lie and it just logged to Balena. But even though we could never decipher what the nodejs program actually did (because it was so heavily obf…

For what it's worth, I'm pretty sure it's quite likely there is a disproportionate number of people Out There™ that would be very happy to sign an NDA and have a look at the nodejs program for free.

You might even be able to find someone local. Maybe wander over to the next in-person security conference vaguely nearby?

Sadly you have no contact info in your profile so I can't even suggest to people seeing this to cold-email you.

(I objectively don't think I would be very successful myself, given that you've mentioned everyone in the office looked at it; I don't have a lot of relevant experience, which sounds reasonably necessary to be successful here.)

Re: The curious case of the Raspberry Pi in the network closet (2019)

#258
post #55

Earlier quoted context omitted.

An ex-employee who still had a key to the office so they could move some stuff they had there. Presumably that courtesy was immediately terminated and the key was returned.

Having a key to the office and having a key to the network closet are not the same thing. The article said only four people had access to the network closet. So did this guy break into the closet to plant the pi? I think he got off way to easy.

You'd have to ask the person who wrote the story. It's possible they said "a key" and meant "a set of keys" or something. Either way you're right the person who planted the RPi was quite lucky to get away with only a stern talking to.

Re: The curious case of the Raspberry Pi in the network closet (2019)

#259
post #225

Earlier quoted context omitted.

> If someone gets the client cert and key, they can probably fake the request to get the decryption password. Yes, that is a weakness, which is openly addressed in the FAQ: https://www.recompile.se/mandos/man/intro.8mandos#quick TLDR: It only works if an attacker is pretty quick about it. See also here: https://www.recompile.se/mandos/man/intro.8mandos#security > And what about the vector where someone attacks the CA…

> That’s a feature. A security system should fail closed. Of course, but there should at least be a mention of the fact that you need to tune the fail-closed parameters to take your availability into consideration. I appreciate that the various attacks would have to be done "pretty quick" according to the FAQ but the definition of "pretty quick" is necessarily countered by what kind of guarantees you can make about y…

The timeout can’t realistically be set very short, since it needs to allow for a normal reboot of a server. Servers are, in my experience, notoriously slow to reboot. Therefore, a typical network hiccup is assumed to be shorter than that. The default timeout value of 5 minutes reflects this.

Also, you could add the Mandos server status to your alerting system, and if anything goes wrong with your network and the Mandos server times out for a client, you can be alerted to this fact, so you can fix it before the next time that client happens to reboot.

> consider how you'd answer the FAQ "So I should set my timeouts super low for better security?"

Fair; the text could be clearer about this.

> I'm curious about what you mean by saying you aren't using "x509 keys" though.

Well, we aren’t using TLS with X.509 keys. We are using TLS with Raw Public Keys, as specified by RFC 7250 (https://www.rfc-editor.org/rfc/rfc7250.html) and supported by GnuTLS: https://www.gnutls.org/manual/gnutls.html#Raw-public_002dkey...

Re: The curious case of the Raspberry Pi in the network closet (2019)

#260

Was working with a NOC technician who was responsible (along with some others) for a pretty large EMEA mobile network, with many millions of subscribers. There was an RFP to update their SMS/MMS system and a certain Israeli company came in to do a site survey, or installation or something in the network data center. Anyway the long and the short of it was one of their technicians was caught with the previous vendor's…

PR makes it possible.

I have personally identified more than a handful of employees who'd use their work computers for... let's say "access to inappropriate content". All of them where invited by HR & legal and let go with a more then decent deal.

Absolutely everything was done to prevent the company being associated with anything nasty.

Post reply on HN