Ugh, unsecured Elasticsearch again. Yes, it's extremely annoying that the open source version doesn't come with any sort of authentication, but what kind of developer (or even a person who has...
Ugh, unsecured Elasticsearch again. Yes, it's extremely annoying that the open source version doesn't come with any sort of authentication, but what kind of developer (or even a person who has ever used a password before) looks at that and decides to leave it open to the world?
Either use a hosted version with authentication rolled in, or stick it behind Nginx with security set up there. The fact it's visible to anyone with the URL isn't exactly hard to miss, whether or not you have the expertise in-house to secure it. I'd also be worried about anything run in house if you can't set up a simple reverse proxy; there's no shame in using SaaS if that's your situation.
It's not a huge leak, but a fairly drastic one. Though VOIPO secured the data promptly on notification, it's possible the source was fully exposed for at least seven months, and the whole...
It's not a huge leak, but a fairly drastic one.
What was found:
Call logs (partial originating #, partial destination #, timestamp, duration of the call) going back to July 2017. 6.7M documents
SMS/MMS logs (timestamp and content of the message sent) going back to December 2015. 6M documents
Some of the logs contained references to internal hostnames. Some of the logs also included plaintext usernames and passwords for those systems. 1M documents
Some of the logs contained API key for internal systems. 1M documents
Though VOIPO secured the data promptly on notification, it's possible the source was fully exposed for at least seven months, and the whole production network might have been compromised.
It's not really surprising anymore when this happens, just another sad example of sloppy security (why would you ever log passwords and API keys in plaintext?). Also, don't ever use SMS for 2FA if you can avoid it.
Yes, that certainly seems to be the case; here's another one. More likely, it's just better awareness and wider use of available survey tools. Shodan simplifies broad searches for publicly exposed...
More likely, it's just better awareness and wider use of available survey tools. Shodan simplifies broad searches for publicly exposed sensitive data; it's hard to believe that state actors and crime networks wouldn't have similar tools for exploration and exploitation.
Ugh, unsecured Elasticsearch again. Yes, it's extremely annoying that the open source version doesn't come with any sort of authentication, but what kind of developer (or even a person who has ever used a password before) looks at that and decides to leave it open to the world?
Either use a hosted version with authentication rolled in, or stick it behind Nginx with security set up there. The fact it's visible to anyone with the URL isn't exactly hard to miss, whether or not you have the expertise in-house to secure it. I'd also be worried about anything run in house if you can't set up a simple reverse proxy; there's no shame in using SaaS if that's your situation.
It's not a huge leak, but a fairly drastic one.
Though VOIPO secured the data promptly on notification, it's possible the source was fully exposed for at least seven months, and the whole production network might have been compromised.
It's not really surprising anymore when this happens, just another sad example of sloppy security (why would you ever log passwords and API keys in plaintext?). Also, don't ever use SMS for 2FA if you can avoid it.
Is it the season for leaks or something? Coming right of the heels of the latest massive breach...
Yes, that certainly seems to be the case; here's another one.
More likely, it's just better awareness and wider use of available survey tools. Shodan simplifies broad searches for publicly exposed sensitive data; it's hard to believe that state actors and crime networks wouldn't have similar tools for exploration and exploitation.