Thanks to Kurt over at DWF I was able to get a CVE assigned for the OSSEC SQL-Injection detailed in my previous post CVE-2016-1000266 / CVE-2016-1000265
Was happy to help the guys over at OSSEC patch the problem and I’m glad it’s getting some acknowledgement.
Hijacking a Victim’s DNS with Anti DNS-Pinning(DNS Re-binding)
Last night I got on the kick of router/modem security considering the recent attacks we’ve had going on I thought it might be nice to jump on the bandwagon of researchers and check it out for myself.
With this I thought I’d simulate an attack I was able to perform in a penetration test because a router had remote management enabled, which was hijacking the victim’s DNS requests via DNSChef and getting a MITM to steal the victim’s credentials as they logged into a specific website.
That was all achieved by simply changing the victim’s DNS settings on their router,
So the question became what’s stopping me from doing this to my own modem via a web browser on an internet facing URL.
Immediately I started looking for any code which may not enforce the Same-origin policy to explain briefly the Same-origin policy was created to protect against attacks where web code attempts to make a request to a server where it’s unauthorized to do so (meaning local network resources as well like modems and routers).
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 »
I had recently been inspired by a video from a man who goes by the alias “Scamalot” in this video series he responds to spam emails and simply “trolls” the scammers, phishers, or spammers the series is great, and I highly recommend checking it out if you haven’t ( https://www.youtube.com/watch?v=dSoXEtFPTfI ).
Well due to being inspired by this I decided to take it upon myself to start attempting to “troll” or annoy these spammers, scammers, and phishers myself as it seemed to be my duty at this point considering the amount of spam I regularly receive it was a great idea.
Coming into this the last thing that I expected to do is take over a phish page and leave a warning for those who clicked on it in the future but, that’s exactly what I ended up doing….