Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improves detection of the MS15-034 #5386

Merged
merged 6 commits into from May 28, 2015
Merged

Improves detection of the MS15-034 #5386

merged 6 commits into from May 28, 2015

Conversation

erwanlr
Copy link
Contributor

@erwanlr erwanlr commented May 20, 2015

Currently only the /welcome.png is checked, however in practise, this file is barely there.

Furthermore, some scanners like Nessus often fail to properly detect the issue, and when it's detected, the vulnerable file is not provided.

I've improved the detection based on a script I created at work: https://github.com/RandomStorm/scripts/blob/master/ms15-034-checker.rb

The idea is to extract all potential static files from the index page and test them rather than just check the /welcome.png.

Output examples:

Vulnerable:
w/o Verbose:

msf auxiliary(ms15_034_ulonglongadd) > check

[*] X.X.X.X:80 - Checking /static/banner.jpg [416] - Vulnerable
[+] X.X.X.X:80 - The target is vulnerable.
[*] Checked 1 of 1 hosts (100% complete)

with verbose:

msf auxiliary(ms15_034_ulonglongadd) > check

[*] X.X.X.X:80 - Checking /welcome.png [404] - Unknown
[*] X.X.X.X:80 - Checking /static/banner.jpg [416] - Vulnerable
[+] X.X.X.X:80 - The target is vulnerable.
[*] Checked 1 of 1 hosts (100% complete)

Not vulnerable:
w/o verbose:

msf auxiliary(ms15_034_ulonglongadd) > check
[*] 192.168.1.24:80 - The target is not exploitable.
[*] Checked 1 of 1 hosts (100% complete)

with verbose:

msf auxiliary(ms15_034_ulonglongadd) > check

[*] 192.168.1.24:80 - Checking /welcome.png [400] - Safe
[*] 192.168.1.24:80 - The target is not exploitable.
[*] Checked 1 of 1 hosts (100% complete)

Unknown (Debian Server):
w/o verbose:

msf auxiliary(ms15_034_ulonglongadd) > check
[*] 192.168.1.103:80 - Cannot reliably check exploitability.
[*] Checked 1 of 1 hosts (100% complete)

with verbose

msf auxiliary(ms15_034_ulonglongadd) > check

[*] 192.168.1.103:80 - Checking /wordpress-4.2/welcome.png [404] - Unknown
[*] 192.168.1.103:80 - Checking /wordpress-4.2/xmlrpc.php [405] - Unknown
[*] 192.168.1.103:80 - Checking /wordpress-4.2/wp-content/themes/twentyfifteen/genericons/genericons.css [200] - Unknown
[*] 192.168.1.103:80 - Checking /wordpress-4.2/wp-content/themes/twentyfifteen/style.css [200] - Unknown
[*] 192.168.1.103:80 - Checking /wordpress-4.2/wp-includes/js/jquery/jquery.js [200] - Unknown
[*] 192.168.1.103:80 - Checking /wordpress-4.2/wp-includes/js/jquery/jquery-migrate.min.js [200] - Unknown
[*] 192.168.1.103:80 - Checking /wordpress-4.2/wp-includes/wlwmanifest.xml [200] - Unknown
[*] 192.168.1.103:80 - Checking /wordpress-4.2/wp-content/themes/twentyfifteen/js/skip-link-focus-fix.js [200] - Unknown
[*] 192.168.1.103:80 - Checking /wordpress-4.2/wp-content/themes/twentyfifteen/js/functions.js [200] - Unknown
[*] 192.168.1.103:80 - Cannot reliably check exploitability.
[*] Checked 1 of 1 hosts (100% complete)

Some questions/remarks:

@erwanlr
Copy link
Contributor Author

erwanlr commented May 20, 2015

cc @firefart for comments :D

@void-in
Copy link
Contributor

void-in commented May 20, 2015

Should /cc @wchen-r7 as well since he originally wrote the module

@wchen-r7
Copy link
Contributor

That looks smarter and more thoughtful, overall I like it.

next unless uri.host == vhost || uri.host == rhost

uris << uri.path if uri.path =~ /\.[a-z]{2,}$/i # Only keep path with a file
rescue => e
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Swallowing all exceptions is not a good coding practice. Do you know if there's something particular you're trying to rescue? Maybe you shouldn't rescue at all?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just don't want the scanner to be stopped due to something weird like an encoding issue or pretty much anything

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand, but you're taking over some console functionalities when you rescue everything. Interrupt is an example, you don't want to deny the user the ability to hit the e-brakes at anytime. You've also lost the ability to log errors to framework.log.

It looks like the block you're rescuing shouldn't be raising anything anyway (not even URI.encode, I guess). If you can handle the nils properly, you should not need exception handling at all.

@todb-r7 todb-r7 added the bug label May 20, 2015
@wchen-r7
Copy link
Contributor

Looking good. I will test this tomorrow, thanks @erwanlr

@wchen-r7 wchen-r7 self-assigned this May 21, 2015
@wchen-r7
Copy link
Contributor

Tried this PR. So the check part works, but the dos part doesn't anymore because whatever potential_static_files_uris finds isn't shared with the dos_host and get_file_size method.


return Exploit::CheckCode::Vulnerable
elsif res && res.body.include?('The request has an invalid header name')
vprint_status("#{vmessage} - Safe")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These messages aren't very necessary. If you run the check command, basically it will tell you the check result twice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you meant the 'run command' instead of 'check command' ?

If those are removed, the vulnerable file or tested ones are never displayed, leading to the same behaviour as Nessus: it just tells you if it's vulnerable or not, w/o any relevant output (i.e the files tested) which is extremely annoying when you want to double check or provide an easiest way for a client to verify the issue (using curl for example)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a check command. It handles our check codes. It's different from the run command. <-- wait never mind, you know this. You demo'd this in the PR description.

Sorry I wasn't being clear enough. I only meant the safe/vulnerable messages. You can vprint which files are tried or useful, definitely handy, but please avoid the safe/vulnerable messages because the check handler is doing that already.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm you know what.... if you don't say vulnerable/safe it's kind of weird too. Please disregard my feedback.

You do need to vprint print_status("#{peer} - #{uri} is vulnerable") though. We started enforcing this last year.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I should be able to land this today.

@erwanlr
Copy link
Contributor Author

erwanlr commented May 28, 2015

the target_uri is now shared between the check and dos methods (thought is was by default but not huhu)

@wchen-r7
Copy link
Contributor

Module works perfectly. Excellent work @erwanlr , thanks again!

@wchen-r7 wchen-r7 merged commit a74c337 into rapid7:master May 28, 2015
wchen-r7 added a commit that referenced this pull request May 28, 2015
@erwanlr
Copy link
Contributor Author

erwanlr commented May 28, 2015

Yay !

You're welcome :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants