Is trial and error the only approach to 30+ possible exploits?

Off-topic Exploits
, , ,
1

“Unlimited possibilities are not suited to man”

I just rooted Grandpa without metasploit but idk how long I would have spent on priv esc without some nudges from walkthroughs. I ran windows-exploit-suggester and got 30+ important/critical vulnerabilities. Sure only the first 10 had links, but each of those 10 had a few exploit links, with one having 6 exploits!

At this point I looked at walkthroughs to see how others approached chopping this forest down and was surprised to learn that everyone just picked up their axes and started chopping.

I was thinking at least there has to be a working exploit here…better to have 30 exploits than none…but from what I read no one was able to get them working, with one person trying ALL of them. It turns out the only exploit I saw others get working (I clicked on all the links on the first page of google) was the churrasco.exe exploit, which wasn’t even on the original list…and to tell the truth I still don’t know how they decided to go with this exploit. I guess using whoami /priv to look for SeImpersonatePrivilege means try churrasco?

So my question is, what is your methodology in this situation? And why did windows-exploit-suggester give so many false positives?? And…can you ever be sure these are all false positives??? What if you didn’t see the churrasco route, wouldn’t the only option be to try harder by climbing down that rabbit hole a second time looking for something other than rabbits??

Here are two great walkthroughs on grandpa I used:
@0xdf is the first place I look for walkthroughs.

This next guy was the one who tried them all, wasn’t very clear how he knew to try churrasco.

In case you like words:
“Unlimited possibilities are not suited to man; if they existed, his life would only dissolve in the boundless. To become strong, a man’s life needs the limitations ordained by duty and voluntarily accepted. The individual attains significance as a free spirit only by surrounding himself with these limitations and by determining for himself what his duty is.”- The I Ching or Book of Changes, Hexagram 60

2

In a way you already answered your own question. You started with 30+ options, but through gaining more information you reduced the list to 10. Yes, you may have missed a key one, but that happens to everyone, and 10 is a lot better than “unlimited”. :wink:

When you are walking around in the dark, sometimes bumping your head on something is the only way to find out where you are. It’s painful but effective. Every time you find an exploit or approach that doesn’t work, you learn more about the target or about your tools.

Every time you search and later learn that you missed a key exploit or article, you learn how to search for it next time, you learn the keywords used by the exploit author or the software vendor, you get a better idea of how they think. Then the next time you search, you’ll likely find a little bit more.

In summary, don’t fall in to the trap of thinking of trail-and-error as a bad thing, and practice helps. Sometimes the hard way is the best way.

3

At a basic level, tools like *-Exploit-Suggester are probably best seen as a bit of a Hail Mary, same with the enum scripts/binaries that are available.

If you are just running the scripts they return, you really will have to just try them all.

Often they generate a lot of noise you need to fine tune. Wherever possible it is better to do a more targeted, manual, assessment so you can get to the vulnerability you want to use, rather than have every possible suggestion.

As for specific questions (In a different order though)

And why did windows-exploit-suggester give so many false positives??

Because it is making suggestions. It is saying “this exploit might be possible” based on whatever the search string is using. It wont test them for you to see if they work.

Often it is as simple as saying “version X of software is running, here are the vulnerabilities for that version” - some will be patched, some will be down to configuration choices, some will be protected by compensating controls, etc.

And…can you ever be sure these are all false positives???

No.

So my question is, what is your methodology in this situation?

Look at the results and decide which one is most likely to work, then work through the list to the one which looks least likely. There isn’t a magic short cut.

Sometimes you can discount some suggestions because they clearly wont work - for example they have a dependency you cant meet.

Using @0xdf’s great walkthrough as an example. Early on, the Searchsploit returns:

Microsoft IIS 4.0/5.0/6.0 - Internal IP Address/Internal Network Name Disclosure                               | windows/remote/21057.txt
Microsoft IIS 5.0/6.0 FTP Server (Windows 2000) - Remote Stack Overflow                                        | windows/remote/9541.pl
Microsoft IIS 5.0/6.0 FTP Server - Stack Exhaustion Denial of Service                                          | windows/dos/9587.txt
Microsoft IIS 6.0 - '/AUX / '.aspx' Remote Denial of Service                                                   | windows/dos/3965.pl
Microsoft IIS 6.0 - ASP Stack Overflow Stack Exhaustion (Denial of Service) (MS10-065)                         | windows/dos/15167.txt
Microsoft IIS 6.0 - WebDAV 'ScStoragePathFromUrl' Remote Buffer Overflow                                       | windows/remote/41738.py
Microsoft IIS 6.0 - WebDAV Remote Authentication Bypass (1)                                                    | windows/remote/8704.txt
Microsoft IIS 6.0 - WebDAV Remote Authentication Bypass (2)                                                    | windows/remote/8806.pl
Microsoft IIS 6.0 - WebDAV Remote Authentication Bypass (Patch)                                                | windows/remote/8754.patch
Microsoft IIS 6.0 - WebDAV Remote Authentication Bypass (PHP)                                                  | windows/remote/8765.php
Microsoft IIS 6.0/7.5 (+ PHP) - Multiple Vulnerabilities                                                       | windows/remote/19033.txt

You can probably eliminate the three DOS attacks as out of scope, the internal address/name disclosure as not helpful, which leaves 7. You might decide the FTP one isn’t relevant because we only have port 80 open.

This leaves the WebDAV attacks. Next, you could have a quick read of the exploit to see which is likely to be useful.

Sometimes you will need to read them all, and the links, to have an idea of what will work - but in the long term this is better than just working through the list, trying the exploits and hoping something will work. Apart from anything else, you need to know if it doesn’t work, why it didn’t work.

What if you didn’t see the churrasco route, wouldn’t the only option be to try harder by climbing down that rabbit hole a second time looking for something other than rabbits??

Well, what you are really asking is if you don’t find the correct route what options do you have? And really the answer is to just keep trying or give up.

If it is a CTF and you know there is going to be a vulnerability, then it is probably best to keep trying because there is a way in. Going back to @0xdf, there is a fairly good explanation of how the massive list is whittled down.

This is why people get better with practice. When you’ve done a lot of windows boxes, you will be used to the Potato exploits, although admittedly you’d need to do really old ones for Churrasco to spring to mind early on. You can’t shortcut experience.

If it is a real-world pentest, then it is slightly different in that you eventually run out of time so you have to decide early on when you should decide “it cant be done” and move on.

tl;dr - practice really helps because there isn’t a way to automate the detection well enough that you wont have a lot of false positives.

4

Everything you two said makes a lot of sense, thanks! I knew to whittle down the possibilities by disregarding things like DOS, but I never thought about disregarding things like IE, FTP, IP enum, etc. I’ll start giving the descriptions a closer read. Going beyond the descriptions and into the details of the exploit code seems to be the trick, I’m just not experienced enough yet to know if it’ll work without elaborate comments.

I’ve started to notice that google pretty consistently helps sort these possibilities. For example simple searching for “[OS version] privilege escalation”, or “[service version] exploit github” seems to give a workable exploit within the top 3 links. I almost feel like I’m cheating when I’m using google instead of searchsploit or windows-exploit-suggester, but as long as I don’t click on anything that mentions the machine i’m working on I feel a bit better about it. I still feel like getting working results at the top of google isn’t totally realistic since so many people on hack the box have looked for these exact same exploits and have even developed their own exploits knowing others will be looking for it…but google is an essential tool for pentesting, so I think I need to start using it more.

So to summarize, it seems like trial and error is the only way, but you can make this method more efficient by spending a bit of time deciding which trials are most likely to succeed by looking at the exploit names, the exploit code, and cross referencing your list with google to help sort which to try first, while potentially adding some more possibilities to the mix that your original search may have missed.

5

@ZanderC137 said:

I’m just not experienced enough yet to know if it’ll work without elaborate comments.

It will come with time. No one was born knowing this stuff, and while it might seem like some people magically know the right exploit, it nearly always means they’ve seen it a few times before and make many mistakes about it in the past.

I almost feel like I’m cheating when I’m using google instead of searchsploit or windows-exploit-suggester,

I get what you mean but try not to think like this. Cheating is a very vague concept in all this. Some people will find suitable exploits manually, some will use *-exploit-suggester, some will google across exploit DB etc.

At the end of the day your brain has a finite ability to store and retain data, while the available information grows constantly. Using google (or any other search engine) to index the data for you, isn’t cheating.

You wouldn’t think it was sensible to try and memorise the location of every book in a library rather than the index.

The key is asking yourself - did you learn something from the box and did you have fun. If you can answer yes to at least one, then its all good (IMHO).

So to summarize, it seems like trial and error is the only way, but you can make this method more efficient by spending a bit of time deciding which trials are most likely to succeed by looking at the exploit names, the exploit code, and cross referencing your list with google to help sort which to try first, while potentially adding some more possibilities to the mix that your original search may have missed.

Good summary. A huge amount of infosec testing is driven by things we dont want to really admit is basically guesswork. We use terms like fuzzing or enumeration to mean we are just trying things to see what happens.

The real art of pentesting is being able to narrow it all down so that your “trial and error” is quick and efficient. We recognise this at some simple levels - you don’t try Linux/Apache attacks on a Windows/IIS server for example - it’s just a matter of recognising that deep down, it’s all like that.

A good example is a lot of bug bounty work. No one knows beforehand what will happen. The process is broadly read/explore the application, find things it claims to do, test the claims and move on. Eventually, you find a claim which isn’t true and get a working exploit. Or you don’t and you move on to a different application.