Researchers Find Over 6,000 Compromised Redis Installations (riskbasedsecurity.com) 30
An anonymous Slashdot reader writes:
Security researchers have discovered over 6,000 compromised installations of Redis, the open source in-memory data structure server, among the tens of thousands of Redis servers indexed by Shodan. "By default, Redis has no authentication or security mechanism enabled, and any security mechanisms must be implemented by the end user."
The researchers also found 106 different Redis versions compromised, suggesting "there are a lot of Redis installations that are not upgrading to the most recent versions to fix any known security issues." 5,892 infections were linked to the same email address, with two more email addresses that were both linked to more than 200. "The key take away from this research for us has been that insecure default installations continue to be a significant issue, even in 2016."
Redis "is designed to be accessed by trusted clients inside trusted environments," according to its documentation. "This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket... Redis is not optimized for maximum security but for maximum performance and simplicity."
The researchers also found 106 different Redis versions compromised, suggesting "there are a lot of Redis installations that are not upgrading to the most recent versions to fix any known security issues." 5,892 infections were linked to the same email address, with two more email addresses that were both linked to more than 200. "The key take away from this research for us has been that insecure default installations continue to be a significant issue, even in 2016."
Redis "is designed to be accessed by trusted clients inside trusted environments," according to its documentation. "This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket... Redis is not optimized for maximum security but for maximum performance and simplicity."
Lemme guess... (Score:1, Informative)
Belonging to outsourced "software engineers" (i.e. copy-pasters) making $3/hr working for Tata or Infosys?
"5,892 infections were linked to the same email address, with two more email addresses that were both linked to more than 200."
Re: (Score:1)
Most of them belonged to American Ruby on Rails and node.js programmers.
RTFM, People! (Score:5, Insightful)
Redis "is designed to be accessed by trusted clients inside trusted environments," according to its documentation. "This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket..."
What part of "Don't leave this open to the Internet" is not clear?
Re:RTFM, People! (Score:5, Funny)
The technical bits written in English.
Re: (Score:2, Insightful)
FTFY
The bits written in English.
Re: (Score:2)
I (obviously) can't mod this up, but I salute you, Noble Sir|Ma'am|Flipper.
RavenDB, similar problem (Score:1)
Did some contracting work for a firm that builds software for public transportation. Posting anon because of that. Software uses NServiceBus. They need persistence support for NServiceBus. So that meant that RavenDB got enabled. Suddenly end-customer asks why some port is open and why when they browse to it with a webbrowser they find a website that leaks all sorts of data about travelers and about their billing data.
Response from our project manager: none. He just didn't understand the issue.
I'm sure such
Re: (Score:2)
Response from our project manager: none. He just didn't understand the issue.
I'm sure such horror and daily-wtf stories happen all the times.
Sure do. I know of software installed at client sites that has uses the sa account to generate data reports and has the sa password hard coded in plain text on the client machines.
And yes .. I did raise it as an issue when I saw that .. 4 years ago.
Re: (Score:3, Interesting)
I opened two bugs this week.
One for a problem that would not affect operations but only display error messages a customer would never see.
One for a security problem where someone had stored client passwords in plain text in a world readable file.
Came back the next day and saw that the first one had been assigned a high priority and the second one the lowest possible priority.
I'm not even surprised.
It's not done when it works (Score:1)
This is a systemic problem in development, and not just in the software world. Quite often it is difficult to explain the necessity of additional work when the prototype works. Security is invisible, so under tight resource constraints it is the first to get dropped. You can see the same problem in all sorts of tutorials on the web: Almost every tutorial stops once the desired functionality is achieved. It is also important to disable or block off "undesired functionality", yet that part is rarely found in
Re: (Score:2)
Yes.
After 20 years involved as a security "pro" for all aspects of operations and development tools support - I concur that the difference between the security mindset and that of other engineering types is a curiosity beyond use cases.
I refer to these snidely, but in earnest, as the "abuse cases".
Re: (Score:1)
The problem - as so often - is a failing management system. Managers still think that computers are essentially a play box for developers, and they hate the though of someone playing with their money. So on first sight of an apparently working system they yell "all stop and don't move until we tell you to!" while before that moment they constantly shout "show me this works! remember, it just needs to (appear to) work, not bells and whistles, no need to dot the i's and cross the t's! this is not a beauty con
Re: (Score:2)
It is also important to disable or block off "undesired functionality", yet that part is rarely found in tutorials.
I often find that when security is discussed the conversation follows the tack of "Well, could someone achieve anything malicious with this functionality?" The implication being that if the answer is "No", then there's no reason to block the access.
To me, this seems totally backwards. The correct tack would be "Does the system require this functionality to work?" If the answer is "No", then it should always be blocked, even if we can't come up with some way it could be used maliciously.
Excellent info /. thank you (Score:3)
Thank you for this information. I've seen several how-to guides on setting up Redis in various environments but did not come across this stark warning in any of them!
Why why why (Score:2)
""By default, Redis has no authentication or security mechanism enabled..."
Why? Why in the world would you make this the default?
Re: (Score:1)
Which part of "That's a really fucking stupid design decision" do you not understand? Also, the CAP theorem has nothing to do with security. The two are not mutually exclauvie as you try to imply.
Re: (Score:1)
So then LibreOffice's decision not to password protect and encrypt documents by default is also a really fucking stupid decision. Or... tar. Or gz. Or .
You two seem to fail to understand what a "design decision" means and that software is designed to be optimal for SOME use cases, not ALL.
Re: (Score:2)
PostgreSQL supports SSL-based authentication out of the box. True, the actual configuration is up to the admin, but I have no idea what you're going on about them not including security stuff.
SSH tunnel (Score:2)
Okay, I'll stick my neck out. Why can't the redis port be tunneled through ssh?
Check 3.2 protected mode (Score:1)