It has been a long time since I posted something here. I apologize if someone was expecting me to. Anyways, the only reason why I came back is because I'd like to share an approach to external testing that I believe not a lot of people are exploiting. I might be wrong but at this time I haven't seen anything or anyone talking about this, at least from the Internet (internally everybody is doing this). The other reason why I want to share this is because I have found a number of companies having the same issue. Is not a technology / vendor issue per se. It is just a bad design and implementation in the way corporate tools such as webmail, web VPNs, or self password recovery apps are used without thinking of the potential risk that the company might face when things are looked from a ten thousand feet view and later zoomed into the details. Lastly, I was hoping to show this to a broader audience at Defcon or Blackhat but my idea / topic was not accepted :'( so I will just post it in here as a personal reference or for the few that read this or know me.
OK.
Here it goes.
The external (Internet) attack surface has consistently been
reduced with the pass of time and little by little it becomes harder for
attackers (or at least for me) to compromise companies without the use of social engineering. However, I think in the past years companies also lost focus in understanding basic
security concepts such as authentication, identification and authorization and didn't focus on fixing the root cause of their security issues.
This, in conjunction with the heavy reliance of testers and companies on
security tools and the need of companies to reduce cost and automate processes to
allow remote connectivity to a wide range of users, have put large companies
into difficult situations to protect every avenue that an attacker could exploit
from the outside. I will explain what I mean with this in the next paragraphs.
For the last years I have used an avenue to get into a good percentage of companies from the Internet and transform external penetration tests into internal. This avenue is not new to anyone, actually is widely used during internal pentests, but I believe it is not exploited externally most of the time due to the complexity of technologies allowing remote access and lack of tools that will help exploit this issue. I am talking about lack of two factor authentication and use of easy to guess passwords. Yes use of passwords... I know it sounds stupid but keep up with me. Most of the large companies I know are all using Single Sign On solutions where users are managed in a centralized repository using the Active Directory or an Identity Management System (IDM) linked to it. The main purpose of this is simplifying the user management process that for the most part is a pain in the ass for all companies. If we keep looking at this trend the other thing that IT is focusing on usually is "user experience". This basically means that if I have an employee that wants to login into an application, it doesn't matter if it is external or internal, he or she should use their corporate user account to do so. This creates a whole new problem for companies since some of the external applications are also used by third parties like contractors, government entities or other companies who have deals with the organization. This opens an avenue for hackers to try compromise companies from the outside. If we assume that in a large corporation they have around 100 external functional websites exposed to the internet and some of them are linked to the corporate (internal) user repository (AD). We can easily conclude that a web application vulnerability in one of these applications might lead to a bigger issue if the attacker is able to compromise a valid user account. Now, the other interesting piece would be how companies are managing remote access to sensitive information or internal resources such as email, corporate applications or other systems that might be considered critical to the business. What I have seen, is that organizations have to expose part of their infrastructure to the Internet weather they like it or not. It is just a business need. Some companies expose part of their PeopleSoft or SAP systems because everything is centralized in there. Other companies have to allow VPN access to contractors so they can login to an application they don't want o expose on the internet. Whatever the case might be, the vast majority of companies will have on the Internet the corporate web email, some kind of remote access capability (VPN), external web applications linked to internal applications and, if we are lucky, a password reset application (self service tool) that will allow a remote user to change their corporate password. At the same time two factor authentication is expensive, hard to setup and not widely implemented in all applications.
After that long explanation / introduction of the trends in most large companies here is where I am going with all this. We use these applications on a day by day basis without asking ourselves if they should work like this or not. Applications such as web mail, web vpn, and other remote connectivity apps do not handle the scenario where someone is testing user accounts all the time until he or she successfully gets in. Yes, there are lockout policies in the Active Directory (AD) that will not allow someone to test a user more than a number of times but there are ways around this too.
Before I start, please keep in mind that what I explain in here is just one piece, Anyone testing externally the infrastructure of a company should test for all types of vulnerabilities and not only one. However, it is always good to have a tool that you can leave running while you look manually for other vulns. Anyways... the approach that I follow to exploit this issue, bad design or however you want to call it is based on two steps: user enumeration or user predictability and brute force. Nothing new to anyone so here it goes. Every time I perform an external pentest I perform discovery of their applications, identify the ranges and understand what is connected with what. For example, I try to identify all the web applications that belong to the company and later see if there seem to be any applications that are linked to the AD. How can you test this? Well, the other thing that I do is an analysis of documents' metadata using FOCA. This can be accomplished with a number of tools but I like FOCA and the results it returns. This will allow me to gather at the very least one or two valid internal user accounts. Once I have these user accounts two things come out of this: first, I know the user structure and second, I have user accounts that I can test on applications that have password rest capabilities and see if they are valid or not. Basically, I will try the user accounts I gathered with FOCA on any external application identified with a user enumeration issues looking for some link to the internal Active Directory. If they have user enumeration and is linked to the AD I will enumerate a many users as possible obviously assuming the app doesn't send emails to the valid users (remember we also know the user name structure). Once I have a number of user accounts (around 1000) that I feel are valid on the internal Active Directory I would look for remote jumps to internal information. Web VPNs, Citrix servers, web mail servers, etc. Anything that allows me to get inside the corporate network from the Internet and obtain access to internal resources. Once I have all those pages I use the ones that don't support two factor to brute force users and passwords. However I don't brute force each user with several passwords but I gather all the users and test only one password on all of them. The reason for this is to avoid locking out accounts and increases the probability of getting on valid internal user account. Simple, right? So three easy steps:
Logical Chaos
The tool can be downloaded on my github here. I believe it is well documented and if you understand that the final purpose of this tool is to test several user accounts with only one or two passwords everything should be kind of straight forward.
The recommended way of using the brute force modules, as mentioned before, is to test several users at a time with one password and wait at least one day to test the next password. The reason for this is to avoid locking out Active Directory users, allowing them to login the next day and reset the lockout count. The main idea of this tool is to test for weak passwords during the night while you look for other vulnerabilities like SQLi, XXS, CSRF, file inclusions, etc. The good news is that is you get one user you probably will be able to compromise some important information. Please think what you do before doing so and don't blame the tools if you mess up something.
I honestly hope this helps someone and provides some kind of perspective on how some companies can improve their security by pushing vendors to improve the way their tools / appliances / applications work. That is the only reason why I am making this public anyways...
Special thanks to:
ET - @etlow for all the help and guidance through the years.
@facon_lownoise - for all the comments on the tool and being the first beta tester
After that long explanation / introduction of the trends in most large companies here is where I am going with all this. We use these applications on a day by day basis without asking ourselves if they should work like this or not. Applications such as web mail, web vpn, and other remote connectivity apps do not handle the scenario where someone is testing user accounts all the time until he or she successfully gets in. Yes, there are lockout policies in the Active Directory (AD) that will not allow someone to test a user more than a number of times but there are ways around this too.
Before I start, please keep in mind that what I explain in here is just one piece, Anyone testing externally the infrastructure of a company should test for all types of vulnerabilities and not only one. However, it is always good to have a tool that you can leave running while you look manually for other vulns. Anyways... the approach that I follow to exploit this issue, bad design or however you want to call it is based on two steps: user enumeration or user predictability and brute force. Nothing new to anyone so here it goes. Every time I perform an external pentest I perform discovery of their applications, identify the ranges and understand what is connected with what. For example, I try to identify all the web applications that belong to the company and later see if there seem to be any applications that are linked to the AD. How can you test this? Well, the other thing that I do is an analysis of documents' metadata using FOCA. This can be accomplished with a number of tools but I like FOCA and the results it returns. This will allow me to gather at the very least one or two valid internal user accounts. Once I have these user accounts two things come out of this: first, I know the user structure and second, I have user accounts that I can test on applications that have password rest capabilities and see if they are valid or not. Basically, I will try the user accounts I gathered with FOCA on any external application identified with a user enumeration issues looking for some link to the internal Active Directory. If they have user enumeration and is linked to the AD I will enumerate a many users as possible obviously assuming the app doesn't send emails to the valid users (remember we also know the user name structure). Once I have a number of user accounts (around 1000) that I feel are valid on the internal Active Directory I would look for remote jumps to internal information. Web VPNs, Citrix servers, web mail servers, etc. Anything that allows me to get inside the corporate network from the Internet and obtain access to internal resources. Once I have all those pages I use the ones that don't support two factor to brute force users and passwords. However I don't brute force each user with several passwords but I gather all the users and test only one password on all of them. The reason for this is to avoid locking out accounts and increases the probability of getting on valid internal user account. Simple, right? So three easy steps:
- Gather information and espeially user accounts
- Enumerate as much users as possible
- Bruteforce those user accounts with one or two passwords at the most while waiting for the lockout count resets itself after the users logins
Logical Chaos
The tool can be downloaded on my github here. I believe it is well documented and if you understand that the final purpose of this tool is to test several user accounts with only one or two passwords everything should be kind of straight forward.
- Enumerate
- QPM - Quest Pasword Manager. This is an amazing way of enumerate users. The tool is configured to use the application to enumerate as many users as possible and uses a logical flaw in the way captchas are configured to enumerate all possible users. This can be accomplished by using the search functionality of the Quest Password Manager (when available) or by just guessing users based on the user name structure. For example, jsmith, john.smith, etc.
- Captchas - If captchas are enabled the tool is programmed to detect them and wait for the user to manually input the first set of captchas. Once captchas are provided through the browser QPM will assign a cookie that will allow anyone to enumerate users without captchas. The reason why this tools has to be used to do this is because this process has to be done through the browser. Also, QPM is heavy on java script and sometimes is diffucilt to interpret the results by going through a web proxy. That said, I am sure that there are ways around this however to me it was simpler to develop this that to repeat a complex process every time I faced this application (QPM)
- Bruteforce - all modules are pretty straight forward. The tool uses the browser to appear a real user and avoid dynamic cookies and heavy java script pages that will be a mess to test through a proxy. The one that I feel is the coolest of these ones and a little but different is the RSA SecureID selfservice module. This one goes through the process and obviously if one user gets compromised using this app then you can even obtain a new temporary token ;) Anyways, I will let you try it if you are interested
- XenApp – A.K.A Citrix Metaframe
- Citrix vpn
- Outlook Web mail
- Web Forefront access
- Cisco Web VPN
- Juniper Web VPN
- PeopleSoft
- RSA SecureID selfservice
- Automated
The recommended way of using the brute force modules, as mentioned before, is to test several users at a time with one password and wait at least one day to test the next password. The reason for this is to avoid locking out Active Directory users, allowing them to login the next day and reset the lockout count. The main idea of this tool is to test for weak passwords during the night while you look for other vulnerabilities like SQLi, XXS, CSRF, file inclusions, etc. The good news is that is you get one user you probably will be able to compromise some important information. Please think what you do before doing so and don't blame the tools if you mess up something.
I honestly hope this helps someone and provides some kind of perspective on how some companies can improve their security by pushing vendors to improve the way their tools / appliances / applications work. That is the only reason why I am making this public anyways...
Special thanks to:
ET - @etlow for all the help and guidance through the years.
@facon_lownoise - for all the comments on the tool and being the first beta tester
No comments:
Post a Comment