First let me explain what OSSEC is and why a vulnerability in this system is important.
OSSEC is an host based open-source intrusion detection system…
Most recently there’s been a few vulnerabilities found and disclosed in it that have gotten rather concerning to me
These become a larger issue when the vulnerability I’ve found requires you to have access to the agent at a level where you can modify the configuration file, I consider what I’ve found to be slightly more severe in larger environments because depending on the configuration of the server system it could allow a full-scale breach instead of a single agent being compromised.
In theory once someone was to exploit/hack or gain access to an agent in any way the only thing you’re concerned with is that agent where the SQL injection takes place in the central server where the agents report to, in some cases this central server is within a corporate network that’s meant to be segregated from the rest of the agents… in theory once one was to compromise the central server of something like this access to additional systems or all of the systems/agents is to follow…
The idea of someone gaining access to an entire enterprise network, but because the system itself is meant to detect intrusions… with the SQL injection that I’ve discovered it would be possible to wipe evidence and make sure people weren’t able to see it given they weren’t recording to email regardless I feel it nearly renders the system useless in a sense.
More concerning is that a lot of people are recommended to use this system post-failure of PCI audits ( Meaning consumer credit card data should be protected by a system with vulnerabilities in it ).
I’ve also since writing this article submitted a pull-request to attempt to fix the vulnerability mentioned in this article (https://github.com/ossec/ossec-hids/pull/923), and requested a CVE which I’ll add to this article once I have it.
All of that aside…
A few days ago I’m upgrading OSSEC on some machines and install a non-stable development/release candidate on one of the systems connecting back to my 2.8.3 (Latest stable/release instance) immediately I notice that my agent isn’t reporting…
I check logs and notice SQL syntax errors, now at first I think nothing of this, it’s strange but not alarming yet….
Then I notice what the syntax errors are actually being caused by and I find that I’ve just discovered an SQL Injection in OSSEC’s server system when using a database (Yes this includes Postgresql).
2016/08/17 12:52:03 ossec-dbd(5203): ERROR: Error executing query ‘SELECT id FROM location WHERE name = ‘thedefaced->netstat -tan |grep LISTEN |grep -v ‘127.0.0.1’ | sort’ AND server_id = ‘1’ LIMIT 1′. Error: ‘You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘127.0.0.1’ | sort’ AND server_id = ‘1’ LIMIT 1′ at line 1′.
That being said I’ve done some research on this and even attempted exploiting it to gain a proof of concept considering the latest release candidate ships with the configuration file that caused this ordeal in the first place I would assume that the latest version is patched against this, yet was not back ported to the latest stable release…
To start lets discuss what could happen with this,
Continue reading »