In order to defend your system against cyber-attacks, you must also be knowledgeable in methods of attacking that system. Although the realization came at a later time, Cisco was able to discover a potential method of attack against their Redundancy Configuration Manager for their StarOS system during security testing. Thankfully, no one had exploited the system during the time it was exposed, and Cisco was able to send out fixes to their users. It was very important, as this would prevent a Remote Code Execution attack on StarOS.
What is Remote Code Execution (RCE)?
https://beaglesecurity.com/blog/images/RCE.png
RCE is an attack method where an unauthenticated attacker with malicious intent is able to execute their code remotely on a targeted device or system over local network or the internet. RCE is considered to be one of the most dangerous forms of attacks on a device, as it can cause a potential theft of data or loss of control on systems.
There are multiple methods to lead an RCE attack with varying impacts which includes:
- Dynamic code execution
- Buffer Overflow
- Design flaws – Hardware/Software/Security
Attacking StarOS
What was the issue with StarOS? According to Cisco, they had found out that the debug mode in the system was enabled for certain services which should not have access. This meant that attackers were able to exploit a security design flaw in order to launch their RCE attack, by connecting to the device and using the service that could access debug mode. If such an attacker were successful, they would have been able to execute commands with the highest level of privilege in the system, which would be very terrifying, as stated before, Cisco could lose control of their StarOS system, as well as have sensitive data and information be stolen from them.
Takeaway
The key takeaway from this event, is the importance of thinking like an attacker when developing and defending your system. Many flaws could be prevented by knowing how an attacker may look at the system to exploit it. Things that are now common such as exploiting buffer overflows can be prevented by fixing any such instance in your code.
https://www.devprojournal.com/wp-content/uploads/2020/02/software-testing-696×392.jpg
Testing your system or code is also very important. Had it not been for the internal security testing, the company would have not found out about the potential issue, and it could have been the case where the worst possible outcome occurs. Testing should be done during the development cycle of your system as well as regularly when it has been pushed and is live. Even the smallest of mistakes could lead to the worst outcomes, which includes setting a simple binary value of user access incorrectly.
Additional Notes and Closing
If you know anyone that uses Cisco’s StarOS system, it would be a great idea to let them know of this issue and ensure that they have the latest version that Cisco released which patches the vulnerability. If there are other products from Cisco that is used by you and your peers, it might be worth to check out Cisco’s Security Advisories website for any potential threats, as due to this event, Cisco found further vulnerabilities in their other systems which includes:
- Information Disclosure Vulnerability
- Denial of Service (DoS) Vulnerability
- Command Injection (CLI) Vulnerability
Of course, this goes for more than just Cisco products. Whichever system it is you are using, make sure to keep updated with any news or information from the company in case incidents like these occur. Stay safe!
References
- https://thehackernews.com/2022/01/cisco-issues-patch-for-critical-rce.html
- https://www.bleepingcomputer.com/news/security/cisco-bug-gives-remote-attackers-root-privileges-via-debug-mode/
- https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-rcm-vuls-7cS3Nuq
- https://blog.sqreen.com/remote-code-execution-rce-explained/
This is a really good post!
It definitely makes sense that an RCE attack would be one of the most dangerous types of attacks, seeing how anyone it can run any code that they choose to write if they get in. They basically get full control, which is quite crazy. It must be extremely difficult to see vulnerabilities before someone else, because essentially you’d need highly trained people to spot every single thing before a skilled hacker sees it. Not to mention the large code bases that are thousands to millions of lines of code, I’d imagine it would be quite the nightmare trying to spot every potential vulnerability, and I suppose that it’s sadly due to this that things like this happen.
Hey,
Great post! It’s interesting how effective a remote code execution is. When I was researching the Log4J exploit attackers did a similar thing and their code execution was often enabling new exploits for later use. It makes me wonder how we could prevent such a thing. With the Log4J exploit many packages had to review many layers deep of code and I imagine a company like Cisco has a massive code base so reviewing it would take a lot of time.
This post truly exemplifies the entire ideology of this class. Knowing how someone can break your system and trying to break it yourself to find the flaws are the exact types of good behavior patterns we are being taught. Trying to hit your own system from every angle, whether that be an RCE or simply trying to crack a user’s password through random guessing, is what all companies that manage their own security need to be doing in order to ensure that their users are protected from such attacks. Good on you for giving an example of just how important it is to break through the cracks before someone else can.
Great work! The content is very interesting, I specifically liked how you inserted a flow diagram of the RCE to explain the concept. It definitely educates novice readers in an efficient way. So from an industrial techie point of view, assessing security threats is one of the most important processes that needs to be carried out throughout the development lifecycle. I completely agree with you on that view. One of the reasons it should not be postponed till the after the software is developed is that the world is moving towards agility, the “Agile way of development”, meaning stages of prototypes are iteratively developed and released so some of the established features and knowledge of the system can be overlooked so it is essential to test them periodically. And security is taken lightly and especially startups don’t invest significantly in it. That needs to change. Another point that caught my eye was how people should possess knowledge of attacking mechanisms in order to be equipped to prevent them. White hat hackers are important to software companies and need more job opportunities as their scope increases with new technology innovations. There was a controversy earlier when educators were against teaching students to hack and attack systems fearing they would go rogue but this is an essential tradeoff to ensure security.
Great post! You also raise some great points about thinking like an attacker to be a good defender, because no one builds a perfect system in their first try, and you would have to break the system again and again to find vulnerabilities, and it is better to find vulnerabilities while still developing, rather than when you release the system to the public.