Hacker News Reader

Comment by duxup | Hacker News Reader

> Investigators say they were able to tie the downloads to Sharp and his work-issued laptop because his Internet connection briefly failed on several occasions while he was downloading the Ubiquiti data. Those outages were enough to prevent Sharp’s Surfshark VPN connection from functioning properly — thus exposing his Internet address as the source of the downloads.

Not the first time I’ve read about a VPN unable to mask someone’s ip when they were on a wonky connection.

View on HN

Proper opsec is you blackhole all traffic when the vpn isn’t active.

Personally I’d feel most comfortable with a separate hardware VPV solution that won’t let anything through leaving the local software to do its thing.

Is there a good reason for that to not be the default when using a VPN? At the very least it should be easy to configure. I remember when I tried using a VPN on Ubuntu a bunch of years ago, I had to set up iptables rules even though the VPN connection could be configured through the network manager GUI.

With wireguard since there is no "connection" to be maintained, you could argue this is a non-issue.

But Wireguard itself relies on an active internet connection, which needs to still be set up to not fall back on in case the wg connection deactivates.

> With wireguard since there is no "connection" to be maintained

What does that even mean?

Let's say you have a Wireguard configuration, wg0 which runs off ens0. If your wg0 connection dies, for whatever reason (let's say the remote server goes down), your computer falls back to ens0.

What does "not having a connection to be maintained" change about this?

GP's just taking issue with the word 'connection', it's fine, I think it's clear.

It’s really not. If you have a route down your WireGuard interface, it’s not going to stop should the end point of that interface no longer be routable.

Wireguard will keep contacting the remote server. You'd have to delete the wg0 interface or delete the default route for packets to go out via ens0. Wireguard only has "connection" in a sense that it caches some runtime information about the peer's endpoint, but endpoint configuration is static.

I guess, too much magic automation on top of this is not the best thing for opsec, including having some daemon that can disable your wireguard interface or reconfigure the network if it doesn't like something. You want your network configuration to be static and predictable, regardless of some temporary failures. Basic wireguard kernel primitives will give you that.

> You'd have to delete the wg0 interface or delete the default route for packets to go out via ens0

So... You'd have to do work to properly blackhole traffic when wg0 goes down. However long it takes to reconnect, you still will automatically fall back down to ens0 while it's down unless you do something to stop that.

How does wg0 go down?

wg0 doesn't go down by itself.

Packets are always delivered to wg interface as long as it is marked as 'UP' (or 'enabled', if 'UP' sounds to you like having anything to do with some kind of "connection") when your routing table directs them there.

When they hit the wg interface when the other endpoint is unreachable for whatever reason, they are either dropped, or queued, or get ICMP unreachable response generated for them, depending on situation. This is done internally by wireguard.

You have a route to stop that. You route 0.0.0.0/0 through wg0 and it doesn't matter if no traffic returns, it'll keep trying because that's the route that's been defined for wg0.

If you wanted to not go through wg0 (whether it can reach the other wireguard peer or not) you'd have to remove the routes first.

A good (the best?) way to solve that is 'the new namespace solution' described at the bottom of the page here:

https://www.wireguard.com/netns/

In brief, you move your physical eth/wlan device to a new namespace, and create the wg device in that namespace but then move it to the init ns.

By default (and without root) everything will use the init ns and only be able to reach the physical device via wg. If it's not active, nothing will even reach your NIC, nevermind the internet.

+1 to this being the safest way. No physical nic for your traffic to fallback to. The downside is this isn’t supported by any GUIs that I know of so it’s a pretty miserable workflow for WiFi.

I prefer to have separate VPN'd network that never routed to other connection.

We have to admit the guy is consistent, at the least. He drove employer's security to ruins on purpose, and did the same to himself.

I can't believe someone can literally destroy its life for BTC. Imagine his family and close friends. His parents probably thought he was a tech wizard genius. And now he destroyed his reputation, his employer's, and he'll be behind bars for quite a few years. I hope he doesn't have kids.

And picture: he could have been the guy who did a great job "fixing" employer's lack of security. Have that on his resume, tell lessons learned on real world practice.

Why the hell would he even think about the FBI route in the first place?

> And picture: he could have been the guy who did a great job "fixing" employer's lack of security

This is not really a thing. It's very hard to get recognition or even a shared understanding of the risk mitigation. As everything else in the world, it's way easier to reward someone for things that happen (new functionality) than rewarding someone for preventing things happening (hack).

I completely disagree. You may not get recognition with the people at the front desk, but you absolutely can get recognition from your peers inside a company and (as valuable?) people outside the company. Some of this has to be the result of your own work and marketing - conferences, getting clearance to talk about the work you've done (which is good marketing for the company if sold correctly), speaking engagements, etc. If you think the recognition just comes as automatic as wages, then you're doing it wrong, but are correct in that no much will be forthcoming.

Classic example of the Do Stuff / Tell People You Did Stuff balance. This stuff is arcane and invisible by default. The coordination and communication tasks that surround the direct work are important.

One was to strike a good balance here is a security roadmap. Write down the adverse outcomes that would be a problem for your business. Write down the possible mitigations, how much they cost to implement and how strong they are. Propose a plan that continuously improves security in a cost effective way. Highlight significant things you can’t defend against yet, and explain how you could address them sooner with more funding. Show the plan to leadership, get it approved, and get to work. Every month / quarter / sprint, write down what you did, show where you are the roadmap, and adjust the roadmap to reflect any changes in business priorities.

Presumably this is an OS-level thing, that it helpfully tries to fall back? If so, I suppose it could be mitigated either by a software control that prevents using the bare connection, or by running the VPN elsewhere, for example on your router.

(I see posts elsewhere in the thread now describing how to do this with iptables.)

what I heard some naugthy people say is that one way to deal with these kind of issues is to have two virtual machines, one that connects to the vpn and a second one (without host networking) that can only access internet through the first one.

the firewall on the gateway vpc has to be on drop by default and only forward traffic from the 2nd vpc to the vpn interface.

the gateway vpc should NEVER provide DHCP or DNS to the second vpc since this is the easiest way to shoot your foot off since a single dns request may give your identity away.

that or use qubes os.

Even if you did that, if I have oversight of the network in a country, like a 5+ eyes level of oversight and you were in a 5+ eyes country, I'd still be able to see where you are and what you would be doing.

Road & Rail networks have a lot in common with digital networks, when you think about it.

Personally I'd have a machine in a foreign country and used that either via an app or friend in front of the machine to do the download(s) with a time delay to avoid obvious links and then sneak it back across the border in bits.

Insecure home networks can be useful, and there is no limit to the number of times and algo's that can be used to encrypt files Russian Doll style.

Foreign country's which do not data share or extradite have their uses, but media like news orgs, Youtube and others can be helpful for establishing what hackers have been extradited. Assume all country's have hackers attacking the US or some other country and then look for missing news stories, YT videos and that sort of thing.

Then look into what relations are like between the two country's and go from there.

If you do your research or homework there shouldnt be any risks.

I dont think the hackers behind this have ever been caught. https://www.bbc.co.uk/iplayer/episode/m0010s10/the-trick

https://web.archive.org/web/20120719071718/http://www.norfol...

i use policy routing and let wireguard mark packets it wants to send out. the main table is empty (there is no route... at all..) external connections insert routes into their own tables. the wireguard interface does this too and any packet not marked by wireguard will use this routing table... if wireguard is missing nothing marks packets to leave at external interfaces. i have an additional rule that prohibits any traffic that did not have a route in any table applicable at the end of the policy rules

Most come with a killswitch, so if it wonks out you can't access the net.

Are killswitches actually fast enough? Serious question, I don’t know much/anything about networking internals.

I never trust killswitches and when I want to ensure I don’t leak anything, I bind to the VPN interface instead, but I don’t know if that actually gives better security?

Speed should not be a problem and hardware solution should not have to be a better solution, ideally. Shame that has to be brought up still.

I've never used surfshark myself but they advertise as having a killswitch inlcluded in their VPN [0] so it sounds like in this case, it definitely failed.

[0] https://surfshark.com/vpn#vpn-page-essentials

Just setup your routes/firewall so that the only possible way traffic can leave your machine is via the VPN device. VPN dies? no traffic going anywhere. Pretty much networking 101 stuff.

That should be the same when bound to an interface, shouldn’t it?

Kill-switches are a misnomer. What you really want is a firewall external from your "target" system that blackholes all traffic not to the VPN gateways IP address. Than make sure packets traveling the parent interface are ONLY VPN traffic or nothing in case of the tunnel dropping (wireshark is good here.)

That sounds like a race condition that gives you a false sense of security. It only takes one leaked packet…

VPNs are not intended to mask illegal behavior. The assumption is no one will care enough to try to get the real IP. So blatantly breaking the law throws that out the window.

Yeah and I don’t trust that a vpn would really care for my $5 a month or whatever when faced with state actions that if it came to that.

At least one VPN provider did just that

https://torrentfreak.com/private-internet-access-no-logging-...

This was before they got a new owner.

Saying “ I don’t have a log” to me isn’t the same scenario I’m thinking of.

I’m thinking after the fact, if the government asked them to log future events.

Or he didn't screw it up and that's the FBI's standard excuse.

My first thought. They could have used some undisclosed (illegal) tools and methods to find him, and then cooked up this story to explain it.

I'm skeptical. Maybe the FBI did use some illegal tool or more likely, a legal tool that they control the backoffice for, but the story I read outlined some pretty common blunders. This makes all the more sense if he was a mono-technical web app guy for most of his career.

If he did pay with paypal, that was his first mistake. Theoretically, you pay for your VPN with a gift card you bought with cash, maybe even one you got in another state and use anonymous email receiver to get your keys. Rotate accounts as project phases are completed.

Theoretically, use a purpose-built machine to keep fingerprints out of the mix, and as others have said, a killswitch using iptables/UFW to only allow traffic through the VPN gateway. Probably wouldn't have hurt to rotated the VPN egress points as well.

Theoretically, he should have been connecting this VPN over a public hotspot not his home network. I get that this wouldn't be conducive to downloading gigs and gigs of data, but if you're the one setting it up and monitoring/junking any logging on the other side, you could also afford to do this with an SBC (or several, again bought with cash) concealed at some location(s) that just pulls the information by slow drip over public connection via VPN. SBCs get tossed into Willamette as they're rotated.

The FBI cyber guys are good and creative but with a reactive situation like this I think old-fashioned gumshoeing, interviews and subpoenas would get them a long, long way. Once they had an inkling that it was an inside job, man, just relentlessly picking away at that with some face time would be really productive. Guaranteed that guy wasn't prepared for the bright light of honest incidental questioning, over and over, much less focused questioning. Not to mention, they are free to lie to your face in those interviews about what they do/don't know. Once they had a list of four people, start shoving out the subpoenas and see what clicks.

Part of their toolbox is also having an idea of what real attacks look like, knowing what those actors care about leaving behind or not concealing, and in the absence of those earmarks, they know they're looking at something "unusual". Now if I start telling you that I did find evidence of an attack of type Y where there absolutely is none, and you're all too eager to help me prove that theory, that's probably a bad sign. Did he have a plan of his own in place to frame some other ransom toolkit or plant seeds of a breach? I mean, what would you think if you walked into a company that got hit with a massive ransom demand, evidence of data theft, but no typical signs of a data breach from the usual suspects? State actor? Now this is serious. Was it their Exchange or RDP server in the closet? Oh, you're cloud-only? What platforms are we talking about? A state actor has zero-days into a major cloud platform?? MS? AWS? Now this is really serious. Or... maybe none of that is the case. Log files are all missing? Who made that decision? I mean, on and on it goes, but it seems pretty easy to see it unravelling once you start pulling on a thread.

If one was really interested, they could probably find some good information in PACER about the information that supported the indictment. Chances are he's already confessed and is attempting to plead out. They'll surely throw the book at him. Insider ransom jobs on US hardware companies are not a tolerable phenomenon.

pfsense does that by default. If the VPN connection is deemed to be down (it does some pinging to evaluate it) it silently defaults to unencrypted.

There is a convoluted way to configure it so that it blocks VPN IP packets from going directly to the WAN, but I noticed it seems to terminate connections when some packet is lost.

Wonder if tor browser would've been a better choice

This doesn't sound too good for VPN users

It's an operating system issue. OS's are really difficult to give absolute invariants that you can trust. If network connectivity security is vital, then the only real solution is to setup your environment in a VPN or on a separate box that will lose the adapter routing info if it goes down.

There’s a huge gap in operational security for a hack of this size.

At minimum, use a burner IP address and hardware from Craigslist.

it sounds like a misconfigured VPN to me, like he didn’t have the interface set to block traffic on failure.

if a security tool lets the user shoot themselves on the foot it's a problem of the security tool not of the user.

I’d be willing to bet that for most of the VPNs that are getting advertised by YouTubers (NordVPN, SurfShark, ExpressVPN, PIA, et al) it’s 100% marketing and they don’t actually care whether their “kill switch” works 100% of the time.

After all, they are not as trivial to implement as it sounds.

Something I don't understand is that he executed it fairly well... With the exception of using a weak, evidently broken, vpn instead of something like mullvad + tor. If you are going to do something like that (which is already a big "why???"), why put such little effort into your own security?

The suspect allegedly stole gigabytes of data, need bandwidth for that.

Last time I tried to use tor, I was getting like 32 kbit/sec, on top of a symmetric 100 mbit/second internet connection.

That was many years ago but I doubt they fixed the speed, very hard to do without centralized servers.

To be clear, at least ExpressVPN has a "prevent traffic going through outside the VPN" mode which would handle this case, and it's on by default.

I am not sure how it's implemented, but it's pretty easy to imagine someone deciding to not use it cuz "it's slow/annoying" or whatever.

That option isn't enough, it works only when the VPN connection is up. If your internet connection is flaky and lose connectivity to the VPN itself, your OS will revert to using its default gateway, and your home IP, which is how the guy got caught.

You need your firewall to block any internet access when the VPN is down.

I have something like that set up in a Docker container for my torrenting VPN system, so I never connect with my residential IP.

That's incorrect. If you lose access to the ExpressVPN VPN connection then (while the VPN software is active) you _completely lose access to the internet_, until you disable a switch in the software. You get network errors and the like. at least with the ExpressVPN tool.

This is a proprietary application, not just using the OS-integrated VPN software. Given your comment, I imagine it sets up firewalls.

I don't use ExpressVPN and apparently the guy with Surfshark thought his VPN functioned like this but it didn't. When in doubt, write the firewall rules yourself, especially if you're going criminal.

Reply on news.ycombinator.com