Module request: CVE-2017-7679

[elogada]

Any chance we can have a module for https://nvd.nist.gov/vuln/detail/CVE-2017-7679? User @gottburgm made a POC in https://github.com/gottburgm/Exploits/blob/master/CVE-2017-7679/CVE_2017_7679.pl and I was thinking perhaps we can make an Auxiliary of it (if there already was such a module, please guide me). My main problem with this one is that I can't find a more considerable POC that does not involve adding to the config file (the CVE seems to dictate that it is a remote attack, and is unauthenticated. Although, do guide me please, if I may be wrong.

Thanks!

[gottburgm]

Hello, just some informations : i made for the customers as a reproducer more than a PoC, and as i remember, i had to hardcode the "malicious" content type into the httpd module with handle the request. So it can be exploited remotely yes, but the "target" would have to have a vulnerable module set as the handler, which will never happen in real cases.

Again, just took 2mins to read my code i didn't searched more, but thats probably why there are few PoCs. Hope i helped. :)

[wvu]

Thank you, @gottburgm!

[Rohandud]

Hello, just some informations : i made for the customers as a reproducer more than a PoC, and as i remember, i had to hardcode the "malicious" content type into the httpd module with handle the request. So it can be exploited remotely yes, but the "target" would have to have a vulnerable module set as the handler, which will never happen in real cases.

Again, just took 2mins to read my code i didn't searched more, but thats probably why there are few PoCs. Hope i helped. :)

please make the code for it , for POC

[h00die]

@Rohandud I think it's pretty unlikely that someone will want to spend time writing a module for something that:

1. is 2.5yrs old
2. leaks 1 byte
3. "which will never happen in real cases"
4. already has a PoC

So while I'm not saying it won't happen, it's doubtful on the best of cases.

[Rohandud]

@Rohandud I think it's pretty unlikely that someone will want to spend time writing a module for something that:

1. is 2.5yrs old
2. leaks 1 byte
3. "which will never happen in real cases"
4. already has a PoC

So while I'm not saying it won't happen, it's doubtful on the best of cases.

Yes mate, I think u are Right, btw did u encounter this cve while enumerating apache httd 2.4.18 and if please tell me how did you got in!?🙏

[h00die]

This vulnerability seems to leak one byte of data. You'll have a tough time "getting in" if it's a random byte as you won't know what that byte is for/to.

[gottburgm]

in fact, by experience i can tell you that if you search for CVE exploitation tools related to a CVE which would let you do hardcore stuff such as RCE/LFI/whatever critical vulnerability you will:

• find plainty of tools
• do illegal shits which has 0 values with
• exploit what the guys who published the tools already hacked 1 month before the CVE public disclosure which is something for me, that is equivalent to share your gf with your bestfriend(s)

And CVE affecting httpd, you can honestly stop wasting your time on it. Lets take the time that i dont have to clearly state what i mean as a reference for any readers:

HTTPd is maintained mostly by redhat and the apache software foundation and their haxor developers communities, httpd is the webserver running on more than 60% of all web servers.

Check how many CVEs are related to httpd and its components and check how many of them could have been used in a remote exploitation (even local) which could allow the attacker to gain whatever kind of thing from it, i think less than 15, lets say 20. now the potential targets would have to be misconfigured and/or running an unpatched version of httpd because most of the 20 CVEs are probably due to user misusages of httpd and not core vulnerabilities.

Already seems to be a total waste of time? lets continue to hypotetically analyse that:

httpd is pre installed and even in some case pre enabled and running in multiple linux distributions and clearly not customized debian shitty ISO one, we talk about distribution like rhel,fedora,... the one that all the agencies that skiddies dream about use for their servers, and the one running on most of medical/security/war weapons/... IoT devices.

Ok, but we can still find some pwnable lost servers ! No, all the internet connected devices are scanned and published every single day by providers such as shodan,... and httpd/apache can be detected+version fingerprinted+ often but not always have components used and their own versions in one single HTTP Request. if you have time for that, i let you calculate how many http requests it would take to query every IPs addresses on port 80 or even on every port. I dont know how many requests it would take because im lazy but i can tell you that my http requester module which send every single request trough a different tor circuit take less than 12s (in average) and that im talking about a single threaded request. My computer would be able to to get all the internet httpd servers running without that much time and efforts.

Finally remember China,Russia,Israel,Noth Korea exists and have billions invested in cyber defense and offense, add to that the usual russians haxors that could destroy a country from a shitty room with a pentium cooled with a 2 fans self made shit and ask your self if they not already found all the targets affected by a public vulnerability affecting their opponents countries servers before you.

hope that i will help you and potential future readers by this example. It can be hard to see it as it is but you will never be the best, you will never be researched by any agencies because you will never do anything harmless/usefull/that i would even consider a thing by using a CVE.

Find them, as this particular CVE, its hypotetically a vulnerability but never exists in real world. And that is some of the many cool things that you can start to do: patching vulnerabilities that even doesnt exists ;)