Live data from Hacker News

UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]

comparitech.com

231–240 of 240 posts

Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]

#231

Unsecured Elasticsearch, once again. ( https://www.theregister.com/2020/07/17/ufo_vpn_database/ ) So ES has insecure defaults, I get that and it's been discussed to death. But who the heck, in this day and age, exposes clusters directly to internet traffic? I don't care what the defaults or security measures you have. DONT EXPOSE SERVERS. Place them inside a VPC, preferably a private one(in AWS parlance, behind a NAT…

I am astonished that ES still does not recognize that there should be at least minimal protection against exposure by default. I mean, it's not super hard to generate good password on install, and if it's not necessary, it can always be manually disabled, but it is astonishing that "let's somebody else worry about security" is still a thing...

Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]

#232

Earlier quoted context omitted.

Do you expect the call to continue, or to drop, when you lock the phone mid-call?

They should definitely have to ask the permission to be able to run the microphone or camera in the background, specially in Firefox (as opposed to native apps).

They already asked permission, and you're still on the call.

Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]

#233

Unsecured Elasticsearch, once again. ( https://www.theregister.com/2020/07/17/ufo_vpn_database/ ) So ES has insecure defaults, I get that and it's been discussed to death. But who the heck, in this day and age, exposes clusters directly to internet traffic? I don't care what the defaults or security measures you have. DONT EXPOSE SERVERS. Place them inside a VPC, preferably a private one(in AWS parlance, behind a NAT…

AWS Elasticsearch was one of the last services which didn't support VPC until late 2017 [1], moreover if you had created a cluster without VPC support the migration is very cumbersome and application changes (to enable double writes) are required to execute it without any downtime [2]. [1] https://aws.amazon.com/blogs/aws/amazon-elasticsearch-servic... [2] https://medium.com/@vishnunarang/how-to-migrate-elasticsearc.…

And if you want to use it with Cognito (to get user auth for Kibana), you NEED to have a public elasticsearch instance...

Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]

#234

VPN providers are something you should have especially high standards for. They are largely unregulated, can see all of your meta data and have an economical incentive to sell it (IIRC some big player has been caught doing that). If a provider shows even the slightest amount of fishiness, instantly discard them (NordVPN immediately comes to mind, with their weird influencer marketing campaign).

It is definitely tough to choose, I don't know if you should discard nord vpn so quickly, recently they've been doing 3-rd party audits that proved they don't keep logs. That has to count for something right?

Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]

#235
post #165

According to The Register, UFO VPN is just white-labeleing a parent service[1]. The full list of compromised providers is thus UFO VPN, FAST VPN, Free VPN, Super VPN, Flash VPN, Secure VPN, and Rabbit VPN. [1] https://www.theregister.com/2020/07/17/ufo_vpn_database/

Never buy a VPN with these kinda names. You can tell they are shady from their names and websites. UFO, Secure, Pure VPN, etc

So you would also reject VPN from Purism company?

Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]

#236

Unsecured Elasticsearch, once again. ( https://www.theregister.com/2020/07/17/ufo_vpn_database/ ) So ES has insecure defaults, I get that and it's been discussed to death. But who the heck, in this day and age, exposes clusters directly to internet traffic? I don't care what the defaults or security measures you have. DONT EXPOSE SERVERS. Place them inside a VPC, preferably a private one(in AWS parlance, behind a NAT…

Also, don't use 0.0.0.0/0 in a security group rule! P.S. Azure has load balancers and security groups too- in fact their security groups are better than AWS's in some ways such as supporting thousands of rules instead of only 50.

They do, but once you setup a load balancer, it wants to send all traffic through the load balancer.

AWS and GCP load balancers are more like an endpoint. Your network is otherwise unaffected.

Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]

#237

Unsecured Elasticsearch, once again. ( https://www.theregister.com/2020/07/17/ufo_vpn_database/ ) So ES has insecure defaults, I get that and it's been discussed to death. But who the heck, in this day and age, exposes clusters directly to internet traffic? I don't care what the defaults or security measures you have. DONT EXPOSE SERVERS. Place them inside a VPC, preferably a private one(in AWS parlance, behind a NAT…

I'm not sure if that's better. You're just introducing more complexity in to your network.. If you don't have the budget for a nat/load balancer or want to just keep it simple, a simple iptables rule would do! Then test with nmap regularly to see if it's correct.

> If you don't have the budget for a nat/load balancer

It's not such a big budget in any of the big cloud providers.

And my point is: if you don't need access, you won't even have such load balancer. Unless someone goes out of their way to provide access to your server, no external access will exist.

Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]

#238

Earlier quoted context omitted.

So the company is run by people who enjoy privacy? It seems weird to frame that alone as an argument against a company which deals in Virtual PRIVATE Networks.

I thought this would be common sense but I guess not. It should be a red flag to you that if a founder or executive won’t reveal his identity, there is a possibility those people represent a nation state or other organization (not necessarily governmental) that you would not give your private data to if you knew their identity up-front.

I suppose you have a point. There are plenty of reputable people out there building strong identities on pseudonyms. But if you’re trying to be truly anonymous, as opposed to pseudononymous, and aren’t tying that identity to anything outside of the one enterprise, that could mean you’re putting less on the line with your reputation. Or it could mean that this is just you starting to build an identity, since everyone has to start somewhere. But either case has the same characteristics common with burner identities, so you’d be justified in being skeptical and cautious.

Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]

#239
post #195

Earlier quoted context omitted.

But it still builds trust in the brand. No one is safe from a state actor.

Trying to gain trust against something you have no control over is the very definition of security theatre.

Um, no.

I'm saying that staff can be observed as behaving correctly, professionally, and more. This would build trust in the brand from multiple perspective, not just security.

There are been a few cases in which this has turned around public opinion re: trust.

Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]

#240
Hello, I’m a tech executive at UFO VPN, and I want to begin by apologizing for the incident that occurred in 2020.

During that period, we failed our users. The data exposure was real. It resulted from allowing a third-party SDK to emit runtime logs, combined with a misconfigured server-side logging system that was accessible without authentication. That architecture should never have existed, and the criticism we received at the time was entirely justified.

I deeply regret that we put users in that position. I also understand that no explanation can undo the harm that was done. Still, once the severity of the issue was fully understood, it became critical to make fundamental changes and to be clear about what those changes were.

All client-side and server-side connection logging was disabled, including debug and development logs.

Sensitive fields were removed at the data-structure level so they cannot be recorded, even unintentionally.

The logging pipeline was rebuilt to require authentication, with strict least-privilege access controls and encryption applied both in transit and at rest.

Additional safeguards were added to the CI/CD pipeline so that any attempt to reintroduce connection-related logging is automatically blocked.

Today, user connection data cannot be accessed through internal APIs for a simple reason: it is no longer collected. This does not make past mistakes acceptable, but it reflects the seriousness with which this failure has been treated.

I am sharing this solely to take responsibility and to be transparent about what was learned. I am also willing to answer technical questions or listen to any concerns.

Post reply on HN