Internal pen test

<<

ccpik

User avatar

Newbie
Newbie

Posts: 20

Joined: Fri Nov 29, 2013 6:41 am

Post Sat Apr 05, 2014 4:49 pm

Internal pen test

*Microsoft IIS 7.5*
*Microsoft Exchange 2007-2008*

I have had some excellent advice thus far on this forum, so I thought I would seek some help on my next question! :)

I have discovered a couple of services that stand out to me, but wanted some input from you guys. I have checked vulnerability databases and the obvious choice is IIS 7.5 out of the two. However, if you were doing a full penetration test for a client and came across these two applications, what would be your plan of exploitation and how would you fancy you chances of actually being successful?

Literally any advice would be helpful
<<

SephStorm

User avatar

Hero Member
Hero Member

Posts: 621

Joined: Sat Apr 17, 2010 12:12 pm

Post Sun Apr 06, 2014 5:34 am

Re: Internal pen test

Hi,

Depends on the rules of engagement, and the type of assessment you are running. Assuming everything is good to go, my first instinct would be IIS. There are at least some vulnerabilities for IIS.
http://www.osvdb.org/83771
http://osvdb.org/show/osvdb/82848

Of course those could be patched. I don't hear much about exchange vulnerabilities in general, But I assume they are out there.
sectestanalysis.blogspot.com/‎
<<

ccpik1

Newbie
Newbie

Posts: 12

Joined: Fri Nov 29, 2013 8:59 am

Location: North West

Post Sun Apr 06, 2014 12:01 pm

Re: Internal pen test

Thank you. I will be reading up on the ones you mentioned, and if I feel confident enough understanding exactly how it can be replicated I'll have a go
<<

dynamik

Recruiters
Recruiters

Posts: 1134

Joined: Sun Nov 09, 2008 11:00 am

Location: Mile High City

Post Sun Apr 06, 2014 11:35 pm

Re: Internal pen test

You're going to have far more luck going after the applications and not the servers. See what email addresses you can scrape together and try some password guessing attacks on Exchange. See what content the web server is actually hosting and try attacking that. Do some recon and see if you can find valid credentials, run DirBuster to find web server additional content, etc.
The day you stop learning is the day you start becoming obsolete.
<<

ccpik

User avatar

Newbie
Newbie

Posts: 20

Joined: Fri Nov 29, 2013 6:41 am

Post Wed Apr 09, 2014 2:22 pm

Re: Internal pen test

Thank you, I used dirbuster and analysed the results from the 5 different servers I am testing.

I discovered Tomcat 5.0.28 and also PHP running (PHP appeared to be patched). Whilst running dirbuster it showed a few error 200's to file locations, but when I try to access them I get 'you do not have the required permissions etc'.

In regards to discovering what other applications are running all I could find where default login pages. Web pen testing was never my strong point so struggling where to go next with this.

Apart from going down the brute forcing route for the login pages I am not sure what else I can go at. There are no other pages on these servers visible. Any advice or pointers?
<<

SephStorm

User avatar

Hero Member
Hero Member

Posts: 621

Joined: Sat Apr 17, 2010 12:12 pm

Post Wed Apr 09, 2014 5:59 pm

Re: Internal pen test

Are you working alone or as part of a team?
sectestanalysis.blogspot.com/‎
<<

ccpik

User avatar

Newbie
Newbie

Posts: 20

Joined: Fri Nov 29, 2013 6:41 am

Post Thu Apr 10, 2014 6:27 am

Re: Internal pen test

On my own with this project
<<

dynamik

Recruiters
Recruiters

Posts: 1134

Joined: Sun Nov 09, 2008 11:00 am

Location: Mile High City

Post Sat Apr 12, 2014 2:23 pm

Re: Internal pen test

Sometimes engagements are scoped in a manner that result in a very small attack surface. This is frequently the case with small external engagements that do not allow authenticated testing or social engineering. You're not doing a poor job just because you don't have a Microsoft 0-day or can't get past a login page.

That said, there are still some other things you can do:
See if the manager functionality is accessible for Tomcat. That's sometime configured with weak credentials (i.e. admin/admin, tomcat/admin, tomcat/tomcat), etc. It's also another target for advanced password-guessing attacks. This can be significant because you can upload your own WAR file to get a web shell. This service is often running as SYSTEM on Windows, and I have also seen it as root on *nix systems (though I do not believe this is the default configuration).

There is a Metasploit module that will automate this if you have valid manager credentials, but I think AV will often snag the WAR they use nowadays. There are tons of other web shells floating around, and it's trivial to install these in Tomcat manually (just "deploy new" and select your WAR). http://laudanum.inguardians.com/ is a great collection, though I have had that fail occasionally as well. Again, possibly because of AV. You can find another one or just make your own. WARs are essentially just zipped JSP, and you can make a custom JSP shell and turn it into a WAR with just a few Google queries.

Additionally, that's a very old version of Tomcat: http://tomcat.apache.org/whichversion.html (I'm assuming "archived" means it's no longer maintained). That service itself might actually be exploitable: http://www.exploit-db.com/search/?actio ... ion=tomcat Even if you don't get anywhere with this, you should note that they're not properly keeping their perimeter services on supported platforms or patching them. Version 5 went into 5.5.x, so 5.0.28 is really old even for v5 itself.

It depends on how the engagement was scoped, but you could ask for a basic user account to poke around the web application(s) from an authenticated perspective. That will open the doors for you significantly.

If not, your options basically come down to circumventing the login/authentication mechanism or finding content you can directly access without authenticating. You could try using tailored wordlists with DirBuster. Use cewl (http://www.digininja.org/projects/cewl.php - also in Kali) to scrape the company website and/or product/service page to make a custom wordlist, which may be more successful in identifying content than generic ones.

Try different extensions as well. Don't just go with php because it's running PHP. Try txt, html, bak, old, zip, etc. https://github.com/digination/dirbuster ... /wordlists is a good resource for this. Check out all of them, but mutations_common.txt is the one that contains various extensions that might be worthwhile (also checkout vunls > tomcat for the server itself).

More often than not, this won't go anywhere, but you can also get really lucky with it. index.php.old might render as text and give you some insight into the login mechanism or other functionality, and backup.zip would likely be a huge win as well. We've found huge dumps of SSNs with just the txt check before. Remember that each extension is another pass through your wordlist, so you need to be a lot smarter with that. Even the medium wordlist will take forever, so you have to customize this, or you'll never get through all the extensions you specify.

Targeting specific directories will also help you make the most of your time. I’d hit something like /backup/ really hard while not wasting my time iterating through /docs/, /docs/en/, /docs/es/, /docs/jp/, etc. Don’t waste time doing something like fuzzing the web server’s documentation contents.

As I mentioned before, you don't have much of an attack web surface with just a login page, but that also makes it imperative that you don't miss anything obvious. You're never going to identify every issue when assessing a large application, but it would be extremely embarrassing if you miss SQLi auth bypass on a login form.

SQLi is the obvious attack vector here. Try some manual attempts and see if anything jumps out at you, and try using sqlmap to identify some less-obvious issues. Also load up Burp and take a look at the requests and responses that are going back-and-forth. Make sure you can't do something like bypass authentication simply by changing loggedin=0 to 1.

Does the login functionality disclose any information? Does it provide differential responses based on whether the username is valid? Try usernames based on what you've gather from recon as well as common ones like admin, administrator, test, etc. Are the responses the same or different compared to a username you made by just mashing on the keyboard?

If you can identify a difference anyway (maybe as little as "Invalid username or password" and "Invalid username or password."), you can enumerate valid users. Also check password reset functionality. Sometimes they properly provide a generic error message for failed logins, but you may find the password reset functionality will tell you whether or not the account is valid (as opposed to simply stating something like "An email has been sent to the address on file for that account" regardless of the account validity).

Also test for controls that throttle or limit automated password guessing attacks. Do you get a 5 minute delay or a CAPTCHA after a certain number of invalid logins, or can you pound on them all day? If there is some mitigating functionality in place, does it work by source IP or the username? Maybe they'll temporarily lock an account after a certain number of failures, but what happens if you iterate through users for each password instead of iterating through passwords for a single user. If there isn't any mitigating functionality, did anyone notice an enormous amount of failed logins in whatever logging/SIEM solution they have, or is no one really looking at that information?

Even if you don't get in, identifying areas where they could improve will help you add value to the report. These types of engagements can be extremely boring, but at the same time, I've never been unable to at least make a few recommendations.
The day you stop learning is the day you start becoming obsolete.
<<

ccpik

User avatar

Newbie
Newbie

Posts: 20

Joined: Fri Nov 29, 2013 6:41 am

Post Mon May 05, 2014 12:23 pm

Re: Internal pen test

Just a quick update after the extremely helpful reply. I tried dirbuster and also cewl but to no avail. I also tested the web facing login pages for XSS and SQL vulnerabilities in case I missed something obvious. Literally hit a brick wall with this, I'm sure someone with more expertise could probably find a way in, but unfortunately for me I can't see myself finding a hole.

One positive however, was the next day post exploitation attempts going into the office and looking at all the firewall logs to see what was being blocked and what was not! So was a good learning curve even if it was not a successful final outcome
<<

SephStorm

User avatar

Hero Member
Hero Member

Posts: 621

Joined: Sat Apr 17, 2010 12:12 pm

Post Wed May 07, 2014 9:59 pm

Re: Internal pen test

Glad to hear it!
sectestanalysis.blogspot.com/‎

Return to Network Pen Testing

Who is online

Users browsing this forum: No registered users and 1 guest

Powered by phpBB® Forum Software © phpBB Group.
Designed by ST Software