Posted on February 4, 2019
It has been over a year since I last blogged, as reflected in this post’s name. My working situation has improved a lot over the past year which has led to me neglecting the previously enjoyed exercise of bug bounty hunting and blogging. I do very much intend on getting back into these activities at some stage but I’m kept busy for now. I work roughly 7 months of the year on contracts. Mainly taking the form of internal/external penetration tests and vulnerability assessments. I do still sometimes take on incident response jobs, many of which are subcontracted to me against my will 😉 I enjoy the rush of an active attack and witnessing the TTPs (techniques, tactics & procedures) of seasoned criminals but like you I can’t and won’t talk about any of that here because I’ll trigger my thousand yard stare.
So it’s a given that I have had 5 months of the year free to develop and encourage my own laziness via automation. That’s what this series of blog posts will focus on, hopefully in enough depth to make it a worthwhile read and potentially convince someone I’m worth contracting. I’d like to show the world some of the things I’ve been working on recently and share my mentality, toolkit and methodologies. I can guarantee a lot of this stuff is being done by others out there, as I like to read a lot and I didn’t pick up these ideas or skills from kicking rocks. It takes a lot of active learning and researching to stay on top of the latest security trends and techniques.
Many folks are indeed better than I at being cutting-edge, thanks to their active information circles, hard work and dedication to self-improvement. I still run tools like Nessus against infrastructure and am very fond of burp-suite, these tools compliment and can be used in conjunction with any of my original tools. They capture useful information very quickly, especially on internal environments. Nessus authenticated scans are very handy to have and I won’t stop using such tools any time soon. I want to thank everyone in this wonderful security community, who takes the time to openly share their trade-craft, hard lessons learned and research.
All I can share is what has worked for me consistently and maybe inspire some others with ideas or new avenues to explore. Since a lot of my stuff is self-developed, I may also eventually release more tools but the bulk of my toolkit probably won’t be shared, it’s my bread and butter and should help me find things others miss. Most things can also be easily accomplished with other tools already in the public domain. I develop for myself in python, it means I know my own tools inside out and can prioritize output in a way that the data becomes immediately actionable for me.
A Simplified Methodology
In order to avoid writing a book, I’ll try simplify and explain a lot of ideas as generally as I can. The following is a simplified penetration testing methodology. This should be effective against any online business, network or company, of any scale.
- Reconnaissance, OSINT and Information Gathering
- Network scanning, Service and application identification, vulnerability identification
- Exploitation & Escalation
I set out with a plan of automating as much as I could and especially where current tools or techniques were lacking, so at a minimal I was at least speeding up what I do manually. This should allow me to have more time for manual examination and fuzzing which increases my value by increasing the likelihood that more serious issues can be exposed in the time available.
⦁ who is the target? company? acquisitions? owners? developers?
⦁ where/how do they hire? where are they based? what tech do they use?
⦁ what’s their major product? what services do they provide?
⦁ 3rd parties they interact with? How do they accomplish their goals?
⦁ where are their networks? how are they managed? by who?
⦁ what issues have impacted them? what attacks have they seen before?
⦁ Company presentations? product demos? any URLs/tech used in them?
⦁ what do they want or need to avoid?
With an understanding and profile of the target, it’s time to start enumerating public network information resources. This is the first technical step of my workflow and will be the focus of this post.
Some key concepts I relish throughout, are that all data and technical information captured is useful, can be expanded on, should be stored and is continuously fed in a feedback loop manner from process to process. It is also essential to keep track of when, where and what you are testing. This can help if a client wants to dig into anything further. Keep a log of your own activities and enable logs for tools, it’ll save you heartache in the long run and allow you to retrace steps in future.
The final concept, is that I want everything I build to be easy to tear down and rebuild. I accomplish this through a series of ansible playbooks. This allows me to rapidly scale my tools out when needed and reproduce my architecture quickly on a fresh set of hosts. Ansible is perfect for me as an alternative to bash scripts and I can manage all of my infrastructure on the command line of a single administrative host.
Capturing the Network
Before digging into the specifics I’d like to share the architecture behind one of my primary tools used for reconnaissance. This is a tool I developed called “recron” and is an automated continuous recon framework. It is composed of four main parts on the management side, a database – a redis task queue, an API and a web app/dashboard. And then a single orchestration client on any number of worker nodes to run my CLI tools. It scales quite well, I can leave it running over a week with no hiccups and I have no idea what to do with this beautiful beast yet.
The basic principle here is that no information is lost once it’s collected. Through cronjobs and continuous enumeration, it can be deployed against a target for the duration of a penetration test or as an ongoing monitoring service to manage assets from an offensive perspective in an ongoing way. The tool allows data or information to be manually added and updated, with changes in infrastructure updating automatically on a continuous basis and being stored or tracked over time. It’s possible to implement automatic alerting for these changes too. However I mostly just want a clear snapshot of the external network infrastructure as it is.
The continuous monitoring and alerting feature set I use and strive for are the following:
⦁ Subdomain discovery, brute forcing and enumeration
⦁ Network edge-expansion, identifying unexplored IP ranges and domains
⦁ Port scans, banner capturing and enumeration
⦁ Web application enumeration via brute forcing and discovery scans
Service and Application Identification
As an example a domain is added to the database via a CLI tool, a continuous process adds this new domain to the task queue. This information is picked up by the multiple worker nodes and the domain is fed into multiple domain discovery tools like subfinder (https://github.com/subfinder/subfinder ) and IP information is retrieved from various current and historical API’s and data-sets like those at scans.io (https://scans.io/). The unique output of these tools is then added back into the database via the API and the process is repeated.
This continuous feedback loop has endless possibilities and allows for the smarter discovery of otherwise hard to find assets. For example one of the tasks uses an excellent tool called altDNS (https://github.com/infosec-au/altdns) which allows the generation of alterations and permutations of subdomains. We can feed this tool a single domain/subdomain, a dictionary, all the subdomains discovered thus far for the target via our API and any other common subdomain brute force lists deemed useful. A brute force of this generated list with massdns doesn’t take longer than 10 minutes (https://github.com/blechschmidt/massdns). This ensures the rapid discovery and enumeration of new assets, subdomains or potential virtual hosts, when you increase the number of client nodes.
Other things we can do is brute the subdomains of subdomains, whereby example.blah.test.domain.com can be brute forced at the following locations:
For large companies it should be obvious how this increased attack surface is especially useful with regards to bug bountying. The results of this technique speak for itself.
The screenshot above is new subdomains discovered on top of what was found with traditional tooling. Another module of recron involves network edge expansion. This for example takes all the IP addresses currently in the database and identifies the network ranges that have multiple subdomains already identified within a /24 block, it then does a reverse lookup of all IPs in that network and checks SSL certificates for any additional domains. Flagging other newly discovered domains as potentially owned by the same target organisation, this is less useful with modern cloud based services but is good for company owned network blocks and can reveal new areas or domains to explore or allow new data to be added into the discovery process.
Reusing all the information stored, presents me with other interesting opportunities. A more recent example I’ve explored, is taking a list of IP addresses that were resolved from the target company domains. A task then runs a vhost brute force against these IPs using a list of all subdomains discovered thus far. This can reveal old/alternative web apps that were never removed from the company owned IPs in question and open up more additional attack surface. This has on multiple occasions revealed web applications for subdomains that didn’t have current DNS entries.
Another extremely useful module is one to run network scans against the identified IPs, this is also a continuous or daily process and takes an IP from the database, adding it to the task queue. I usually run masscan (https://github.com/robertdavidgraham/masscan) and then Nmap against a target with the -A flag so it also runs additional information gathering scripts. The results are then imported via the API and added to a host allowing for asset exploration via the management dashboard.
The idea is to make useful information accessible as quickly as possible and available in order to make it actionable. Another component of this automated recon framework is a tool I just recently “finished”. I based it on a few older tools of mine that dumped directory brute force scans into elasticsearch (called scantastic), I wanted to minimize the overhead of my infrastructure however and SQLite works perfectly fine in this case.
I’m releasing the latest tool that was part of the framework and it’s called scanomaly. The intent of this was to combine multiple tools into one flexible tool and store all the data for single targets in a databases. Using the module based system it also allowed me to rapidly script prototypes for new attacks and run them across a network.
This allows me to compare databases and generate alerts based on new content that has appeared on web servers since the last scan and also carry out general fuzzing. There isn’t a public user interface for the output of this tool yet but I may just copy some of the stuff from the management flask app in the screenshot above. I want the visual elements to go along with the anomaly detection tools, based on the response information stored in the responses table. I’ll likely do another blog post on how to use this tool with examples once I’ve the user side of it finished.
This post is getting too long so I’m going to call it before talking about exploitation and escalation …
It’s good to be back among the blogging world
Posted on September 24, 2017
Given I have been working in information security for the past few years, I became well aware of the different certifications available as a means of professional development. The certification that stood out as gaining the most respect from the security community seemed to be the “(OSCP) Offensive Security Certified Professional” certificate, I witnessed this time and time again in conversations online. The reason often given is that it is a tough 24 hour practical exam vs a multiple choice questionnaire like many other security certificates. The OSCP is also listed regularly as a desirable requirement for many different kinds of infosec engineering jobs.
I recently received confirmation that I have successfully achieved this certification. To anyone interested in pursuing the OSCP, I would completely encourage it. There is no way you can come away from this experience without adding a few new tricks or tools to your security skills arsenal and aside from all of that, it’s also very fun. This certificate will demonstrate to clients or to any potential employer that you have a good wide understanding of penetration testing with a practical skill-set to back up the knowledge. I wanted to get this as I’ve had clients in the past not follow up on using my services due to me not having any official security certificates (especially CREST craving UK based customers). Hopefully this opens up some doors to new customers.
Before undertaking this course I already had a lot of experience performing vulnerability assessments and penetrations tests, I also had a few CVEs under my belt and have been quite active in the wider information security community by creating tools, taking part in bug bounties and being a fan of responsible disclosure in general. I found the challenge presented by this exam to be quite humbling and very much a worthwhile engagement.
I would describe the hacking with kali course materials and videos as very entry-level friendly which is perfect for someone with a keen interest looking to learn the basics of penetration testing. The most valuable part of the course for those already familiar with the basics is the interactive lab environment, this is an amazing experience and it’s hard not to get excited thinking about it. There were moments of frustration and teeth-grinding but it was a very enjoyable way to sharpen skills and try out new techniques or tools.
I signed up for the course initially a full year ago while working full time on contracts and found it extremely difficult to find the time to work on the labs as I had multiple ongoing projects and was doing bug bounties quite actively too. I burnt out fairly quick and didn’t concentrate on it at all. I did one or two of the “known to be hard” machines in the labs fairly easily which convinced me I was ready and sat the exam having compromised less than 10 of the lab hosts. This was of course silly and I only managed 2 roots and one local access shell which wasn’t near enough points to pass and very much dulled my arrogance at the time. I didn’t submit an exam report and decided to focus on my contracts and dedicate my time to the labs properly at a later date.
Fast forward over a year later to the start of this month (September) and I had 2 weeks free that I couldn’t get contract work for. So I purchased a lab extension with the full intention of dedicating my time completely to obtaining this certificate. In the two weeks I got around 20 or so lab machines and set the date for my first real exam attempt. This went well but I didn’t quite make it over the line. I rooted 3 machines and fell short of privilege escalating on a 4th windows host. I was so close and possibly could have passed if I did the lab report and exercises, however this time around I wasn’t upset by the failure and became more determined than ever to keep trying. I booked another 2 weeks in the labs, focused on machines with manual windows privilege escalation and booked my next exam sitting, successfully nailing it.
As I had learned a lot of penetration testing skills doing bug bounties, I found that it was very easy to identify and gain remote access to the lab machines, I usually gained remote shell access within the first 20 or 30 minutes for the large majority of the attempted targets. I very quickly found out that my weakest area was local privilege escalation. During my contract engagements, it is a regular occurrence that my clients request I don’t elevate any further with a remote code execution issue on a live production environment. This activity is also greatly discouraged in bug bounties so I can very much see why I didn’t have much skill in this area. The OSCP lab environment taught me a large amount of techniques and different ways of accomplishing this. I feel I have massively skilled up with regard to privilege escalation on Linux or Windows hosts.
I’m very happy to join the ranks of the (OSCP) Offensive Security Certified Professionals and would like to thank anyone who helped me on this journey by providing me with links to quality material produced by the finest of hackers. Keeping the hacker knowledge sharing mantra in mind, below is a categorized list of very useful resources I have used during my journey to achieving certification. I hope these help you to overcome many obstacles by trying harder!
Shell Escape Techniques
Linux Privilege Escalation
Windows Privilege Escalation
Posted on June 29, 2016
I recently did an interview for a Magazine about bug bounties and hacking Pornhub. When I’m not targeting large multi-million dollar organisations directly through bug bounty programs, I perform security assessments on behalf of small to medium size enterprises.
Contracts take up a larger amount of my time, as a freelance consultant it can be hard to advertise this work given that I keep my clients and the work I do strictly confidential. I use responsible disclosure and bug bounty programs as a means of advertising my skill-set and hopefully as a means of getting attention for the regular consulting services I provide. I’m available for short term contracts, no shorter than a day and no longer than a month.
My rates are quite cheap in comparison with standard prices one usually expects to pay for security consulting or penetration testing. The reason for this is to make my services more attractive to smaller companies or websites (they need protection too and often can’t afford it).
I’m also still running a special cheap rate for customers based in Ireland. My slightly alternative Penetration Test is essentially a more old-school style, 2 week, multifaceted penetration test. This type of testing is harder to come by these days.
The aim of this testing is to identify the most likely security issues to be exploited by a malicious attacker to ruin or damage your business, looking at your business as a whole. This includes taking a look at all your online assets and also includes performing controlled malware or phishing campaigns. The goal here is to determine what the most likely attacks facing your particular business model are and to help you resolve or mitigate them. It can help identify issues your staff also need to be aware of. Often organisations don’t realize how much information about their assets or internal company structure an attacker can gleam from public resources. This testing gives a very good overview of where your primary security risks are and can help you to prioritize your efforts.
Alternative 2 week Penetration Test: €4000
Daily Consulting Rate: €650-850
My prices are generally cheaper for smaller businesses and if I don’t find severe issues.
Contact firstname.lastname@example.org with any questions, it costs nothing to be curious!
Posted on April 11, 2016
I attended the second ever Zero Days CTF (capture the flag) event recently. It was setup and organised by lecturers in the Institute of Technology, Blanchardstown who run the Cyber Security and Digital Forensics course. The event was also sponsored by Amazon, Integrity360 and Rits Information Security. ITB is home to one of the few 3rd level security courses available in Ireland. The event was primarily aimed at students and is, as of now, the biggest event of its kind to be ran in Ireland as far as I’m aware, with almost 40 teams of 4 taking part.
As someone who follows CTF TIME quite regularly, I’ve done quite a few challenges from the top level Capture the Flag events around the world, the competition is high and the standard is difficult for the majority of these events. I often recommend that people check them out or follow the github of CTF write-ups as a means of learning some cool new shit.
It was however nice to see that the difficulty of the challenges in the Zero Days CTF were adjusted to make it more fair for participants of all levels. They did however seemingly have an increased level of difficulty on the challenges I had seen from the 2015 event which is a positive thing for all involved. There were also a number of teams of professionals already working in the industry taking part. I would have loved to have events such as this back when I was a student, it serves to point newcomers in the security world towards some very interesting areas and certainly provides extra opportunities to put some of your information security knowledge, theory and techniques into practice.
Our winning team ‘popret‘ was composed of Conor Quigley, Denis Isakov, Serge Bazanski and myself (Ciaran McNally). We are all currently working in the security industry in Dublin and are fond of a challenge. We put into action some good team and collaboration techniques that helped us knock off many of the challenges early before anyone else managed to solve them, ensuring we maximized our points. We used IRC and also a shared paste-pad to help speed up our solutions by documenting any work done so far and to make sure we weren’t simultaneously working on the same challenges.
We were awarded some 7″ Android Tablets for our effort! I’d like to thank all who put the work in to set up such a fun event and also encourage people to attend events like this into the future as it’s fundamental to growing the quite small Irish information security community. Events like this are excellent networking opportunities and are a good place to spot tech talent fresh out of college. Hopefully we see plenty more of these events into the future…
Hack the Planet.
Posted on October 9, 2015
Daggercon is a security conference that took place for the first time this year out in west Dublin on the IBM campus. It was free to attend and was definitely one of the biggest events of its kind that I’ve seen in Ireland. The event was ran very smoothly and with a real community spirit that hopefully helps grow communication within the Irish information security scene. All areas of the security community were represented, from hobbyist to corporation.
After the CTF I nervously did my talk but was delighted to get good feedback and questions from the attendees. The topic for my talk was Bug bounties, hopefully I helped to raise awareness of them or gave useful tips in how to get involved or started with them . The slides for this talk are available at the following location slideshare.net/securitie/bug-bounties-cn-scal.
I then also took part in a “Secure Coding” competition that leveraged a very interesting platform by the name of Secure code Warrior. This gamified the reviewing of source code and finding security issues in JSP web applications from static analysis. It was definitely more fun than you would expect for a learning platform.
I ended up winning this competition too and being presented with a new Amazon Echo, these devices aren’t available in Ireland at the moment. All in all it was an excellent event and I hope to see it continued in 2016!
Posted on September 18, 2015
Over the past few months I’ve dedicated approximately 24 hours in total to the Adobe Responsible Disclosure program. I am currently the leader of this bounty program by a significant margin, this is however mostly attributed to the fact that the program offers no cash incentive for bounty hunters. I was informed that they do however run private bounty programs on occasion for cash rewards. I set myself a personal goal of submitting 100 bugs and then planned to do a public disclosure of all the issues I discovered. This was primarily meant as a means of advertising the security consulting services I provide as a freelancer.
This plan however went a bit sour, as Adobe requested I keep the details of the issues I responsibly disclosed private, which I feel they are fully entitled to do, so what I have decided to do instead is this blog post. This will outline from a high-level the kind of issues I’ve been finding on their web services. This data is based on the first 66 vulnerabilities I submitted.
As you can see in the pie chart below, 33% of all the bugs I submitted were Cross Site Scripting (XSS) vulnerabilities. It’s easy to understand that XSS is still very widespread and will remain a common web security problem in the OWASP top 10 for a long time.
Another 30% of the issues I found were “Sensitive Information Disclosure”, these varied widely and included such things as finding web logs in the web directory, configuration files, misconfigurations that allowed source code to be downloaded and even a public-private key pair in a web directory.
Some of the most severe issues I identified were authentication bypasses or privilege escalation bugs. These allowed administrative access to various content management systems belonging to some of Adobe’s key services. A lot of these were achieved by accessing administrative panels directly that had broken authentication, through finding hidden registration forms or simply misconfigured permissions. These accounted for 14% of the findings.
I discovered quite a lot of other critical issues that could or do allow the leaking of a lot of sensitive data. Remote code execution, SQL Injection, Local File inclusion and XXE are the kind of vulnerabilities that would generally reward handsomely on a paid bounty program as issues like this could cost a company millions if the information was in the wrong hands. I also found multiple code repositories available in web directories. These critical issues accounted for 15% of the 66 bugs I reported.
There are definitely some interesting contrasts to be drawn between the security of some of the paid bounty programs and that of Adobe. There seems to be a lot more obvious and “low-hanging” issues throughout the Adobe web services. This could mean Adobe have a lower threshold of difficulty so is a perfect target for some new bounty hunters.
This gives me hope, as it’s becoming clearer that the bug bounty community knows the value inherent in what we do. Companies should be forced to realise that even a small cash incentive can go a long way in convincing the community to look a little deeper at your bug bounty program. Even at $20 a vulnerability, the 66 issues I submitted would pay my months’ rent. Regardless of what way you look at it, its a billion dollar organisation being cheap. Once I hit my 100 bug goal I won’t be looking at their stuff any further without a cash incentive.
I am undercutting the bounty communities “No Free Bugs” motto simply as a means of trying to get myself a bit more contract work and for that I am sorry. I see bug bounties as something the world needs right now. They provide a great means for young infosec students to break into the industry and get a few notches of experience on their CV, all while earning a bit of pocket money for the effort.
Many people like myself are seeing bounties as a means of making consistent income so they can work for themselves or even fill in the spaces between contract work as a freelancer. Bug bounties present an excellent opportunity for beginners to practice their practical skills on real systems, this is much more valuable as “industry experience” than that of Capture the Flag events you may get in universities for example; you are getting real experience in reporting the issues found.
Bug bounties are extremely valuable to the companies leveraging them too, they give incentive for a defensive security team to be pro-active about defending the companies systems. I imagine they have revolutionised the way the internal incident handling is performed or at least improved or greatly reduced the turn-around time for resolving security issues as the programs become more mature.
Posted on September 8, 2015
One thing I abhor that you will find as standard in the security industry is the two to three day Penetration Test. These undertakings can of course greatly help improve an organisations security posture but it seems more like a box-ticking activity. The only reasonable outcome being that the bar is raised just enough so that a passing script-kiddie loses interest and moves on, or that the most obvious severe issues are remediated. There are of course other factors at play such as costs, deadlines and compliance testing but the previous sentence remains a problem as it is still true.
Companies need to embrace that a security assessment is something they should come away from with fear. The result of your penetration test should be a solid list of real attack scenarios your company could face (or will) that needs to be defended against. If your organisation doesn’t feel threatened by the results or feel like they have been outsmarted, then the security assessment isn’t a real reflection of the real world. The price you are paying isn’t worth the resulting report.
In the real world, malicious actors will use any means necessary to benefit from the shortcomings of your enterprises security. This could be for financial gain, through stealing information or simply through complete destruction of your assets because they disagree ideologically with what you do.
I found the recent series of Mr.Robot to be fantastic, it accurately portrayed many of the multifaceted methods deployed by malicious actors to infiltrate and destroy even an extremely large enterprise. Understandably this is Science Fiction and the outcome is quite far-fetched, but the techniques demonstrated are not. Attacks similar in nature are regularly used against organisations and the regular Penetration Testing methodology of reconnaissance, analysis, vulnerability assessment and execution is demonstrated in full.
In light of this fantastic show and having the freedom to try new things as a freelancer, I would like to announce my “Mr.Robot Special”. This is a full, multifaceted, two week Penetration Test for the price you would regularly pay for a traditional three day one. I get excited at any opportunity to work like a secret agent and play with all my gadgets and custom tools. This offer is only open to organisations in Ireland for the moment. Please do get in touch! ( email@example.com )
As my perspective has changed on the value of traditional penetration tests, I would like to also challenge the standard. A single person of course does not possess the same skills you may find in a good red-team style penetration test. Very rarely, if ever, do you get that style of attack in a standard operation. I feel there is inherent value in having a single actor perform a concentrated attack on your organisation or network, as the drive to succeed is increased as there is no illusion of a team to hide failure.
If I can highlight to you the damage a single person could potentially do to your organisation, it should be easier to imagine the risk posed by an internet full of malicious actors, let alone a nation-state level attack or other advanced persistent threat. With a clear view of the threat you face on a daily basis, cost-effective strategies can be developed to help mitigate these risks.