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…
UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]
231–240 of 240 posts
Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]
#232Earlier 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).
Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]
#233Unsecured 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.…
Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]
#234VPN 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).
Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]
#235According 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
Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]
#236Unsecured 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.
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]
#237Unsecured 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.
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]
#238Earlier 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.
Re: UFO VPN claims zero-logs policy, leaks 20M user logs [resolved]
#239Earlier 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.
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]
#240During 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.