.jpg)
The All-Too-Frequent Failure of Data Protection in the Field of DevOps and Developers
I have decided to post this as a response to an article I read and ensuing discussion concerning the hacking of servers through RDP.
At present I see several major trends happening in this field:
1. Ongoing transition to DevOps is happening also because of original System people (I am proud to have been one of them once upon a time, those that even used to install 2000/2003 on a physical server!) seeing the demand for 3rd level support declining steadily with the world of Cloud growing fast, so they understand the need to advance and expand into the field of software
2. Current transition to DevOps is happening at fast pace because the software developers have begun to understand that it is not enough to simply “write code”. I can remember the time when the programmer did not know how to install an OS now I am delighted to see software developers that understand: their well-known world of code will have to become a world of Deployment!
3. The younger people, those that never in their lives even tried to install a physical server and did not have to configure a Firewall from scratch, never had to deal with Assembler. These Children of the Cloud can develop products in a much faster way, providing a very effective delivery, albeit based on a pre-existing infrastructure.
I have been discussing the whole issue of DevOps with my colleagues lately, it can become a crucial one, as this community does mostly consist of brilliant system and software people that can work together in the Cloud, in Sweet Harmony (those over 30 might remember that song).
Personally, I have first encountered the field of DevOps while building the AWS infrastructure for an Israeli client. A software guy, whom I was helping to define the system, told me that he wanted to transit to DevOps, and that he was very eager to learn the architecture and networking I have set up for AWS (a quite beautiful structure with VPN clusters and about 200 VPC’s in different areas).
Together with all this, the world of Cyber Threats is changing rapidly in several ways:
1. Cyberattacks have become a fully-fledged business, operating according to a well-developed business model, even if this is performed by “illegitimate” criminal organizations or individuals. Some of the perpetrators used to serve for the Russian or Chinese versions of the NSA, and in China this is even done by proper cyber units of the People Liberation Army.
2. The leakages of government/military level tools (Eternal Blue etc) have proven to be a huge game-changer, version of this software still penetrate systems that have not performed adequate patching until now! The speed with which Eternal Blue has morphed into Ransomware shows how quickly the bad guys adapt to the changes in environment, both in professional and commercial sphere.
3. The size and frequency of DDOS attacks has reached record-breaking levels, and one can order DDOS services in easy and convenient manner, using tools that are similar to the shopping cart, you can see it for yourselves doing a simple search on a Dark Web. The IOT has also become a virtual petri dish for DDOS bots.
4. The phishing threat has risen to a whole new level as means to steal sensitive data and intellectual property.
5. The new and rapidly growing threat is Zero Day Exploits, very difficult to defend against during the initial phase of discovery (just like in point 1)
All this is very challenging, without a doubt.
In the World of Cloud everything becomes easier, more accessible and much more amazing. It is now possible to do in 5 minutes what would have taken 5-6 days before the Cloud was here, or even things that were just a fantasy just a few years ago.
Some of these changes are the possibility of deploying Virtual Machines in a few minutes’ time and getting instant access, Microsoft has also embraced the AWS approach, while dropping the default choice of NAT, so that the new machines are supplied directly with open 3389 (thus ensuring more speed).
Now let us look back at our headline: why is the world of DevOps so slow to grasp the importance of Data Protection? From my experience as a consultant and designer of system architecture, the DevOps people cannot grasp the severity of the Cyber threat for some of the following reasons:
1. Those that have transited from system administration and design know how to configure a server or a firewall, but they do not look at the application side, so if they need to install an outward-looking IIS server, they do not bother with configuring the necessary permissions and privileges, as this is “not really my business”
2. Those who were software developers tend to exhibit more understanding of the applicative risks (like SQL Injection and various WAF issues), but all too frequently I see those guys setting up DEV machines with open 3389 configurations protected by ridiculously simple passwords (they think that because it is Dev – this is not really that important)
3. Younger-generation Cloud kids that are used to direct cloud deployments usually do have awareness of Data Protection (a pleasant surprise!), but mostly use the only the ready-made manufacturer’s solutions, but if the concrete system requires a custom solution of some sort, like some sort of On-Prem connection, they cannot do it and there is no effective Data Protection as a result
What is to be done? They need to study and to learn new things! I have been dealing with the broad theme of Data Protection for many years already, but my eyes really were opened after I attended the very complicated and challenging course of Offensive Security, which really gave me the hands-on experience of Penetration Testing. During this course you could
really see the process as performed by the attacker, who may be a system or software expert, a very creative and formidable foe.
Roughly, this is how it looks from the attacker’s point of view:
1. Full scan and obtaining a complete system status and external structure
2. Searching for weak spots
3. Using existing tools to exploit the system weaknesses
4. Building custom tools to exploit some of the weak spots
5. Executing the exploit
6. Your server is toast
This is a very concise summary, but enough to get a clear picture:
1. When you install a server with open 3389, in a matter of seconds your server will be identified by various scanners that search the networks all the time, without stopping! The attacker, usually running a script, gets a precise update on a new open 3389 server. Following that, the operating system can by deduced based on the version of RDP that is detected
2. After a few seconds the attacker’s scanner will start using a tool like Brut Force or Dictionary Attack, a relatively simple password will be discovered in a few minutes and your system breached (yes, a few minutes – during my lectures I sometimes set up a demo, showing how easy it is to breach AWS or Azure server with a simplistic or predictable password.
Yes, the open 3389 configuration is a “disaster”, because it gives the attackers some of the following information:
1. I am not very professional, and me installing the open 3389 means that I also neglect installing addition defenses and security features
2. This is a newly-installed server, without much or any protection, so this is the perfect time to penetrate the system, plant the “package”, and then wait to see what will be the purpose and content of the server (perfect for DC, as an example)
3. My passwords will most probably be weak and predictable
On the issue of RDP:
1. This protocol allows to run Remote Execution through it, which means running a malware without a need to plant it inside the server in advance
2. Even if you have full patching, a weak password will give an attacker an opening to sneak in and plant the package in space of seconds, getting control of the server
So here is what needs to be done:
1. You do not open a 3389 unless it is done through VPN or through ACL that restricts access to the source
2. The passwords always (always!!!) need to be complex, never use the words that might appear in a dictionary, use password generators!
3. You need to study all the time – every DevOps/Dev person needs to learn about existing and new off-the-shelf tools, such as Kali and others
One more thing (DevOps guys, please do not get angry with me about that): very few people are able to become true jacks-of-all-trades, that is why big tech companies employ dedicated DevOps teams that include system people, software developers and cyber experts as well.
The biggest problem is usually encountered when setting up new smaller companies or start-ups that do not possess the resources for the appropriate planning and execution of Data Protection. This can lead to Intellectual Property being obtained by your competitors (mostly in China, but also in other places) from the first day of the server’s operation.
To sum it all up:
1. A 3389 port that is open to the internet is a really bad idea
2. Simple passwords, even for a small Dev server, is very bad too
3. Learning basic Data Protection is a must of all the range of DevOps positions
Eli Migdal – TowerWatch Solutions - CEO
The All-Too-Frequent Failure of Data Protection in the Field of DevOps and Developers
I have decided to post this as a response to an article I read and ensuing discussion concerning the hacking of servers through RDP.
At present I see several major trends happening in this field:
1. Ongoing transition to DevOps is happening also because of original System people (I am proud to have been one of them once upon a time, those that even used to install 2000/2003 on a physical server!) seeing the demand for 3rd level support declining steadily with the world of Cloud growing fast, so they understand the need to advance and expand into the field of software
2. Current transition to DevOps is happening at fast pace because the software developers have begun to understand that it is not enough to simply “write code”. I can remember the time when the programmer did not know how to install an OS now I am delighted to see software developers that understand: their well-known world of code will have to become a world of Deployment!
3. The younger people, those that never in their lives even tried to install a physical server and did not have to configure a Firewall from scratch, never had to deal with Assembler. These Children of the Cloud can develop products in a much faster way, providing a very effective delivery, albeit based on a pre-existing infrastructure.
I have been discussing the whole issue of DevOps with my colleagues lately, it can become a crucial one, as this community does mostly consist of brilliant system and software people that can work together in the Cloud, in Sweet Harmony (those over 30 might remember that song).
Personally, I have first encountered the field of DevOps while building the AWS infrastructure for an Israeli client. A software guy, whom I was helping to define the system, told me that he wanted to transit to DevOps, and that he was very eager to learn the architecture and networking I have set up for AWS (a quite beautiful structure with VPN clusters and about 200 VPC’s in different areas).
Together with all this, the world of Cyber Threats is changing rapidly in several ways:
1. Cyberattacks have become a fully-fledged business, operating according to a well-developed business model, even if this is performed by “illegitimate” criminal organizations or individuals. Some of the perpetrators used to serve for the Russian or Chinese versions of the NSA, and in China this is even done by proper cyber units of the People Liberation Army.
2. The leakages of government/military level tools (Eternal Blue etc) have proven to be a huge game-changer, version of this software still penetrate systems that have not performed adequate patching until now! The speed with which Eternal Blue has morphed into Ransomware shows how quickly the bad guys adapt to the changes in environment, both in professional and commercial sphere.
3. The size and frequency of DDOS attacks has reached record-breaking levels, and one can order DDOS services in easy and convenient manner, using tools that are similar to the shopping cart, you can see it for yourselves doing a simple search on a Dark Web. The IOT has also become a virtual petri dish for DDOS bots.
4. The phishing threat has risen to a whole new level as means to steal sensitive data and intellectual property.
5. The new and rapidly growing threat is Zero Day Exploits, very difficult to defend against during the initial phase of discovery (just like in point 1)
All this is very challenging, without a doubt.
In the World of Cloud everything becomes easier, more accessible and much more amazing. It is now possible to do in 5 minutes what would have taken 5-6 days before the Cloud was here, or even things that were just a fantasy just a few years ago.
Some of these changes are the possibility of deploying Virtual Machines in a few minutes’ time and getting instant access, Microsoft has also embraced the AWS approach, while dropping the default choice of NAT, so that the new machines are supplied directly with open 3389 (thus ensuring more speed).
Now let us look back at our headline: why is the world of DevOps so slow to grasp the importance of Data Protection? From my experience as a consultant and designer of system architecture, the DevOps people cannot grasp the severity of the Cyber threat for some of the following reasons:
1. Those that have transited from system administration and design know how to configure a server or a firewall, but they do not look at the application side, so if they need to install an outward-looking IIS server, they do not bother with configuring the necessary permissions and privileges, as this is “not really my business”
2. Those who were software developers tend to exhibit more understanding of the applicative risks (like SQL Injection and various WAF issues), but all too frequently I see those guys setting up DEV machines with open 3389 configurations protected by ridiculously simple passwords (they think that because it is Dev – this is not really that important)
3. Younger-generation Cloud kids that are used to direct cloud deployments usually do have awareness of Data Protection (a pleasant surprise!), but mostly use the only the ready-made manufacturer’s solutions, but if the concrete system requires a custom solution of some sort, like some sort of On-Prem connection, they cannot do it and there is no effective Data Protection as a result
What is to be done? They need to study and to learn new things! I have been dealing with the broad theme of Data Protection for many years already, but my eyes really were opened after I attended the very complicated and challenging course of Offensive Security, which really gave me the hands-on experience of Penetration Testing. During this course you could
really see the process as performed by the attacker, who may be a system or software expert, a very creative and formidable foe.
Roughly, this is how it looks from the attacker’s point of view:
1. Full scan and obtaining a complete system status and external structure
2. Searching for weak spots
3. Using existing tools to exploit the system weaknesses
4. Building custom tools to exploit some of the weak spots
5. Executing the exploit
6. Your server is toast
This is a very concise summary, but enough to get a clear picture:
1. When you install a server with open 3389, in a matter of seconds your server will be identified by various scanners that search the networks all the time, without stopping! The attacker, usually running a script, gets a precise update on a new open 3389 server. Following that, the operating system can by deduced based on the version of RDP that is detected
2. After a few seconds the attacker’s scanner will start using a tool like Brut Force or Dictionary Attack, a relatively simple password will be discovered in a few minutes and your system breached (yes, a few minutes – during my lectures I sometimes set up a demo, showing how easy it is to breach AWS or Azure server with a simplistic or predictable password.
Yes, the open 3389 configuration is a “disaster”, because it gives the attackers some of the following information:
1. I am not very professional, and me installing the open 3389 means that I also neglect installing addition defenses and security features
2. This is a newly-installed server, without much or any protection, so this is the perfect time to penetrate the system, plant the “package”, and then wait to see what will be the purpose and content of the server (perfect for DC, as an example)
3. My passwords will most probably be weak and predictable
On the issue of RDP:
1. This protocol allows to run Remote Execution through it, which means running a malware without a need to plant it inside the server in advance
2. Even if you have full patching, a weak password will give an attacker an opening to sneak in and plant the package in space of seconds, getting control of the server
So here is what needs to be done:
1. You do not open a 3389 unless it is done through VPN or through ACL that restricts access to the source
2. The passwords always (always!!!) need to be complex, never use the words that might appear in a dictionary, use password generators!
3. You need to study all the time – every DevOps/Dev person needs to learn about existing and new off-the-shelf tools, such as Kali and others
One more thing (DevOps guys, please do not get angry with me about that): very few people are able to become true jacks-of-all-trades, that is why big tech companies employ dedicated DevOps teams that include system people, software developers and cyber experts as well.
The biggest problem is usually encountered when setting up new smaller companies or start-ups that do not possess the resources for the appropriate planning and execution of Data Protection. This can lead to Intellectual Property being obtained by your competitors (mostly in China, but also in other places) from the first day of the server’s operation.
To sum it all up:
1. A 3389 port that is open to the internet is a really bad idea
2. Simple passwords, even for a small Dev server, is very bad too
3. Learning basic Data Protection is a must of all the range of DevOps positions
Eli Migdal – TowerWatch Solutions - CEO
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר
