Last Login: October 01, 2020
hartescout's Contributions (9)
The issue with ranking exploitability even the vulnerability with rest api in this particular instance would be a combination of “are recommended measures in place to mitigate if it exists in the first place” and “how willing the actor would be be to exploit”. If the given scenario for exploitation presents itself, then it will be fairly quick and easy to exploit and get to the meat and begin enumerating other endpoints and privilege. To even conduct the reconnaissance necessary to have an idea of vulnerability seems a pretty difficult task in my limited knowledge.
That said, if identified and utilized, this is powerful.
While the vulnerable code resides within the Cisco REST API container, the effects of the vulnerability, if exploited, will be experienced on the Cisco device as a whole. This is because exploiting this vulnerability could allow an attacker to submit commands through the REST API that will be executed on the affected device.
The fact that in the blog post sited here on AttackerKB the author uses the work “only” when describing the hardware effected sets off a bit of an alarm bell in my opinion. Any CVE allowing commands at level specified to be issued on an endpoint is cause for concern, especially with something as simple to manipulate as REST API Most certainly if standard reconnaissance methods can identify.
Only the following Cisco platforms supports the affected Cisco REST API container and are therefore potentially impacted by this vulnerability: Cisco 4000 Series Integrated Services Routers Cisco ASR 1000 Series Aggregation Services Routers Cisco Cloud Services Router 1000V Series Cisco Integrated Services Virtual Router
Another thing we must remember as researchers, on either side, is that our analysis and public disclosure also acts and beneficial information for any threat actor. So, I’d say definitely be cautious in publishing information that downplays a CVE as it can appear complacency is setting in.
Okay, to end of all my unnecessary commentary I’d say this is a pretty useful vulnerability if risk of exploitation is obvious and in numbers exceeding risk matrices or thresholds developed by in house teams.
” Multiple ZyXEL devices achieve authentication by using the weblogin.cgi CGI executable. This program fails to properly sanitize the username parameter that is passed to it. If the username parameter contains certain characters, it can allow command injection with the privileges of the web server that runs on the ZyXEL device. Although the web server does not run as the root user, many ZyXEL devices include a setuid utility that can be leveraged to run any command with root privileges. As such, it should be assumed that exploitation of this vulnerability can lead to remote code execution with root privileges.
Exploit code for this vulnerability that targets NAS devices is available on the internet. “
Exploits are available. What interests me is this shodan.io search posted with 138,000+ devices still vulnerable. A firmware update has been released for most versions of device however, ” Block access to the ZyXEL device web interface “ is the advice for remaining or an alternative.
Here is the shodan search I put in as a reference for the topic as well. Again, you’re expert opinion is much more valuable than mine at this early stage. I am unfortunately unable to test these in my lab environment due to other commitments.
edit: I might be mistaken CVE-2020-9054 is listed as the exploit here: https://kb.cert.org/artifacts/cve-2020-9054.html
This one is fairly new. I will put a few quotes in here as they display my ideas of why this should be considered high priority and have better writing skills than I do, unfortunately.
I was initially alerted (again) to this CVE with the Thread linked here : https://twitter.com/GossiTheDog/status/1232368620270911488
I agree, enterprise environments with Internet facing Exchange. As stated in the thread, you can see a simple search with shodan.io will expose this vulnerability. There are thousands that qualify.
Here is another, more formal and thorough analysis I think you will find helpful: https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys
Here is a video of bug in action.
This is a RCE vulnerability that effects Microsoft Exchange Server. Now a patch was released, but Microsoft has not classified this as critical, so we will see how effective it is.
“Instead of having randomly-generated keys on a per-installation basis, all installations of Microsoft Exchange Server have the same validationKey and decryptionKey values in web.config. These keys are used to provide security for ViewState. ViewState is server-side data that ASP.NET web applications store in serialized format on the client. The client provides this data back to the server via the __VIEWSTATE request parameter. “
I welcome any discussion, please tell me if I missing something. I would love to hear more about this and if any Blue Team has had an incident already.