Better late than never, I've got the presentations from BSides MSP uploaded. These are updated versions of two previous presentations. As always, feel free to reach out with questions or comments.
-Mike
@hardwaterhacker
You Will Be Breached
Is Your Data Literally Walking Out the Door?
Thursday, June 25, 2015
Tuesday, May 12, 2015
You Will Be Breached
Today, I had the chance to talk incident response at the North Dakota IT Symposium, where I shared my presentation - You've Been Breached. Are you Prepared?
Data breaches are inevitable. The need for effective incident response programs exists in all sizes of organizations. How well you recover from a breach depends on how prepared you are to respond.
This talk is an updated version of my previous talk - You Will Be Breached. This presentation covers the basics of building an incident response program, including several slides of resources useful to helping build an incident response program in your organization.
You can download my slides from Slideshare.
I'll also be presenting this talk at BSidesMSP in June. Come join us for two days of infosec learning and sharing!
Data breaches are inevitable. The need for effective incident response programs exists in all sizes of organizations. How well you recover from a breach depends on how prepared you are to respond.
This talk is an updated version of my previous talk - You Will Be Breached. This presentation covers the basics of building an incident response program, including several slides of resources useful to helping build an incident response program in your organization.
You can download my slides from Slideshare.
I'll also be presenting this talk at BSidesMSP in June. Come join us for two days of infosec learning and sharing!
Thursday, March 26, 2015
Implementing passive DNS monitoring to prevent phishing attacks
The idea of typosquatting - registering a domain name which mimics that of a valid web site - is not a new concept. In fact, in the US, laws aimed at preventing typosquatting were introduced as far back as 1999. In the beginning, typosquatting was a way to voice a gripe with the intended target or to generate advertising revenue from mistyped domain names. Criminal organization tactics evolved to use typosquatting as a way to deliver malware to anyone who accidentally happened upon the page.
Recent high profile attacks against Anthem BCBS and Premera Blue Cross highlight the evolution of typosquatting from opportunistic attacks to targeted attacks on specifically targeted organizations. While Premera has been tight-lipped about the methods used to breach their network, more is known about the Anthem attack. Analysis of both attacks by outside sources, however, point to the involvement of typosquatting attacks.
In the case of Anthem BCBS, formerly known as Wellpoint, a typosquatted domain we11point[.]com was registered in April of 2014. The Premera attack, which originally took place in May of 2014, appears to be associated with a typosquatted domain prennera[.]com. In both cases, to the casual observer, the typosquatted domains are nearly indistinguishable from their legitimate counterparts. It is known that we11point[.]com was used in a phishing attack targeted on Anthem employees in order to deliver malware which afforded the attackers a foothold in Anthem's network. It is suspected that prennera[.]com was used for the similar purposes.
In an effort to protect my corporate network against these kinds of attacks, I looked for ways to detect typosquatted domains that might be used in targeted phishing attacks. Fortunately, I did not have to look far. Andrew Horton of Morningstar Security created URLCrazy to automatically generate various permutations of a given domain name using a number of different methods included character omission, character swapping, and homoglyphs, the kind used in the Anthem attack.
Using URLCrazy is straight forward, with easy to understand options including keyboard layout. Since possible typos are based on the keyboard layout being used, URLCrazy supports several keyboard layouts. Output can be sent to the screen or formatted as a CSV, with the option of saving the output to a file.
In addition to generating typosquatting candidates, URLCrazy also checks whether those domains have already been registered. Below are two examples of the output generated for microsoft.com and wellpoint.com. Note that in the Wellpoint example, URLCrazy actually generated the same homoglyph used in the Anthem attack.
For my purposes, I wanted to be able to take a list of domains owned by the company and generate possible typos I could use as an early warning system for possible phishing attacks. I took the company domains and fed them to URLCrazy. I then performed a review of each domain that was already registered and classified them as either a valid site or a typosquatter and recorded these designations in a CSV. The typosquatted domains were then fed into our web proxy to prevent access to them in the event they are used in a phishing attack.
I wrote a simple python script which calls URLCrazy and compares the output against my CSV of identified domains. If a new typosquatted domain is registered, it will be detected and an alert will be generated and sent to the security analyst team for review. If the domain is indeed a typosquatted domain and not a legitimate website, the domain is again fed into our web proxy, blocking access. The CSV is then updated to include this new domain, ensuring we don't receive continued alerts.
My script, crazyParser, can be retrieved from my GitHub: https://github.com/hardwaterhacker/CrazyParser
This approach can be classified as a passive, reactive approach. If reviews are performed on a frequent and regular basis, it will serve as an effective defense against possible typosquatting attacks. This approach approach does not provide protection against phishing campaigns against your customers using typosquatted domains, however.
In order to proactively protect your customers, it may be necessary to identify typosquatting candidates and purchase those domains. These domains can then be redirected to the legitimate target domain name. This approach can become costly for smaller organizations with many domain names, and can become an management nightmare. It is generally considered best practice to have domain expiry notifications sent to a group mailbox to prevent domain registrations from lapsing after key personnel leave your organization.
In the event a domain has been registered which appears to be an obvious attempt to capitalize on typos of your legitimate domain name, the Universal Domain-Name Dispute-Resolution Policy may provide some relief. The UDRP allows for domain name holders to petition for the transfer of typosquatted domains to their control under certain circumstances.
Most commercial web proxies provide a categorization for web sites. In may cases, a newly-registered domain name will not yet have been categorized by your proxy vendor. As a final course of action, you can block access to all uncategorized web sites. This may provide a window of protection against domains used in phishing attacks. Blocking access to uncategorized web sites is generally considered a good practice.
As targeted phishing attacks continue to rise as an effective attack vector, this kind of DNS reconnaissance can serve as a reactive early warning system and even be used proactively to defend against attacks.
As always, I hope you found this post useful and your feedback is always welcome!
-@hardwaterhacker
Recent high profile attacks against Anthem BCBS and Premera Blue Cross highlight the evolution of typosquatting from opportunistic attacks to targeted attacks on specifically targeted organizations. While Premera has been tight-lipped about the methods used to breach their network, more is known about the Anthem attack. Analysis of both attacks by outside sources, however, point to the involvement of typosquatting attacks.
In the case of Anthem BCBS, formerly known as Wellpoint, a typosquatted domain we11point[.]com was registered in April of 2014. The Premera attack, which originally took place in May of 2014, appears to be associated with a typosquatted domain prennera[.]com. In both cases, to the casual observer, the typosquatted domains are nearly indistinguishable from their legitimate counterparts. It is known that we11point[.]com was used in a phishing attack targeted on Anthem employees in order to deliver malware which afforded the attackers a foothold in Anthem's network. It is suspected that prennera[.]com was used for the similar purposes.
In an effort to protect my corporate network against these kinds of attacks, I looked for ways to detect typosquatted domains that might be used in targeted phishing attacks. Fortunately, I did not have to look far. Andrew Horton of Morningstar Security created URLCrazy to automatically generate various permutations of a given domain name using a number of different methods included character omission, character swapping, and homoglyphs, the kind used in the Anthem attack.
Using URLCrazy is straight forward, with easy to understand options including keyboard layout. Since possible typos are based on the keyboard layout being used, URLCrazy supports several keyboard layouts. Output can be sent to the screen or formatted as a CSV, with the option of saving the output to a file.
 |
| URLCrazy usage |
In addition to generating typosquatting candidates, URLCrazy also checks whether those domains have already been registered. Below are two examples of the output generated for microsoft.com and wellpoint.com. Note that in the Wellpoint example, URLCrazy actually generated the same homoglyph used in the Anthem attack.
 |
| URLCrazy output for microsoft.com |
 |
| Homoglyphs of wellpoint.com |
For my purposes, I wanted to be able to take a list of domains owned by the company and generate possible typos I could use as an early warning system for possible phishing attacks. I took the company domains and fed them to URLCrazy. I then performed a review of each domain that was already registered and classified them as either a valid site or a typosquatter and recorded these designations in a CSV. The typosquatted domains were then fed into our web proxy to prevent access to them in the event they are used in a phishing attack.
I wrote a simple python script which calls URLCrazy and compares the output against my CSV of identified domains. If a new typosquatted domain is registered, it will be detected and an alert will be generated and sent to the security analyst team for review. If the domain is indeed a typosquatted domain and not a legitimate website, the domain is again fed into our web proxy, blocking access. The CSV is then updated to include this new domain, ensuring we don't receive continued alerts.
My script, crazyParser, can be retrieved from my GitHub: https://github.com/hardwaterhacker/CrazyParser
This approach can be classified as a passive, reactive approach. If reviews are performed on a frequent and regular basis, it will serve as an effective defense against possible typosquatting attacks. This approach approach does not provide protection against phishing campaigns against your customers using typosquatted domains, however.
In order to proactively protect your customers, it may be necessary to identify typosquatting candidates and purchase those domains. These domains can then be redirected to the legitimate target domain name. This approach can become costly for smaller organizations with many domain names, and can become an management nightmare. It is generally considered best practice to have domain expiry notifications sent to a group mailbox to prevent domain registrations from lapsing after key personnel leave your organization.
In the event a domain has been registered which appears to be an obvious attempt to capitalize on typos of your legitimate domain name, the Universal Domain-Name Dispute-Resolution Policy may provide some relief. The UDRP allows for domain name holders to petition for the transfer of typosquatted domains to their control under certain circumstances.
Most commercial web proxies provide a categorization for web sites. In may cases, a newly-registered domain name will not yet have been categorized by your proxy vendor. As a final course of action, you can block access to all uncategorized web sites. This may provide a window of protection against domains used in phishing attacks. Blocking access to uncategorized web sites is generally considered a good practice.
As targeted phishing attacks continue to rise as an effective attack vector, this kind of DNS reconnaissance can serve as a reactive early warning system and even be used proactively to defend against attacks.
As always, I hope you found this post useful and your feedback is always welcome!
-@hardwaterhacker
Wednesday, March 18, 2015
Is your data literally walking out the door?
Yesterday, I had the privilege of presenting at the 2015 ND Cyber Security conference, held at North Dakota State University. This conference brought together more than 200 K-12 and higher education technology specialists as well as others interested in information security from around the region.
I discussed the basics of physical security as seen from an attacker's perspective. I realize this presentation doesn't cover lock picking, but there are plenty of resources out there that talk about lock picking.
The presentation is available on SlideShare: Is Your Data Literally Walking Out the Door
As always, feedback is welcome and appreciated!
I discussed the basics of physical security as seen from an attacker's perspective. I realize this presentation doesn't cover lock picking, but there are plenty of resources out there that talk about lock picking.
The presentation is available on SlideShare: Is Your Data Literally Walking Out the Door
As always, feedback is welcome and appreciated!
Wednesday, October 29, 2014
Automating nmap and ndiff with PowerShell
I like to perform reconnaissance against my network border on a regular basis to identify new services and new hosts. With nmap, some bash, and cron, this is pretty easy to do. Unfortunately, the system I have outside our network to do this with is a Windows system with Kali running in a VM. I say unfortunately, because for some scans, running from Kali within a VM is significantly slower than performing a scan from nmap in Windows. I know you're thinking "But why don't you just get a *nix box in the cloud?" You deal with what you have available to you. Larger organizations sometimes come with less flexibility.
I wanted to be able to scan a given set of hosts and compare the results of each scan against the previous scan. The ndiff utility included with nmap was designed to do just that. I also wanted to get those results emailed to me. I also wanted to encrypt these results before emailing them, because reasons. I hadn't spent a lot of time with PowerShell, so this seemed like an opportunity to both get something done and learn PowerShell. The result is scandiff, a partial wrapper for nmap, ndiff, and 7Zip written in PowerShell.
Scandiff does a discovery scan against the targets supplied looking for open ports to identify live hosts. These hosts are then re-scanned using a larger set of ports and service version probing (-sV). I chose this two step method to decrease overall scan times when scanning large IP spaces. If the IP space being scanned is behind a firewall blocking pings and not returning RST, nmap will determine all ports are "open|filtered" and marks the host as up. The downside to this approach is that it is possible to miss hosts which have ports opened but are not included in the probed ports list. It is advisable to review your infrastructure and include all common ports for your network's services in your discovery probe list.
Scandiff retains the previous output in an XML file, $basename-prev.xml. Once the scan has completed, ndiff is run to compare the current scan results against the previous results to generate a -diff.txt file.
Once the ndiff operation has completed, the XML files, nmap log, and diff file are added to an encrypted 7Zip archive. This archive is added as an attachment to a System.Net.Mail.MailMessage email object. The results are then emailed to a designated recipient using the PowerShell Net.Mail.SMTPClient.
I used Gmail to relay the output to my inbox. This section can be modified to relay through a different email server, and authentication can be disabled if not required by your mail server. Email output can be disabled completely by specifying "-email 0" or "-email $False".
I'm still playing around with the nmap options to find the right balance of accuracy and thoroughness vs. performance. The script also has very little error handling. I will be working on adding this in the coming weeks. I am also looking at being able to specify the majority of configuration options from a configuration file to make the command line operation less unwieldy.
Scandiff can be downloaded from github here: https://github.com/hardwaterhacker/scandiff. Let me know if you find this useful. I'd welcome any input on how to improve this script.
I wanted to be able to scan a given set of hosts and compare the results of each scan against the previous scan. The ndiff utility included with nmap was designed to do just that. I also wanted to get those results emailed to me. I also wanted to encrypt these results before emailing them, because reasons. I hadn't spent a lot of time with PowerShell, so this seemed like an opportunity to both get something done and learn PowerShell. The result is scandiff, a partial wrapper for nmap, ndiff, and 7Zip written in PowerShell.
Scandiff does a discovery scan against the targets supplied looking for open ports to identify live hosts. These hosts are then re-scanned using a larger set of ports and service version probing (-sV). I chose this two step method to decrease overall scan times when scanning large IP spaces. If the IP space being scanned is behind a firewall blocking pings and not returning RST, nmap will determine all ports are "open|filtered" and marks the host as up. The downside to this approach is that it is possible to miss hosts which have ports opened but are not included in the probed ports list. It is advisable to review your infrastructure and include all common ports for your network's services in your discovery probe list.
Scandiff retains the previous output in an XML file, $basename-prev.xml. Once the scan has completed, ndiff is run to compare the current scan results against the previous results to generate a -diff.txt file.
Once the ndiff operation has completed, the XML files, nmap log, and diff file are added to an encrypted 7Zip archive. This archive is added as an attachment to a System.Net.Mail.MailMessage email object. The results are then emailed to a designated recipient using the PowerShell Net.Mail.SMTPClient.
I used Gmail to relay the output to my inbox. This section can be modified to relay through a different email server, and authentication can be disabled if not required by your mail server. Email output can be disabled completely by specifying "-email 0" or "-email $False".
I'm still playing around with the nmap options to find the right balance of accuracy and thoroughness vs. performance. The script also has very little error handling. I will be working on adding this in the coming weeks. I am also looking at being able to specify the majority of configuration options from a configuration file to make the command line operation less unwieldy.
Scandiff can be downloaded from github here: https://github.com/hardwaterhacker/scandiff. Let me know if you find this useful. I'd welcome any input on how to improve this script.
Friday, October 3, 2014
Automating Simple Website Reconnaissance Measures a.k.a An Ounce of Prevention
As a pen tester as part of an internal security team, I'm responsible for periodically sweeping our networks to identify web servers and determine if there are risks presented by those websites such as information disclosures, default credentials, or insufficient access and authorization measures. (aside: yes, change control would make sure this never happened again. In a world filled with unicorns farting rainbows.) On anything other than a small network, this can quickly become a time-consuming task. It didn't take long to decide to automate as much of this process as possible.
Since our vulnerability scanners are regularly touching all parts of our network, they are a good choice as a source for a list of hostnames, IPs, and ports for any service speaking HTTP or HTTPS. After massaging the data in Excel I have a list of URLs to test using either the FQDN or IP and the port number.
Once I have this list, typically several thousand different URLs to test, I need to quickly eliminate the systems I don't need or want to inspect. To do this, I wrote a simple python utility which uses urllib2 to pull in the page associated with each URL and analyze it through a simple string.find() loop. I built a dictionary of common sites that I know I won't need to inspect, such as
The biggest return isn't in time saved, however. The real value comes when the utility isn't able to classify the site. These sites often contain information that should have been secured, or authentication mechanisms using weak/default credentials. I can easily filter the output into additional tasks, such as testing for default Tomcat or JBoss credentials, etc.
In the past, I would take these unclassified results and dump them into a spreadsheet and then review them individually. Any site that would attempt to perform a Javascript redirect or refresh to a different landing page when '/' was requested would fool my utility as urllib2 is unable to follow the redirect. This lead to manually reviewing a lot of sites that would otherwise be easily identified if my utility could see the landing page.
A while back I experimented with being able to take a screenshot of each site to quickly eliminate these sites visually. Unfortunately, at the time, every utility I investigated was also stumped by the redirect. AJAX-heavy sites also fooled my utility as well as the other utilities I tested.
This summer Netflix released a tool they wrote - Sketchy - which they use to assist in their IR processes. Sketchy addresses the same issues I was experiencing with Javascript and AJAX sites. After reading about Sketchy, I knew that I wanted to try applying this to my processes to see if I could get better results and be more efficient.
Feeling inspired by all the incredible talks presented at DerbyCon,I decided it was time to start putting Sketchy to work. I blogged earlier about my experience setting up Sketchy, you can read about it here.
While Sketchy does have an API, a quick and dirty shell script worked for my needs. The script supports grabbing a screenshot (sketch), grabbing the DOM as text (scrape), or grabbing the rendered HTML (html). For sites sketchy is unable to connect to, my script makes a log entry and does not produce an artifact.I can quickly view these resulting images and determine if the site is something that warrants further inspection.
Sketchy was easy to install, and it didn't take long to whip up a functioning system. With a few hours of setup, scripting, and testing, I'm able to automate what used to be several hours of work. In the end, I'm free to get more done, and much more of the proverbial low-hanging fruit is picked.
If you're using different tools to achieve the same end, I've love to hear about it. Leave me a comment or reach out to me on Twitter.
-Mike
Since our vulnerability scanners are regularly touching all parts of our network, they are a good choice as a source for a list of hostnames, IPs, and ports for any service speaking HTTP or HTTPS. After massaging the data in Excel I have a list of URLs to test using either the FQDN or IP and the port number.
Once I have this list, typically several thousand different URLs to test, I need to quickly eliminate the systems I don't need or want to inspect. To do this, I wrote a simple python utility which uses urllib2 to pull in the page associated with each URL and analyze it through a simple string.find() loop. I built a dictionary of common sites that I know I won't need to inspect, such as
- Sites with the corporate authentication mechanisms presented
- Default Apache / IIS web pages
- Default Tomcat or JBoss install
- KVMs and SAN switch interfaces
- etc.
The biggest return isn't in time saved, however. The real value comes when the utility isn't able to classify the site. These sites often contain information that should have been secured, or authentication mechanisms using weak/default credentials. I can easily filter the output into additional tasks, such as testing for default Tomcat or JBoss credentials, etc.
In the past, I would take these unclassified results and dump them into a spreadsheet and then review them individually. Any site that would attempt to perform a Javascript redirect or refresh to a different landing page when '/' was requested would fool my utility as urllib2 is unable to follow the redirect. This lead to manually reviewing a lot of sites that would otherwise be easily identified if my utility could see the landing page.
A while back I experimented with being able to take a screenshot of each site to quickly eliminate these sites visually. Unfortunately, at the time, every utility I investigated was also stumped by the redirect. AJAX-heavy sites also fooled my utility as well as the other utilities I tested.
This summer Netflix released a tool they wrote - Sketchy - which they use to assist in their IR processes. Sketchy addresses the same issues I was experiencing with Javascript and AJAX sites. After reading about Sketchy, I knew that I wanted to try applying this to my processes to see if I could get better results and be more efficient.
Feeling inspired by all the incredible talks presented at DerbyCon,I decided it was time to start putting Sketchy to work. I blogged earlier about my experience setting up Sketchy, you can read about it here.
While Sketchy does have an API, a quick and dirty shell script worked for my needs. The script supports grabbing a screenshot (sketch), grabbing the DOM as text (scrape), or grabbing the rendered HTML (html). For sites sketchy is unable to connect to, my script makes a log entry and does not produce an artifact.I can quickly view these resulting images and determine if the site is something that warrants further inspection.
Examples
 |
| Linksys router login page |
 |
| Twitter login page |
Conclusion
Reviewing websites is essential to identifying information disclosures, weak authentication mechanisms, and new web apps or devices that may have been deployed without your knowledge. Regularly reviewing these websites for this information prevents audit findings and helps keep your network and data safe from unauthorized access.Sketchy was easy to install, and it didn't take long to whip up a functioning system. With a few hours of setup, scripting, and testing, I'm able to automate what used to be several hours of work. In the end, I'm free to get more done, and much more of the proverbial low-hanging fruit is picked.
If you're using different tools to achieve the same end, I've love to hear about it. Leave me a comment or reach out to me on Twitter.
-Mike
Thursday, October 2, 2014
Lessons learned from setting up Sketchy
Have you ever wanted to pass a URL off to a program and have it return a screenshot of that site? This is incredibly useful for things like DFIR, allowing you to get an initial look at a page without having to poke at it with a potentially vulnerable browser. I've used various tools to try to take screenshots of sites that either have a Javascript-based redirect at initial load or are AJAX-based and these tools always failed me.
Earlier this summer, I heard about a suite of tools released by Netflix. This suite included Sketchy, a conglomeration of python, Flask, phantomjs, gunicorn, celery and redis. Sketchy uses lazy-rendering within phantomjs to allow it to take screenshots of AJAX-heavy sites.
Based on the writeup by the Netflix crew, I was hopeful this would solve the problem once and for all. I finally had time this week to sit down and play with Sketchy. There were a few bumps along the road, so I decided to put down what I did here in case anybody else is interested in getting Sketchy working.
If you use Kali, you're probably running most of your commands as root. If you are, when you set up the database using `python manage.py create_db'. If you proceed down this path and follow the Test Startup instructions, everything will work fine, however you will get an Internal Server Error message if you try to follow the Production startup instructions.
In my case, production startup failed to render images because the database was set up by root but gunicorn was running under a reduced-privilege user (to be discussed later).
To get around this, I created a tmp directory within my Sketchy install as /opt/sketchy/tmp. In order for manage.py to create the DB in this directory, I modified config-default.py to point to the new location:
Make sure to update your PHANTOMJS location according to your local system. The setup script detected I had phantomjs installed, however config-default.py was looking for it in /usr/local/bin instead of /usr/bin.
I'll be posting another blog soon about how I use Sketchy as an internal penetration tester to reduce the amount of time I spend performing website reconnaissance and looking for information disclosures.
Earlier this summer, I heard about a suite of tools released by Netflix. This suite included Sketchy, a conglomeration of python, Flask, phantomjs, gunicorn, celery and redis. Sketchy uses lazy-rendering within phantomjs to allow it to take screenshots of AJAX-heavy sites.
Based on the writeup by the Netflix crew, I was hopeful this would solve the problem once and for all. I finally had time this week to sit down and play with Sketchy. There were a few bumps along the road, so I decided to put down what I did here in case anybody else is interested in getting Sketchy working.
Installation
I installed Sketchy in my Kali linux VM. The installation was straight forward. Use git to clone the Sketchy repository to your machine. I chose to put mine in /opt/sketchy. With an up-to-date Kali installation, simply running ubuntu_install.sh will pull down all the necessary dependencies and build your environment for you. If you don't want to trust a script to do this for you, the dependencies are clearly noted in the manual install section of the wiki.User Setup
The Sketchy wiki doesn't discuss this, but if you're going to run Sketchy as root, celery will complain about being started as UID 0. To get around this, I created a standard privilege user named sketchy, a group named sketchy, and made the sketchy user a member of the sketchy group. I then changed ownership of the Sketchy install directory and all files and subdirectories to the sketchy user and sketchy group.Database Setup (and the first hiccup)
By default, Sketchy creates a SQLite database to store information. While the wiki recommends a different RDMBS such as MySQL, for low volume purposes you should be fine using the default database. This was where I ran into a problem which would confound me for some time.If you use Kali, you're probably running most of your commands as root. If you are, when you set up the database using `python manage.py create_db'. If you proceed down this path and follow the Test Startup instructions, everything will work fine, however you will get an Internal Server Error message if you try to follow the Production startup instructions.
In my case, production startup failed to render images because the database was set up by root but gunicorn was running under a reduced-privilege user (to be discussed later).
To get around this, I created a tmp directory within my Sketchy install as /opt/sketchy/tmp. In order for manage.py to create the DB in this directory, I modified config-default.py to point to the new location:
If set up the database as root, you'll want to change ownership of the new database to sketchy.sketchy to allow gunicorn to update it.# Database setup SQLALCHEMY_DATABASE_URI = 'sqlite:////opt/sketchy/tmp/sketchy.db'
Configuration
The Sketchy wiki indicates you should remove ":8000" from the HOST variable in config-default.py. I did not find it necessary to remove this to allow Sketchy to work properly.Make sure to update your PHANTOMJS location according to your local system. The setup script detected I had phantomjs installed, however config-default.py was looking for it in /usr/local/bin instead of /usr/bin.
supervisord.ini
There isn't too much to change in this file. For [supervisord], you may want to store your log files in /var/log. Changing the loglevel to debug will help you identify issues. In both the [program:celeryd] and [program:gunicorn] sections, set the directory to your Sketchy installation directory and change the user to the account you created to run the daemons (I used sketchy). I also changed the address gunicorn was using to 127.0.0.1 to prevent it from listening on any network interface.Conclusion
Sketchy definitely has a place in my toolkit. I haven't found anything that will reliably screenshot pages that use Javascript to redirect to another page or things that are AJAX-based. Sketchy fits the bill perfectly for that use case. The performance isn't bad, but it's not a speed demon either. I haven't spent any time looking into optimizing the various components used to see if I can get better performance.I'll be posting another blog soon about how I use Sketchy as an internal penetration tester to reduce the amount of time I spend performing website reconnaissance and looking for information disclosures.
Subscribe to:
Posts (Atom)