Penetration testing and site security
Greetings everyone!
While botnet research is fun and rewarding, it doesn't always pay the mortgage. Those who pay well don't enjoy having research aired in public - hence the lack of postings lately.
I figured some regular readers might be interested in what I've been up to. At the same time, I hope to create a good set of notes for an educational presentation I hope to give in a few months. This post should be generic enough to keep both my readers and employers happy.
My most recent projects have been penetration testing. I've done projects like this before, but never this massive. Its almost like everyone has suddenly realized how important computer security is - or maybe they're worried that with school letting out - all of the script kiddies are going to start hitting their sites.
It would be morally and ethically wrong to disclose any data related to this type of research/project, but I figured I'd post some things for everyone to think about while coding, performing your own pentests or generally (legally) messing around.
If you haven't done so, I recommend visiting Hack This Site. Hack This Site has several safe hacking games to play. While they are all fiction, some of the tactics will actually work in a real scenario. More importantly, you can enjoy an evening or two of goofing around without actually causing yourself or anyone else any harm.
Penetration Testing is not a skill set. Its not something that can be taught. All it requires is an open mind. You must think about things differently than other people. You must be willing to experiment without being afraid of your self. You must be disciplined enough to know not to use your knowledge with malicious intent. You should not share your research with anyone but your employer. Let your employer submit bug reports to vendors. This type of research is simply a behind the scenes job. If you just want your name in lights at Defcon, this isn't the job for you. You'll get about as much respect publishing exploits as you would by having your credentials on the wall of sheep.
The following techniques I am going to outline can be used for malicious intent. I'm fully aware of that. You should be aware that you will be caught if you try to use them. You may not get caught your first time, but trust me you will get caught eventually. Visit the hacking challenge sites and stay away from temptation. You'll find life is so much more rewarding when you can do what you love legally and without suspicion.
Before a pentest, right after I get the scope and required documentation signed, I perform a little recon. I use free search engines like Google and Maltego.
I search for news group postings to or from people who have email accounts on the target domain. I read every email and learn as much as I can about my target. Email postings provide a wealth of information. In email headers you can see internal IPs for businesses and residential IPs for employees. You can likely see what email or web client they use, and that will lead you to which operating system they run.
Some businesses let their employees use instant messengers and IRC. These point to weak security practices that are helpful later in the pentest.
Using Google I search for website issues like SQL injection. Example searches could include:
Acting as a normal website visitor I will carefully search pages for locations that might be vulnerable to Cross Site Scripting and SQL injection. This is just about anywhere a clients browser can send data to the server. I note all of this for the actual pentest day, when I can try fuzzing fields.
That includes the pull down menus and input fields. With all of my searches I make sure to view the source code on each and every page. I look for comments that may have been left by developers. I'm looking for unused include scripts, insider data overlooked, and believe it or not, usernames and passwords.
I watch the server headers, and try to identify the web server and operating system. I pay special attention to internal IP addresses and cookies. In one penetration test a cookie was simply a base64 encoded IP address - that IP address was the internal IP for the server.
I DIG the target DNS server for obvious sub domains,
In reality I simply run a recon script which gathers most of this data for me. I am working several projects at once, and need to spend my time wisely.
The night before I am scheduled to begin testing my target, I go over all the data I have gathered. I prefer to go over it just before I go to sleep. I come up with my best work while I'm asleep.
Depending on the scope of the test I may start a slow nmap scan of the host. By using the -T0 or -T1 flag I can evade most IDS systems. I start up these scans before even taking my morning shower or grabbing breakfast. They take a very long time to complete, and I don't want to waste a minute of that time.
I have several IPs at my disposal - for cases when an IPS catches me. Since I have these IPs, I'm also able to distribute my attacks. One machine can be performing slow SQL injection, while another is fuzzing or working on buffer overflows. The third machine is still running the never ending nmap scans.
The attack vectors and results always vary, but its rare to find a server that is not vulnerable to some common exploit. Many times an open webserver is all I need. More companies are hosting their own webservers and relying on desktop support to provide security. Its not always that easy though. There is never a time when my browser does not have a tab open to Mitre's CVE list, Milw0rm, BugTraq and other sites that commonly contain information on software bugs. I'm not a script kiddie, but I'm not a machine either. Any skilled penetration tester knows where to go for knowledge, and regularly updates their copies of Metasploit. He or she will always review the code and learn the details of the exploit. In many cases the exploits can be written better, or modified in such a way to exploit another similar vulnerability.
The job is more glamorous on TV. In reality penetration testing 75% paperwork, 15% waiting for scans to finish, and 10% actual work.
I'm not about finding exploits and disclosing them to public forums. I am interested in secure coding and helping people identify their vulnerabilities. The techniques listed above are not new, they're not elite - they are things malicious hackers do every day. These tactics are right out of the penetration testers unwritten play book. Every penetration tester, and nearly every hacker will be bored to tears with this post. I wish SQL Injection, XSS, and Input validation were fairy tales.
Back to the notes for my presentation. I plan on using the A-Z bullets below. Feel free to share more in the comment section.
A) Always, ALWAYS filter user input. There is no reason someone should be allowed to put a script tag (<script>) in a date of birth field for example. You should deny all characters and whitelist only accepted. Never the other way around. Its much easier to allow a-z and 0-9 and deny all others, than it is to try and deny `!@#$%^&*()_+{}:"<>?/.,][;\|~\n\0\r\t and allow everything else (Did you notice I forgot one key character?)
B) You should always filter user input. -- See how important it is? Is there any reason someone needs to type '; DROP TABLE users--! Filtering includes server side buffer validation. In short, don't allow 256 characters when you only expect 2.
C) You should escape hostile characters, not replace them. I found one application that translated all quotes to a back-tick. In an oversite, they translated back-ticks to a single quote. Its a wonder their application didn't DoS itself. `; DROP TABLE users-- created a big headache for them.
D) Turn off debugging. Its left on more often than you'd imagine. Debugging is for development environment. Disable debugging in production completely. If you don't have a development server, you don't get to debug your code. Plain and simple. Spend a few bucks and install VMware - Save yourself the hassle of a compromise later.
E) Turn off verbose messages. Very few things scare me more than when I see a 500 error with server path disclosure:
F) Review ALL comments on your web application. Do you really need to make your comments visible to the world? Can they be parsed out on the server side by a proxy?
G) Deny/Drop all ports on the firewall - permit only required ports. Review the firewall configuration quarterly for any mistakes. You'd be surprised how often someone accidentally does a permit any/any to troubleshoot a problem and forgets to return the firewall back to the proper state.
H) Remove unused webpages and backups from websites. These should be stored securely somewhere in case they are needed again in the future. However, forgotten code probably contains vulnerabilities that are forgotten to all but a hostile attacker.
I) Review web, application, database and firewall logs regularly.
J) Implement an incident response procedure. Do you know who to contact in case of compromise?
K) Throughly test all patches before applying them. Does the latest patch break a SQL statement and allow for injection?
L) When applying patches, don't forget the database server, application server and operating system and firewalls. Remember the web server isn't the only appliance out there.
M) SSL doesn't protect your site from attackers, it only protects from eavesdroppers. This means, unless properly configured, your IDS could be missing attacks. Consider an application firewall that decrypts, inspects, and re-encrypts the traffic.
N) Monitor Mitre's CVE's regularly for applications you may use.
O) Regularly check sites like Zone-H and XSSed. If your site is listed, respond quickly but throughly.
P) Perform vulnerability scans on a minimum of a quarterly cycle. Use a quality scanner that performs signature checks and black box fuzzing. Some free options include Nikto and Wapiti.
Q) Don't rely on Javascript to filter bad words, input, or anything else. Client side javascript can be bypassed or modified with little to no effort.
R) Have an independent reviewer perform a yearly penetration assessment. This should be done more frequently for high profile sites.
S) Implement Egress filtering. Filter all unnecessary outbound ports. If you are compromised egress filtering can help limit your exposure.
T) Isolate employee only areas. Use VPN connections whenever possible.
U) Employees that use VPN or work from home should be furnished with company equipment to perform their job. The equipment should have a firewall and should not be used for casual surfing activities.
V) Train all employees on what is acceptable mail and news group posting. Employees should not share confidential company data with outsiders. Once an email is sent it can't be recalled.
W) Check modems, fax machines and printers for any potential data leakage. Many voicemail systems have forgotten dialup administration areas. What juicy details are stored on your companies voicemail server?
X) Implement a NIDS that will identify ARP poisoning style MITM attacks. (Arpwatch)
Y) Routinely test backups and disaster recovery plans. A severe compromise could be more of a disaster than anything mother nature can dish out.
Z) Relax. The world is out to get you, and you might just miss it if you are too paranoid.
While botnet research is fun and rewarding, it doesn't always pay the mortgage. Those who pay well don't enjoy having research aired in public - hence the lack of postings lately.
I figured some regular readers might be interested in what I've been up to. At the same time, I hope to create a good set of notes for an educational presentation I hope to give in a few months. This post should be generic enough to keep both my readers and employers happy.
My most recent projects have been penetration testing. I've done projects like this before, but never this massive. Its almost like everyone has suddenly realized how important computer security is - or maybe they're worried that with school letting out - all of the script kiddies are going to start hitting their sites.
It would be morally and ethically wrong to disclose any data related to this type of research/project, but I figured I'd post some things for everyone to think about while coding, performing your own pentests or generally (legally) messing around.
If you haven't done so, I recommend visiting Hack This Site. Hack This Site has several safe hacking games to play. While they are all fiction, some of the tactics will actually work in a real scenario. More importantly, you can enjoy an evening or two of goofing around without actually causing yourself or anyone else any harm.
Penetration Testing is not a skill set. Its not something that can be taught. All it requires is an open mind. You must think about things differently than other people. You must be willing to experiment without being afraid of your self. You must be disciplined enough to know not to use your knowledge with malicious intent. You should not share your research with anyone but your employer. Let your employer submit bug reports to vendors. This type of research is simply a behind the scenes job. If you just want your name in lights at Defcon, this isn't the job for you. You'll get about as much respect publishing exploits as you would by having your credentials on the wall of sheep.
The following techniques I am going to outline can be used for malicious intent. I'm fully aware of that. You should be aware that you will be caught if you try to use them. You may not get caught your first time, but trust me you will get caught eventually. Visit the hacking challenge sites and stay away from temptation. You'll find life is so much more rewarding when you can do what you love legally and without suspicion.
Before a pentest, right after I get the scope and required documentation signed, I perform a little recon. I use free search engines like Google and Maltego.
I search for news group postings to or from people who have email accounts on the target domain. I read every email and learn as much as I can about my target. Email postings provide a wealth of information. In email headers you can see internal IPs for businesses and residential IPs for employees. You can likely see what email or web client they use, and that will lead you to which operating system they run.
Some businesses let their employees use instant messengers and IRC. These point to weak security practices that are helpful later in the pentest.
Using Google I search for website issues like SQL injection. Example searches could include:
* site:site/domain "SELECT * FROM * WHERE"You get the idea. Other great searches can be found at Johnny Long's site.
* site:site/domain "SELECT USER"
* site:site/domain "PASSWORD="
* site:site/domain intitle:"ERROR 500"
* site:site/domain intitle:"employee"
* site:site/domain ERROR inetpub
Acting as a normal website visitor I will carefully search pages for locations that might be vulnerable to Cross Site Scripting and SQL injection. This is just about anywhere a clients browser can send data to the server. I note all of this for the actual pentest day, when I can try fuzzing fields.
That includes the pull down menus and input fields. With all of my searches I make sure to view the source code on each and every page. I look for comments that may have been left by developers. I'm looking for unused include scripts, insider data overlooked, and believe it or not, usernames and passwords.
I watch the server headers, and try to identify the web server and operating system. I pay special attention to internal IP addresses and cookies. In one penetration test a cookie was simply a base64 encoded IP address - that IP address was the internal IP for the server.
I DIG the target DNS server for obvious sub domains,
dig A webmail.pentestsite.com
dig A employee.pentestsite.com
In reality I simply run a recon script which gathers most of this data for me. I am working several projects at once, and need to spend my time wisely.
The night before I am scheduled to begin testing my target, I go over all the data I have gathered. I prefer to go over it just before I go to sleep. I come up with my best work while I'm asleep.
Depending on the scope of the test I may start a slow nmap scan of the host. By using the -T0 or -T1 flag I can evade most IDS systems. I start up these scans before even taking my morning shower or grabbing breakfast. They take a very long time to complete, and I don't want to waste a minute of that time.
I have several IPs at my disposal - for cases when an IPS catches me. Since I have these IPs, I'm also able to distribute my attacks. One machine can be performing slow SQL injection, while another is fuzzing or working on buffer overflows. The third machine is still running the never ending nmap scans.
The attack vectors and results always vary, but its rare to find a server that is not vulnerable to some common exploit. Many times an open webserver is all I need. More companies are hosting their own webservers and relying on desktop support to provide security. Its not always that easy though. There is never a time when my browser does not have a tab open to Mitre's CVE list, Milw0rm, BugTraq and other sites that commonly contain information on software bugs. I'm not a script kiddie, but I'm not a machine either. Any skilled penetration tester knows where to go for knowledge, and regularly updates their copies of Metasploit. He or she will always review the code and learn the details of the exploit. In many cases the exploits can be written better, or modified in such a way to exploit another similar vulnerability.
The job is more glamorous on TV. In reality penetration testing 75% paperwork, 15% waiting for scans to finish, and 10% actual work.
I'm not about finding exploits and disclosing them to public forums. I am interested in secure coding and helping people identify their vulnerabilities. The techniques listed above are not new, they're not elite - they are things malicious hackers do every day. These tactics are right out of the penetration testers unwritten play book. Every penetration tester, and nearly every hacker will be bored to tears with this post. I wish SQL Injection, XSS, and Input validation were fairy tales.
Back to the notes for my presentation. I plan on using the A-Z bullets below. Feel free to share more in the comment section.
A) Always, ALWAYS filter user input. There is no reason someone should be allowed to put a script tag (<script>) in a date of birth field for example. You should deny all characters and whitelist only accepted. Never the other way around. Its much easier to allow a-z and 0-9 and deny all others, than it is to try and deny `!@#$%^&*()_+{}:"<>?/.,][;\|~\n\0\r\t and allow everything else (Did you notice I forgot one key character?)
B) You should always filter user input. -- See how important it is? Is there any reason someone needs to type '; DROP TABLE users--! Filtering includes server side buffer validation. In short, don't allow 256 characters when you only expect 2.
C) You should escape hostile characters, not replace them. I found one application that translated all quotes to a back-tick. In an oversite, they translated back-ticks to a single quote. Its a wonder their application didn't DoS itself. `; DROP TABLE users-- created a big headache for them.
D) Turn off debugging. Its left on more often than you'd imagine. Debugging is for development environment. Disable debugging in production completely. If you don't have a development server, you don't get to debug your code. Plain and simple. Spend a few bucks and install VMware - Save yourself the hassle of a compromise later.
E) Turn off verbose messages. Very few things scare me more than when I see a 500 error with server path disclosure:
Error Executing Database Query.
[Macromedia][SQLServer JDBC Driver][SQLServer]Incorrect syntax near '')'.
The error occurred in E:\inetpub\wwwroot\qry_Details.cfm: line 27
Called from E:\inetpub\wwwroot\parsed\qry.detailspage.cfm: line 118
(fictional, modified error page)
F) Review ALL comments on your web application. Do you really need to make your comments visible to the world? Can they be parsed out on the server side by a proxy?
G) Deny/Drop all ports on the firewall - permit only required ports. Review the firewall configuration quarterly for any mistakes. You'd be surprised how often someone accidentally does a permit any/any to troubleshoot a problem and forgets to return the firewall back to the proper state.
H) Remove unused webpages and backups from websites. These should be stored securely somewhere in case they are needed again in the future. However, forgotten code probably contains vulnerabilities that are forgotten to all but a hostile attacker.
I) Review web, application, database and firewall logs regularly.
J) Implement an incident response procedure. Do you know who to contact in case of compromise?
K) Throughly test all patches before applying them. Does the latest patch break a SQL statement and allow for injection?
L) When applying patches, don't forget the database server, application server and operating system and firewalls. Remember the web server isn't the only appliance out there.
M) SSL doesn't protect your site from attackers, it only protects from eavesdroppers. This means, unless properly configured, your IDS could be missing attacks. Consider an application firewall that decrypts, inspects, and re-encrypts the traffic.
N) Monitor Mitre's CVE's regularly for applications you may use.
O) Regularly check sites like Zone-H and XSSed. If your site is listed, respond quickly but throughly.
P) Perform vulnerability scans on a minimum of a quarterly cycle. Use a quality scanner that performs signature checks and black box fuzzing. Some free options include Nikto and Wapiti.
Q) Don't rely on Javascript to filter bad words, input, or anything else. Client side javascript can be bypassed or modified with little to no effort.
R) Have an independent reviewer perform a yearly penetration assessment. This should be done more frequently for high profile sites.
S) Implement Egress filtering. Filter all unnecessary outbound ports. If you are compromised egress filtering can help limit your exposure.
T) Isolate employee only areas. Use VPN connections whenever possible.
U) Employees that use VPN or work from home should be furnished with company equipment to perform their job. The equipment should have a firewall and should not be used for casual surfing activities.
V) Train all employees on what is acceptable mail and news group posting. Employees should not share confidential company data with outsiders. Once an email is sent it can't be recalled.
W) Check modems, fax machines and printers for any potential data leakage. Many voicemail systems have forgotten dialup administration areas. What juicy details are stored on your companies voicemail server?
X) Implement a NIDS that will identify ARP poisoning style MITM attacks. (Arpwatch)
Y) Routinely test backups and disaster recovery plans. A severe compromise could be more of a disaster than anything mother nature can dish out.
Z) Relax. The world is out to get you, and you might just miss it if you are too paranoid.
Labels: Google Dorks, Network Security, Penetration Testing, Website Security
posted by Nicholas at
04:17
0 Comments:
Post a Comment
<< Home