Image
 
linkedin_logo.png rss_logo.jpg
twitter_logo.png youtube_logo.jpg
Latest Additions
 
EH-Net Login
Welcome Guest.






Lost Password?
No account yet? Register
Who's Online
We have 44 guests and 2 members online
 
Advertisement

You are here: Home arrow Ethical Hacking Discussions and Related Certificationsarrow Network Pen Testingarrow Common vulnerabilities you expose during engagements
EH-Net
May 22, 2013, 06:55:48 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Go back to The Ethical Hacker Network Online Magazine Home Page
 
   Home   Help Calendar Login Register  
Pages: [1]   Go Down
  Print  
Author Topic: Common vulnerabilities you expose during engagements  (Read 1345 times)
0 Members and 1 Guest are viewing this topic.
cb122
Newbie
*
Offline Offline

Posts: 20


View Profile
« on: March 14, 2013, 06:23:24 AM »

When you conduct your network security assessments for your clients, are there any very common security weaknesses you come across in most of your client networks? I always find it intriguing to gauge the common sorts of security issues found in most networks. I’d hazard a guess that most serious network administrators will proactively run vulnerability assessment tools themselves, prior (and ideally on regular schedules) to an external security firm coming in and doing their independent there review. I just wondered if there are common security issues and vulnerabilities you come up against again and again in your reviews? Any tales and feedback most welcome.
Thanks
Logged
ajohnson
Recruiters
Hero Member
*
Offline Offline

Posts: 1057


aka dynamik


View Profile WWW
« Reply #1 on: March 14, 2013, 07:20:34 AM »

  • Blank/Weak admin creds for SQL Server and Tomcat
  • Still regularly see MS08-67 and NT4
  • MitM attacks - ARP poisoning, name response spoofing, etc.
  • Default credentials on web apps and devices
  • Tons of random third-party applications that fall through the patching cracks
  • VxWorks Memory disclosure is on about half of the assessments I do

I need to get going for my flight, but those are the ones that come to mind when I think of what I see over and over and over and over.
Logged

WIP: GCFA | www.infosiege.net | @infosiege

The day you stop learning is the day you start becoming obsolete.
ziggy_567
Sr. Member
****
Offline Offline

Posts: 361


View Profile
« Reply #2 on: March 14, 2013, 08:20:49 AM »

SSL issues are very common as well. They're not super-sexy, remotely exploitable....but there still out there.
Logged

--
Ziggy


eCPPT - GSEC - GCIH - GCUX - RHCE - SCSecA - Security+ - Network+
cd1zz
Hero Member
*****
Offline Offline

Posts: 561


View Profile WWW
« Reply #3 on: March 14, 2013, 08:45:41 AM »

What AJ said but in addition:

 - Sync'd local admin pws
 - Lots of LM hashing in use
 - Tons of exposed 445 on EVERYTHING which makes PTH and psexec possible

Logged

BillV
Hero Member
*****
Offline Offline

Posts: 1892


View Profile WWW
« Reply #4 on: March 14, 2013, 09:33:01 AM »

Same as each of those guys above have said, lots of it. Couple more...

- We commonly see default DRAC credentials in larger environments.
- Default SNMP strings (public and private)
- Open network shares with sensitive information
- Unauthenticated VNC
- Insecure protocols (clear text... telnet, ftp, r stuff)
Logged
hayabusa
Hero Member
*****
Offline Offline

Posts: 1632



View Profile
« Reply #5 on: March 14, 2013, 10:05:07 AM »

Another one I've seen quite frequently, lately, is WSDL issues

- information disclosure, up to and including full LDAP administrative credentials and passwords from a WSDL request that wasn't made unavailable to 'joe average user'
Logged

~ hayabusa ~ 

"All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." - Sun Tzu, 'The Art of War'


OSCE, OSCP , GPEN, C|EH
r0ckm4n
Jr. Member
**
Offline Offline

Posts: 74


View Profile
« Reply #6 on: March 14, 2013, 10:24:03 AM »

Another one I've seen quite frequently, lately, is WSDL issues

- information disclosure, up to and including full LDAP administrative credentials and passwords from a WSDL request that wasn't made unavailable to 'joe average user'

Speaking of WSDL, here's an article about using a Burp WSDL plugin; http://www.netspi.com/blog/2013/03/05/hacking-web-services-with-burp/
Logged

CISSP, IAM, working on OSCP
cd1zz
Hero Member
*****
Offline Offline

Posts: 561


View Profile WWW
« Reply #7 on: March 14, 2013, 10:55:07 AM »

Weak passwords have already been mentioned.... I have pretty good success taking about 10 common passwords and spraying them across ALL the services I discover. Vmware, vnc, SMB, telnet, ssh.... everything.... In large environments, I usually hit at least one, which is typically the first step in total pwnag3 because of all the stuff already mentioned. Defense is hard. Glad I'm on offense.
Logged

ajohnson
Recruiters
Hero Member
*
Offline Offline

Posts: 1057


aka dynamik


View Profile WWW
« Reply #8 on: March 14, 2013, 05:26:07 PM »

What AJ said but in addition:

 - Sync'd local admin pws
 - Lots of LM hashing in use
 - Tons of exposed 445 on EVERYTHING which makes PTH and psexec possible



There's a group policy that disallows network authentication for the local users specified. We typically make organization's roll that out after we've run a train on them using those techniques. It ruins everything for us or whoever the next year, but it's simple and effective. Disallowing delegation for privileged accounts is huge too.

Another fun one is if they're setting the local admin's password via group policy preferences and you get a standard domain user account. You can read the groups.xml on the domain controller and there are scripts floating around that'll decrypt the encrypted password in it because Microsoft disclosed the key they used.

Edit: http://carnal0wnage.attackresearch.com/2012/10/group-policy-preferences-and-getting.html
« Last Edit: March 14, 2013, 05:35:07 PM by ajohnson » Logged

WIP: GCFA | www.infosiege.net | @infosiege

The day you stop learning is the day you start becoming obsolete.
cd1zz
Hero Member
*****
Offline Offline

Posts: 561


View Profile WWW
« Reply #9 on: March 14, 2013, 07:30:27 PM »

That's a cool idea and I think that would work well with what I usually recommend.... which is to implement GPO based FWs and block 445 inbound, except from a jump box or from a small subnet of IPs.

I know 445 can also be used for installing software remotely, but again, that could be accomplished by only allowing inbound 445 from a subset of the network/jump box.

I was recently at a client that implemented something really cool called CyberArk, ever heard of it? It changes the local admin passwords to crazy random passwords, every hour! It keeps track of all of them and allows SSO through the CyberArk. Bad ass!

Logged

cb122
Newbie
*
Offline Offline

Posts: 20


View Profile
« Reply #10 on: March 15, 2013, 07:31:25 AM »

Many thanks to you all.
Logged
ajohnson
Recruiters
Hero Member
*
Offline Offline

Posts: 1057


aka dynamik


View Profile WWW
« Reply #11 on: March 15, 2013, 09:57:30 AM »

That's a cool idea and I think that would work well with what I usually recommend.... which is to implement GPO based FWs and block 445 inbound, except from a jump box or from a small subnet of IPs.

I know 445 can also be used for installing software remotely, but again, that could be accomplished by only allowing inbound 445 from a subset of the network/jump box.

I've personally had a difficult time getting people to implement client-side firewall changes. There's always a ton of push-back. I don't know if the sys admins just aren't as comfortable on the network side or what the deal is, but something that should be simple always seems to break everything. That's definitely a good strategy when implemented properly though.

With the network logon GPO, there's a corresponding one that disallows RDP for specified users, which is necessary since that's treated as an interactive logon, not a network logon. On the attacking side, that obviously requires cracking the hash instead of passing it, but it's not like that doesn't happen frequently Smiley Again, disabling the service or client-side firewalls could address that as well. I guess a blanket GPO is a good safety net.

I was recently at a client that implemented something really cool called CyberArk, ever heard of it? It changes the local admin passwords to crazy random passwords, every hour! It keeps track of all of them and allows SSO through the CyberArk. Bad ass!

I've never used it personally, but it's one I suggest be researched for anyone looking at enterprise password management. I saw one that did something similar, but it only changed after it was checked out by a user, effectively providing one-time passwords. The ManageEngine utility looks promising too. It even supports multi-factor, so you need a phone or RSA token in order to check out passwords.
Logged

WIP: GCFA | www.infosiege.net | @infosiege

The day you stop learning is the day you start becoming obsolete.
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines
Joomla Bridge by JoomlaHacks.com
Valid XHTML 1.0! Valid CSS!
Page created in 0.068 seconds with 23 queries.
 
Exclusive Deal

sansfire13_245x90_cw90.jpg
SANSFIRE 2013
June 15 - 22

5% Off w/ Code: EHN_5

SANS Deals 4 EH-Netters
5% OFF Any SANS Course in Any Format!
Coupon Code: EHN_5 Including SANS Rocky Mountain 2013 & SANS Boston 2013
Polls
Compared to this year, 2013 will be:
 
Recent Forum Topics
EH-Net News Feeds
Latest Additions
 
         
Advertisement

© 2013 The Ethical Hacker Network
Joomla! is Free Software released under the GNU/GPL License.