2024 Verizon DBIR Insights and Thoughts

The Verizon Data Breach Investigations Report (DBIR) for 2024 was recently released. It’s a must read of those in cybersecurity. It gives great insight into the overall threat landscape and then breaks it down by industry. Working in healthcare this is important because while ransomware grabs the news a bigger concern may actually be insider threat. This is highlighted even more this year with new requirements around reporting on security incidents and breaches insider threat and specifically the Miscellaneous Error category. My random thoughts from the report are below with a lean towards healthcare.

Insights and thoughts on the Verizon DBIR

Vulnerability exploitation on the rise

Exploitation of vulnerabilities tripled from last year. I’ve read similar numbers from other trend reports and it makes sense. As organizations get more controls in place such as Multi-Factor Authentication (MFA) and people get better at identifying phishing (later in the report) attackers will pivot to other ways of getting in. We’ve already seen a rash of vulnerabilities in network appliances over the last several months that could allow attackers into the network.

Human Element Calculation Change

Privilege misuse was removed from the human element calculation which means the human element metric dropped to 68% instead of 76% if it were kept in this year. I’m a little torn because I still believe it’s human element misusing privilege. The idea is to align their security awareness recommendation better. From that angle I get it because privilege misuse is more intentional regardless of security awareness training.

Added third-party vendor and supply chain issues

This is a good one to add. As organizations get better at defending attackers will look to get in via third-party vendor or supply chain issues. Which really isn’t a new concept see: Target breach or the Trojan War. A good third-party vendor risk management program is essentially to keeping organizational data secure.

Errors Increases due to mandatory breach notifications

Errors increased to 28% this year. Internal actors increased from 20% to 35%. Organizations that don’t have to report won’t. In healthcare if a breach is under 500 records then reporting doesn’t have to occur, so there’s even more Errors not being reported. I expect more regulation will make this number continue to grow for healthcare . This will hopefully highlight and shift focus to finding solutions to the insider threat problem. Yes, there’s Data Loss Prevention (DLP) but it’s a pain in the ass to get in place.

Meme created by ME!

Security Awareness is Improving

20% of people are reporting simulated phishing emails and 11% are reporting after clicking. That’s positive improvement. I also really like that the report focused on report rates and not clicking. Click rates can fluctuate depending on the difficulty of the phish and the time of year. Too much focus is put on clicking when what’s really needed is an improvement in reporting.

Reporting gives the security team an opportunity to respond to an incident sooner. I always tell people that clicking doesn’t bother me. Did they report it? It’s much easier to respond now, than several weeks later when there’s a bigger issue. Encouraging reporting, even when a click happens, also helps build a more positive security culture. We’re all human and make mistakes. I’ve fallen for my own phish before.

Generative AI Not as much of an issue as we thinK

It’s recognized that AI is helping attackers in writing phishing email and malware and being deployed in political campaigns but it’s not being used in way that is significantly contributing to breaches. This is why I love the Verizon DBIR. Despite the news headlines and play on social media AI and all the awful things it can do is not currently having a measurable impact. It’s certainly still something that needs to be discussed, understood, and controls put in place, but it may be better to focus on efforst that may make a more substantial impact such as vulnerability management and security awareness.

Distributed Denial of Service is the top action in incidents

This is where understanding the verbiage of the report is important. Incident vs breach. Breach is a loss of data. An incident is a security incident that may not involve data being stolen. Hence, DDoS isn’t about taking the data it’s about taking the service offline for an extended period of time. This shocked me a little. DDoS is still happening and it’s impacting a lot of organizations. Having mitigating controls and a plan in place to respond is important for any organization.

Jen Easterly comments on vulnerabilities and the need to shift focus

“...recurring classes of software defects to inspire the development community to improve their tools, technologies, and processes and attack software quality problems at the root.”

Quality code is secure code is something I’ve been preaching for years. If the quality is there then the security will be there. It’s in the documentation. When developers don’t follow best practices and the documentation that’s when vulnerabilities get created. The reason why security folks have a job is because people aren’t developing, coding, or configuring things right in the first place.

I like that Jen is taking a more broad view and it’s not something I’ve thought about. Instead of focusing on individual vulnerabilities or bugs we should go a level up. Every organization is different and every development team is going to have different issues with certain quality issues. We need to be looking at the class of bugs and trying to solve for the large grouping of vulnerabilities. This will help the development community identify where they can make improvements in their tools, technologies, and most importantly processes.

Social Engineering Section

BEC attacks had a median transaction of $50,000. They have a great graph that shows most organizations can get their money back by reaching out to law enforcement. I had a great conversation with Jayson E. Street recently on the Exploring Information Security podcast on social engineering and he had a great idea to send everyone involved in financial transactions a card with a code word on it. If that code word wasn’t authenticated then it’s very likely a BEC attack. I love the simplicity of the solution and I think it can make a good impact.

WEB APPLICATION ATTACKS SECTION

Credential stuff and brute force attacks are the most common against APIs. Authentication and authorization are the biggest issues for APIs, not so much injection vulnerabilities. This improves security but also means permissions should be top of mind when developing APIs. Things like MFA and rate limiting also need to be in place to help mitigate the potential of a breach. 1000 credentials are available online daily for $10. Credentials are cheap and easy to come by.

Free gaming currency lures lead malicious NPM packages was not something on my radar. This is the younger generation looking to make a fast bUck in the gaming landscape. Unfortunately, they’re downloading malware. Typo squatting was second. From the report it talked about packages checking external repositories before internal. It’s always better to try and build an internal repo system that pulls updates from the known good repositories. This is easier said than done.

Miscellaneous ERrors

This is often overlooked by organizations. Insider threat is the bigger concern in industries like healthcare where people are handling personal, health, and financial data. There’s a lot of data flying around. More than 50% was due to misdelivery which means people sent sensitive information to the wrong party and often non-malicious.

87% of users accounted for errors. System administrators go from 46% last year to 11% this year. System administrators largely accounted for internal threat issues due to misconfiguration. They’ve tightened up but it also highlights how under reported user errors were.

Data Loss Prevention (DLP) is huge to help prevent this. The problem is that DLP is a pain in the ass to implement. I hope that highlighting how big of an issue insider threat will encourage companies to try and tackle the problem in more creative ways.

Healthcare Industry

I’ve already talked a lot about healthcare above. Miscellaneous Errors regained the top spot after being second to system intrusions last year. I would expect system intrusions to continue to decline in next year’s report due to law enforcements increased involvement in taking down ransomware gangs. Privilege misues was second. This is the more malicious actions internal threat actors are taking. System intrusions were third.

Conclusion

The 2024 Verizon Data Breach Investigations Report (DBIR) is a must read. It provides critical insights into the evolving threat landscape, particularly emphasizing the increasing complexity of cybersecurity challenges across various industries. It’s a good anchor point for challenging assumptions about the biggest risk to our own organization.

As cybersecurity environments become increasingly complex, the DBIR’s insights are invaluable for professionals seeking to bolster their defenses and anticipate potential threats. The report serves not only as a tool for understanding but also as a catalyst for implementing robust security measures tailored to specific industry needs. For those in cybersecurity, especially in sectors as sensitive as healthcare, the DBIR is an essential resource that supports ongoing efforts to protect sensitive information and systems from both external and internal threats.

Demystifying the Dark Web: Challenging the Myth of a Hidden Internet

I’m still adjusting to my new role as Sr Specialist of Security Awareness and Training at Acadia Healthcare, so things have gotten behind on this site. Behind the scenes I’m still recording and editing episodes and I’ve got some really good ones coming up. I still want to post content on this site and try to get one blog post out a week. I have some ideas to do that with the time allotted and one of those ideas is AI. This article was entirely written by AI.

I would love feedback in the comments below if you liked or didn’t like and if you feel there are any corrections that need to be made. I have read over it and thought it did a pretty good job but my experience is limited on the “Dark Web.”

The dark web is often portrayed as a shadowy underworld of the internet, a place where anonymity reigns supreme and illicit activities thrive. This portrayal has been popularized by media and folklore, painting a picture of a digital "no-man's-land" inaccessible to the average user and law enforcement alike. However, upon closer examination, the assertion that the "dark web doesn't exist" can be a provocative way to challenge misconceptions and misunderstandings about what the dark web truly is and what it represents.

Understanding the Internet's Layers

To debunk the myth, it's essential to understand the internet's structure, which is more nuanced than a binary division between the "surface web" and the "dark web." The internet is better described in layers, with the surface web comprising websites indexed by search engines. Beneath this lies the deep web, which contains unindexed content like private databases, academic journals, and secure personal accounts. The dark web is a small portion of the deep web, accessible only through specific, anonymizing networks like Tor.

The Dark Web: A Concept, Not a Place

One critical argument against the dark web's mythical status is the recognition of it as a concept rather than a physical or digital "place." The dark web refers to the use of anonymized networks to access content and services that are either intentionally hidden from the surface web or require specific software to access for privacy and security reasons. It is not a separate internet but part of the broader, intricate ecosystem that constitutes the web.

The Role of Anonymity and Privacy

The dark web's existence is often justified by its role in protecting anonymity and privacy. Activists, whistleblowers, and those under oppressive regimes use it to communicate safely. This aspect challenges the notion that the dark web is solely a haven for illegal activities. It serves a crucial function in facilitating secure communication, underscoring that its existence is not inherently malevolent but rather a tool that can be used for good or ill.

Misconceptions and Exaggerations

The sensationalization of the dark web contributes to its mythical status. Stories of nefarious activities and marketplaces often overshadow the less dramatic, yet equally important, uses of the dark web for privacy and security. By challenging the existence of the dark web as a singular, monolithic entity, we can shed light on the realities of digital anonymity and its implications for society.

Conclusion

The assertion that "the dark web doesn't exist" serves as a starting point for a more nuanced discussion about the internet's complexities and the importance of privacy and anonymity online. It invites us to reconsider our preconceptions and understand the dark web not as a hidden den of iniquity but as a component of the internet that reflects the diverse needs and ethical considerations of its users. In demystifying the dark web, we confront not just the technical realities of the internet, but also the broader questions of rights, freedoms, and responsibilities in the digital age.

Tools and resources for effective Threat Modeling

My presentation for this year is Threat Modeling. My first stop is the 2024 Palmetto Cybersecurity Summit Feb 21-22, 2024, in Columbia SC. I’ll also be speaking at BSides Nashville May 11, 2024, and ShowMeCon May 13-14, 2024.

Getting Started

We’re going back to kindergarten people! We’ll get to draw shapes and lines and use different colored markers! To get started all one needs is a whiteboard and markers. Building out a diagram is the first step. As I mentioned in the Basics of Threat Modeling blog post having one prepared prior to the session will help expedite the process. Unfortunately, if there isn’t an existing diagram one will have to be done during the session. Adam Shostack has a description of the symbols and elements to use in a threat model on his GitHub page. They’re very simple and that’s the intention because threat modeling an application or process can get very complex.

Adam Shostack - DFD3 - https://github.com/adamshostack/DFD3

If the session is virtual and not in person the same principles applies. All popular video conferencing has a whiteboard feature on it that can be used for threat modeling. There are third-party options as well including:

• Microsoft Whiteboard (Usually free with corporate account)

• Microsoft Visio (License required)

• Microsoft Threat Modeling Tool (Free)

• OWASP Threat Dragon (Free)

• Draw.io (Free)

• Miro (Free version)

• Lucidchart (Free version)

• MURAL (Free version)

• Whimsical (Free version)

The tools I’ve had experience with are Microsoft’s Whiteboard, Visio, and Threat Modeling Tool. Visio and the Threat Modeling Tool get into a lot of detail and can feel complex if you’re just getting started. The more important thing is learning the methodology and approach to threat modeling. Threat Dragon has a lot more simplicity. It is open-source so doesn’t have all the bells and whistles of other tools. It can take a little to get used to using. I’ve seen developers create diagrams with Draw.IO. It’s simple and easy to use but be mindful that if they build it on a third-party website they may be putting internal organization information on the internet. I have not used Miro, Lucidchart, MURAL, or Whimsical but they look similar to Draw.IO. Leave a comment below with your favorite white boarding tool.

Automated threat modeling tools

I have only used Microsoft Threat Modeling Tool and OWASP Threat Dragon for automating parts of the threat model process. Microsoft’s Threat Modeling Tool get’s very granular and tries to be exhaustive on attack scenarios. If you like digging into a lot of details it can be a very useful tool. OWASP Threat Dragon is a much lighter version of that which is why I used it a lot more. For me I wanted the group to come up with their own attack scenarios because it allowed them to exercise their security muscles and build a stronger security mindset. This impacts the other areas of their day-to-day work. As their working they’ll be thinking about security.

There are other commercial and open-source tools that promise one-click threat modeling. I have not had an opportunity to use them. Here are some popular ones I found:

• IrisusRisk

• Threat Modeler

• SecuriCAD

• SD Elements

If you have used one of these or another leave a comment below.

Educational Resources

The book I always recommend is Threat Modeling: Designing for Security by Adam Shostack. It is “THE” book on threat modeling. What I love about the book is that after the first chapter it says to just start threat modeling. It’s more of a companion book for learning and maturing the threat modeling program.

OWASP is another resource for threat modeling. They have an entire project on everything you need to know about Threat Modeling. The OWASP Cheat Sheet is also a great place to start and a good reference point while maturing the threat modeling practice. Finally, an exhaustive list of threat modeling resources can be found at Awesome Threat Modeling on GitHub.

Leave a comment below with resources or tools you recommend. If you’re interested in seeing a version of this talk check out the ColaSec Meetup page as I will be presenting on threat modeling at the February 20th, 2024, meetup. A virtual option for attending is available.

How to build a phishing program

The first thing I recommend, is reading Phishing Dark Waters by Christopher Hadnagy, Michele Fincher, and Robin Dreeke. They have a lot of great insights on phishing and how to build a program and I used the book as a guide to build my own. One of the ideas in the book that really helped give me direction for building the program were the metrics. The book broke metrics down into four categories:

• Clicked and Reported

• Clicked and Didn’t Report

• Didn’t Click and Reported

• Didn’t Click and Didn’t Report

The idea of a phishing program is to reduce click rates and increase reporting rates. These metrics helped establish goals and strategies for building and running a successful phishing program. Using these metrics as a guide we were able to reduce click rates and improve reporting rates by over 50% at a company with over 6000 employees. Below we’ll get into getting started, the mindset to have, how to mature the program, and metrics and reporting.

Getting Started

Leadership buy-in

The first thing needed is leadership buy-in. The higher up the leadership buy-in the more effective the program. If buy-in isn’t at the highest level don’t fret. Once the program is started leadership will start to buy-in once they see the metrics. Metrics have a way of providing valuable insight into the risk associated with phishing attacks for the company.

Who to tell

Before sending a phish you need to inform the people that will help keep the phish from becoming a full blown incident. This can vary depending on the organization. Some will want very few people to be told. Others will want legal and HR input. The essential people that need to be involved is the person you report to and the Security Operations Center (SOC) and help desk managers.

The SOC and help desk managers will need to determine if their people need to be told. The SOC and help desk should be included in the phishing simulation, other times it might be more beneficial to let them to know. Often, they managers will want to see how their directs respond to a phishing email report. For larger phishes it’s a good idea to inform the help desk but for more targeted phishes they may not need to be told. There’s also always the option of making them a targeted phishing group.

Automation

Sending out phishes will increase the workload on other departments like the help desk, the SOC, and anyone monitoring the security inbox, if that’s not already the SOC. Automation is a friend here. Setup automated responses wherever a phishing email may be reported.

We didn’t do this for our first phish of the company and had over 500 people report the email. I responded to every single one of them because it was my miss and I wanted to acknowledge and show people appreciation for reporting a phish. If they’re not acknowledged and thanked they’ll be less likely to send in a phishing email in the future.

Recognize people who report phishing emails

To make an effective phishing program people need to be recognized and thanked for taking the time to identify and report a phishing email. If there’s a platform where employees can send other employees praise or recognition I would load anyone who reports a phish in there. People need positive feedback to continue the positive behavior.

Also, it’s okay if people tell each other about the simulated phish. We want others getting into the habit of giving their peers and co-workers a heads up that they have a phishing email in their inbox. Simulated phish or real phish people giving each others a heads up is a good thing.

Create your first phish

To start pick something super dumb that has a lot of indicators that easily identify it as a phishing email. This will provide a baseline for the overall click rate of the organization. It will help build the roadmap for future phishes. Establishing the baseline sets the starting point. As click rates go down the difficulty of the phishes can be increased and reported on. This will help show a reduction in risk to leadership.

The thing to remember about click rate and phishing emails is that there a lot of factors that go into clicking on an email. The time of day, the stress levels of people, what’s going on at work and at home, and luck. Who get’s sent a phish, time of day, and the type of phish are the only things in our control. Click rate is volatile. I’ve seen a monthly phish get a 2% click rate. I’ve also seen a monthly phish get a 14% rate. Pay attention to the time of year and what might be going on inside and outside the organization.

Deciding on whether to blast out the email or schedule it over a period of time is going to be very important. For larger groups you want to schedule the phish over a period of time. I would phish the entire company monthly. They’d get the phish at random times throughout the month. For smaller groups I had the option of sending them the phish all at once. Sending out a phish to several thousand emails in one day that will not make you any friends with the SOC or help desk, especially if automation is not set up.

What’s off limits

Even if your CEO gives you free reign, like I’ve had in the past, you do not have free reign. GoDaddy got in trouble for a phish in 2020 that the security team sent. The lure was a $650 holiday bonus. After people clicked they instead got told they were assigned extra security awareness training. While the bad guys may use this type of technique or other types of phishing emails we as the good guys should not stoop so low. That type of phish is getting people’s hopes up and then bringing it back down. This will result in an angry reaction.

Anything dealing with financial, family members, politics, religion, or sex are off limits. These topics create an extra strong emotional reaction from people. I also wouldn’t mess with anything related to marketing or other departments needing to get employees engaged. Any of these will be sure to get you in political hot water. Even if you get backed up by the CEO that group may have to accept it, but they won’t like it and will look to sabotage the program.

The phishing program is something people in the organization should understand is here to help. It’s already hard enough to get people to buy-in and feel good about security. Pissing them off won’t help the program and may even result in it being hamstrung. That’s why it’s important to remember that a phishing program is practicing for the real thing. It’s not the game of “Gotcha!” it’s practice.

It’s about practice

From Ted Lasso

The phishing program is about practicing the activity of receiving and responding to a phishing email. Getting people to get them doesn’t help and can put the phishing program in choppy political waters. That’s why the program needs to tie back to something real world.

Dig into your email gateway and look for phishes that are being caught in there. Check the security inbox to see what actual phishing emails are being reported there. Look for ones that are of a general nature for the entire company. Pay attention to the news and what are some of the latest phishing emails being sent to people. Think about the time of year. Packages are flying around during November and December. The phishing platforms do a good job of adding new templates with the latest phishing emails they’re seeing. Make it relevant.

Targeted phishes

Targeted phishes are phishes that are sent to a targeted group. The purpose should be specific to the department or group of people and related to techniques attackers may use to try and get into an organization. Again, look in security tooling to understand what certain groups are being targeted with and research phishes in the news that relate to the company’s industry.

Depending on your organization you can go outside of the parameters of making it related to outside news events. In the past I’ve seen phishes using Game of Thrones and the latest Avengers movies as lures. These were sent to groups who were aware of the phishing program and did a better job of identifying phishes. For targeted phishes like this make sure to host training afterwards to discuss and reiterate the practice aspect of the phish.

One of the most successful phishes I ever did was part of a lunch and learn session. The phish got a 50% click rate and it wasn’t even my idea. As part of the session I asked the people in attendance for ideas for a phish to send to IT. We had a praise platform that you could use to send people praise. So we decided to do a phish that used one of the notification emails for getting praise. Then we made it look like it was from the CEO. We did add several indicators that it was a phishing email such as giving them a nonexistent praise and an obvious link if you hover over it. We got clicks almost immediately during the session.

Later that day I was visited by a couple of directors in the IT department who said they had never fallen for an internal phish before at any organization. I avoided severe political backlash in this situation because they were in a group with a low click rate and they had access to the lunch and learn where we did the phish. In another organization this could have caused a lot of issues.

Despite conducting phishes as a way to gather information and reduce risk in the organization we are still going to bruise some people’s ego. Which is why we need to be thoughtful and careful about the phishes we send.

Increase the difficulty

As the click rate goes down, increase the difficulty. Determining if you can increase the difficulty should be from a reduced click rate from a period of over three or more months. Month-to-month click rate can be volatile. To increase difficulty reduce the number of indicators in a phishing email. If you started with five indicators reduce it to four. This allows the phishing emails to have levels of difficulty that can be reported on.

Indicators can be anything from reducing misspellings to making domains look a lot more legitimate. We’ve used domains that were bought to protect the company from typosquatting attacks. We loaded those into the platform and used them when we needed to increase the difficulty of phishing emails.

Reporting, Metrics, and extra training

As mentioned above, I like to use click rate and report rate. Other statistics don’t provide as much insight. The phishing platform may not have those statistics as default which means some excel jujitsu will be needed to get the metrics worth reporting up.

I never liked calling out individuals unless they were flagged multiple times as repeat clickers and put the company at a significant risk. In that case a conversation with their manager and HR is useful. One of the things I find useful was to group click rate and report rate by department. Grouping departments gives people an out but still allows large groups of people to be reported up if they’re having trouble with phishing emails. Leadership liked this grouping as it provided them with good insight into which departments were struggling with phishing emails. This also motivates departments do better because they don’t want to be in the top 10 click rate and want to be in the top 10 for report rate.

As far as training, I didn’t like assigning extra training from the phishing platform unless there was buy-in from the top and could be tied to something performance wise from an HR standpoint. If I assigned training without any sort of outcome, people could ignore the training and not have any repercussions. I do still think training is important and preferred in-person training because it allowed me to walk them through the phish and allow them to ask questions. I found that the groups I got to work with in these training sessions did a much better job with phishing emails. Those sessions can also be recorded and put into a LMS platform.

Summary

A phishing program can be a powerful security awareness tool for an organization. It should look to decrease click rate and improve report rate. The first phish should set a baseline. Increase the difficulty as click rates go down and report rates go up. Try to tie phishes to relevant phishes that is being seen in the company’s security tooling. Even with free reign certain phishes are off-limits. The CEO might be okay with it but everyone else will start to harbor bad feelings towards the phishing program and security and will look to undermine it when possible.

Identify what metrics are important and put those together to be reported up. Creating top 10 lists for departments is a great way to gamify the reporting and get people to more actively participate. Finally. remember this is about practice. Anyone can fall for a phish if the right factors line up. Taking an empathetic approach will help with making the program more engaging and effective.

Drop any questions you may have in the comment section below or reach out via the contact form.

This post first appeared on Exploring Information Security.

Web Application Testing: PortSwigger Burp Suite vs OWASP ZAP

Both OWASP ZAP and Portswigger Burp Suite are exceptional tools designed to identify vulnerabilities in web applications. I’m one of those oddballs that prefer ZAP over Burp Suite. Most (95%) of penetration testers and application security engineers prefer Burp. We’ll dive into the history and differences below.

History

OWASP ZAP is an open-source web application security scanner. Ideal for beginners and intermediate users, it offers an intuitive user interface and a wide range of features. ZAP is particularly known for its active and passive scanning capabilities, spidering, and a powerful REST-based API. Being a community-driven project, it's continuously updated with new features and security tests.

I started using ZAP when I was asked to stand up an application security program for an agency I was employed at in South Carolina. I knew nothing about application security but quickly found the Open Web Application Security Project (OWASP) and a free tool for testing applications the Zed Attack Proxy (ZAP). With the tool I found my first vulnerability, blind SQL injection, which kick started the application security program at the agency. Nearly a decade later the developers are still using ZAP to test their applications prior to it going to production.

According to ChatGPT:

Burp Suite, developed by PortSwigger, is a more comprehensive suite of tools. It includes an advanced set of features like detailed manual testing tools, automated scans, and the ability to save and resume sessions. Burp Suite comes in various editions, with the free version offering basic functionalities, and the professional version providing more advanced capabilities.

This is the view of most professionals within the testing space of security that I’ve interacted with. A lot of this comes from the history of ZAP which was a fork of another open-source proxy called Paros Proxy. Development is no longer done on Paros but ZAP is still being developed and has a lot of community support.

A lot of the features mentioned about by ChatGPT ZAP has as well. The tools are 90% the same with some slight nuances in functionality. Either tool will test an application sufficiently.

ZAP vs Burp

ZAP was written by a developer named Simon Bennetts. I had the pleasure of having Simon on for the eighth episode of Exploring Information Security. I’ve used Burp throughout my career. First as part of training courses such as Tim Tomes’ Practical Web Application Penetration Testing (PWAPT). I tried it as part of my day-to-day work but I would usually fall back to ZAP. I found the interface of ZAP more user friendly and I’ve heard people who prefer Burp confirm that they liked some of the organization of the interface.

Burp is still a fine tool it just takes a little more time to get used to the interface. Having used ZAP that was just my preference. I’ve used both in assessments and found the findings very similar. The plugin ecosystem is a more robust but ZAP has plugins and they are kept up-to-date regularly. Both are well documented tools and easy to go through and learn. Portswigger offers a lot of free online resources for learning how to use the tool better and is probably a large reason why a majority of testers use it.

I like ZAP for developers because it was written by a developer and it’s free. Burp has a community version but it’s automated scanning is rate limited unless you have the paid version. You can get the testing done it just takes longer. One of the features I’ve heard proponents of ZAP appreciate is the Forced Browse feature which does a good job of finding directories in an application.

Final thoughts

Either tools is good for testing web applications. It really comes down to preference and the situation a person is in. If you’re looking to get developers more involved in testing ZAP is a great fit. If you’re looking for a specific plugin for testing Burp will probably have it. Results are going to be very similar.

What’s your preference for web application testing tools?

This blog post first appeared on Exploring Information Security.

Created with the help of ChatGPT

Log4Shell, is it really an issue at this point?

I thought reading the Veracode State of Log4j Vulnerabilites: How Much Did Log4Shell Change? by Chris Eng would be a bit of FUD (fear, uncertainty, and doubt). I was pleased to see that it wasn’t. They provided some great numbers on Log4J and remediation efforts. I was also happy to see them recognize that developers fix vulnerabilities when alerted about them quickly. This is something I talk about a lot in my presentations and with security folks. Developers want to get this right and having right approach and empathy with vulnerability management will get them to buy into these efforts.

The next line though says that the data contradicts the developers response because there is so much Log4j out there. Reviewing the CVEs in the article most of the remaining Log4J is in other packages. This is a problem with packages and open source. A package can be buried in another package. This was highlighted several years ago with the left-pad incident. A disgruntled developer removed a small bit of code that added a left-pad to the side of a website from NPM. It took down thousands of website because that line of code was buried in other packages.

This is why security needs to take a balanced approach to vulnerabilities and not lean only on severity rating. We need to be building proof of concepts. The reason why Log4j was such a massive thing was because it was buried in other packages. While it might be in another package it might not be used or accessible by attacker. In the case that it was it’s important to understand what it gives an attacker.

This is where the balance comes in for security. Just because the vulnerability is an 8-10 severity doesn’t mean that’s it’s actual severity in each environment. If it’s note exploitable it’s more like a 1-3 severity. Which moves it down the priority list of vulnerabilities of which there are usually hundreds of thousands.

Don’t get me wrong you want to get those vulnerabilities addressed but the timeline for getting them addressed changes. When I was leading the effort for Log4j remediation in our environment we used the pentest team to find what was exploitable externally. After remediating those vulnerabilities we looked internally. Most vulnerabilities could be patch but internal couldn’t be updated immediately and required a larger upgrade to accomplish. This is where we established timelines with those teams to get the vulnerability remediated because we knew what needed addressing immediately and what could take more time Just a blanket patch it all now would interrupt business processes, projects, and create hard feelings.

It’s good to note that Log4j is still out there and probably extremely important for companies to patch. Security needs to identify how much of it is actually vulnerable and work with other departments and teams to figure out the best timeline. Development teams need to be focused on more immediate issues such as the Atlassian server having a vulnerability or the latest malicious NPM package. Those are more important than a two-year old vulnerability that may or may not be exploitable. If it is exploitable go patch now!

Chucking vulnerabilities over a wall to developers is never a good strategy and will waste a lot of time and effort and degrade trust between departments.

If you are in need of consulting services on vulnerability manager or application security click the contact button below and reach out. I’m happy to have a conversation about your struggles and identify how I can best help.

This blog post first appear on Exploring Information Security.

Interesting security reads: AI, Typosquatting, and Okta

Increasing transparency in AI security - Google Security Blog - Interesting article on AI security and how it falls pray to the same supply chain attack as the development lifecycle. It goes over how Sigstore and SLSA can help improve the security of the AI development lifecycle.

Have I Been Squatted - This is from the Risky Biz News and looks like a very interesting tool for companies looking to identify if they have any domains being typosquatted that could be used for phishing attacks.

The Okta story continues - Krebs on Security - The plot thickens. All Okta customers were impacted by the breach. Full name and email address were stolen. This is valuable information for attackers looking to phish IT administrators that have permissions into their Okta tenant.

IceKube - WithSecure Labs - This is an interesting tool recently released that checks Kubernetes environments for attack paths. Then it provides a graph as a visual that allows you to see the attack path. This could be very useful for teams looking to understand an environment.

Guidelines for secure AI system development - National Cyber Security Centre UK - AI is a bit of the wild west at the moment but as governments get a better handle on the technology they’ll start putting regulations and controls in place. Guidance is usually the first step and it’s worth paying attention to if products or companies are starting to use AI in a specific company or globally.

This blog post first appear on Exploring Information Security.

Implementing Dynamic Application Security Testing (DAST) Tools into the SDLC

One of the questions that always came up at the end of my API talk was around Dynamic Application Security Testing (DAST) for APIs. I mention DAST in the talk but never really went more in-depth due to time constraints. The questions usually revolved around vendors. In this post I want to talk about how DAST works, I’ll mention vendors from my experience, and finally I’ll go over implementing DAST in the Software Development Lifecycle (SDLC).

HOW IT WORKS

DAST tests an application when it’s stood up and running, usually in a test environment. The test itself looks for the low hanging fruit because it’s running automated tests with no context or awareness of the business function of the application. It will run the same test against a finance system as well as an operational system. This tool is not a replacement for manual testing.

The tool will simulate what an attacker might do to an application. It will check for injection vulnerabilities and weaknesses within connections and protocols to the application. Again low hanging fruit so it will struggle with more involved techniques and misses simple things like URL enumeration and other abuse cases. Overall this tool is a great starting point for applications as it’ll capture a lot of the low hanging fruit but it won’t go much more in-depth than that.

Vendors

OWASP has a list of Vulnerability Scanning Tools AKA DAST available. The main ones I usually recommend are Tenable, Rapid7, and Invicti because I have familiarity with them. I always recommend evaluating multiple vendors before deciding on one. If you’re needing a DAST because of compliance reasons, I’d suggest Tenable or Rapid7 depending on which vulnerability management suite you already own.

If you’re wanting something for more than just compliance look at Invicti because that’s their only focus. This allows them to focus solely on the DAST technology. A Tenable or Rapid7 is looking at providing other security solutions not just DAST. From a low-cost perspective OWASP ZAP or BurpSuite are two free options that can be run manually or setup to automatically run in a CI/CD pipeline. The cost here is a resources time for learning and setting up the open-source tool.

IMPLEMENTATION

DAST is the easiest application security tool to setup in an SDLC. You need a URL, some login credentials, and a timeframe to scan. I recommend scanning as close to production as possible. Scanning in production is never a good thing because it’s throwing a lot of malicious types of attacks at an application. This can cause issues such as taking down the application or putting a junk data into your production environment databases. Scans can be setup to not be as aggressive but then it ends up missing vulnerabilities.

Scanning in a User Acceptance Testing (UAT) allows scans to run at the most aggressive level and not impact production. That is as long as the database isn’t shared with production. The only catch here is finding a time to run the scan so it doesn’t impact user testing. Scans can be setup to run in the afterhours.

The frequency of scanning should be based on how often code is released to UAT. If development is on two-week sprint then it’s reasonable to setup scans to run every two weeks. Some industries only require scanning applications once a month and that’s fine as well because as the vulnerabilities are addressed the need for DAST becomes less important.

Boom! Done!

Not so fast my friend!

Now that we’re scanning we need someone to look at and tune the results. This person should ideally be someone with application security experience because they’ll need to understand how the application woks or willing to dive in and learn. DAST has false positives. Not as many as a Static Application Security Testing (SAST) tool but it will have some. If results are taken from a DAST tool and sent to developers without any sort of vetting it will either tick off the development team or not get addressed. Often times both scenarios are the response.

If an application security person or someone willing to learn isn’t available then setting up a meeting with the development team to share findings and ask questions will go over a lot better. Developers are good people and love talking about their code (baby) and they’ll want to make sure it’s protected from the bad guys on the outside. This meeting will need to be a regular one for any new applications loaded into the DAST. As the vulnerabilities get tuned or addressed the meeting can be less frequent. As trust is built the meeting can become an email unless there’s some misunderstanding or a more complicated vulnerability needs to be addressed.

Summary

DAST is easy to setup but it’s the last tool to be kicked off. As more security tooling get’s implemented and the program matures the importance of DAST becomes less. It’s still a great starting point for any application security program. Always evaluate multiple DAST vendors. If it makes sense to go with a DAST that is already part of a suite of other tools then go with that.

The strategy for implementing DAST is the same for web applications as it is for APIs. You won’t see as many results for APIs because their use is more restrictive than a website. The main concern with APIs is authentication and authorization issues. DAST will be able to call out weak protocols but it will not be able to identify if a person has the access they need. Remember to work with the development team on getting DAST setup because their help will be needed for addressing vulnerabilities.

If you’re looking for an API vendor focused on testing, I’d recommend 42Crunch.

Drop a comment below if there are any questions or other topics you’d like me to cover. If you’re interested in services I have sponsorship, consulting, and speaking engagements available. Reach out via the contact form.

This blog post first appear on Exploring Information Security.

Social Engineering is making a come back

History always seems to repeat itself.

History of social engineering

Ransomware has been around since the late 1980s. Social engineering has technically been around since the advent of human communication. In the context of technology security it’s been around since phreaking techniques were used in the 1960s and 1970s as a way to take advantage of phone systems. Today it’s phishing, vishing, smishing, and much more. It’s been around but not the main technique used to get into an organization, well until now.

It seems as vulnerability management and incident response improves attackers are switching to social engineering via phone. I recently heard from a friend about another friend who got all their work logins compromised via an attacker calling into the help desk and resetting his password and MFA. This comes on the heels of the MGM and Okta breaches.

MGM

Like the movie Ocean’s 11 attackers used social engineering techniques to obtain access into MGM system by impersonating an employee and calling into the help desk to have their credentials reset. This resulted in ransomware being deployed in their environment and costing the casino hundreds of millions of dollars.

Okta

The compromise of access tokens via the Okta’s customer support unit is probably even scarier because Okta holds the keys to a lot of other organizations. This breach gives attackers information to pivot into other organizations.

What’s next for social engineering

When attacks like the two examples above are successful and result in lots of money and infamy others start copying the techniques used. I would expect us to continue to see attacks like these going forward which means more focus will be needed on security awareness. Groups like Scattered Spider are already starting to pop up and their focus is on social engineering their way into organizations. Then with that access ransomware gangs begin deploying ransomware. This highlights a need for good detection procedures and technologies. We’ll probably also see more difficult controls put in place to protect accounts. This will degrade our account access user experience as a side effect.

Resources for Social Engineering

Social-Engineer: This is a company started by Chris Hadnagy focused on social engineering. They provide resources and also assessments for an organization that focus on social engineering. He’s written several books as well on the topic that I highly recommend.

One of those books:

"Social Engineering: The Art of Human Hacking" by Christopher Hadnagy: This book delves into the psychology and techniques of social engineering.

Krebs on Security is a great blog to follow in general. He covers a variety of topics mostly around breaches.

This blog post first appear on Exploring Information Security

The future of AI and security

Artificial Intelligence (AI) is quickly changing the landscape for all of our society. It will significantly change our way of life over the next 10 years similar to how computers and mobile devices impacted our lives. If you’re not getting familiar with it now you may get left behind. This website is really only possible because of AI and more specifically ChatGPT. I’m able to crank out articles and information way faster than if I were creating the website entirely by myself.

I note all the pages I’m creating with the help of ChatGPT at the bottom so people know when it’s me and when it’s AI. I’ll be doing the blog posts and AI will be helping me build out all the other pages. You’ll probably notice the difference pretty quickly. I’m noting because I expect laws to come out in the future that require disclosure if AI was used in the creating of content. This is similar to how bloggers had to disclose if they were getting money from an entity as part of a post or other content on their website. Let’s dive into the predictions.

The government will regulate AI

As mentioned above the government will step in to ensure AI is being used in an ethical way. I’m curious how using AI to create things will hold up in court around topics such as copyright and data usage. I was hesitant to create an entire website and other documentation using AI because I don’t know if it would be considered plagiarism or copyright infringement. Amazon recently came out and limited self-publishing books to three a day. I think there are unforeseen things that will end up in discussion around AI and it’s use that will require regulation.

With any document being able to be feed into AI there’s a question for companies around sensitive data being leaked. This can be intellectual property and more concerning people’s personal information. As we see incidents where AI is leaking this type of information the government will step in and adjust laws an regulations, if not make new ones.

Creators will shift from writing to editing

This includes people like developers who are already using ChatGPT to write code. While AI is not any good at secure code review it can help developers get started with writing their own code. This can be a good thing as long as developers use it as a starting point and don’t just shove it right into production.

There’s no reason not to use ChatGPT as a first draft for things. I’ve written security policies for a company with just a couple hours of using ChatGPT and editing the output. This can be a good thing for smaller companies who don’t have a security team. Also, ChatGPT is able to write things in a much easier to understand format. Reading company policies may get a bit easier. Which leads into the next predication.

This will disrupt documentation

If you’re in Governance Risk and Compliance (GRC) or some other discipline within security that focuses on documentation it’s a good idea to start getting familiar with ChatGPT. There are people already out there using it and their output is going to be significantly more than anyone not using ChatGPT. GRC will need fewer people to complete their work. The ones who embrace it will stay because their productivity level is higher.

Summary

AI is a step forward and I think it’s going to help in a lot of ways. Yes, there will be some bad things and misuses that occur but overall it’s progress for our society. People creating within the tech space will see the biggest benefit. It will reduce the amount of time it takes to get a written piece of code or document out the door.

As far as securing the data their will be the usual growing pains when a new technology becomes easily accessible to everyone. Guardrails and guidelines will need to be put around the data as leaking the data is the biggest concern for AI. It’s benefits though could be significant and so security will again have to balance innovation with keeping people’s information safe.

This blog post first appear on Exploring Information Security

Hacker Summercamp Fallout

Here’s some of the interesting things from Hacker Summercamp.

Lot’s of news articles on hacking AI because 2023 is the year of AI and it’s overshadowed every other topic (No, I’m not bitter my API talk has since been overshadowed by the dawn of the AI era).

NPR - What happens when thousands of hackers try to break AI chatbots - by Shannon Bond

TL;DR:

• 2000 people over three days participated

• Google, Meta, and ChatGPT provided their AI

• The outcomes from the contest are to strengthen guardrails, help policy makers, researchers, and the public understand how AI can go wrong

If you want the presentation slides from Black Hat they have them on their website.

There was of course some junk hacking. While it’s impractical, it is interesting research. This particular one is on hacking card-shuffling machines at casinos. Which I’m pretty sure they did in Ocean’s 13.

TL;DR:

• Report came out about some controversy around a poker game. Report said machine couldn’t be hacked

• Challenge accepted

• USB + USB port = pwned

Check out the Red Signal list on Twitter created by Jason Lang to see more fallout.

Also signup for the Risky Biz Newsletters. There’s some good nuggets on Black Hat and DEFCON in the one from August 15, 2023.

This blog post first appear on Exploring Information Security

Hacker Summercamp is over; let the fallout commence

Hacker Summercamp is a week long period at the beginning of August where the security community converges in Las Vegas to discuss all things hacking. I’ll have a page up to go into more details. One of the outcomes of the period is new vulnerabilities and attacks techniques are released in presentations. Some of it will be what’s called, Junk Hacking, which is interesting hacking that is very narrowly defined and usually has a small attack surface. Other security research released could have a significant impact organizations.

I’ll be watching for new releases throughout this week and write them up here. If you see anything interesting drop in the comment section below. If you went, drop your experience in the comment section below.

This blog post first appear on Exploring Information Security

Application Security resources for beginners

This is a continuation of my resource series of posts. Application security is the field I found a lot of interest in. This despite coming from the operations side of IT not development. Using the resources below I was able to get a job in application security.

Websites:

• Troy Hunt

• Open Web Application Security Project

I first realized I had an interest in appsec after reading a Troy Hunt post. Not only were things explained well, but I was also paying attention to every word in his blog posts. He has since branched out to more breach related content as the creator and maintainer of Have I Been Pwned. Still he has a lot of good appsec content. He has several courses on Pluralsight for beginners plus. He also does a weekly podcast that’s worth checking out.

The Open Web Application Security Project (OWASP) is the go to resource for AppSec. It’s a massive non-profit organization that has tons of projects, knowledge bases, cheat sheets, and more. There might even be a local OWASP chapter. There’s annual conferences to attend (I’ve never been). It’s the resource I recommend for people starting out.

Podcasts:

• DevelopSec

• Application Security Podcast

James Jardine puts on the DevelopSec podcast. The podcast is targeted at developers. It’s also consumable by security people. This podcast doesn’t release on a regular schedule. The Application Security podcast is also targeted at developers. It releases in seasons.

Training:

• SANS SEC542

• PWAPT

The first bit of AppSec training I got was the SANS SEC542 Web Application Penetration Testing and Ethical Hacking. It’s a lot of AppSec information, concluding with a Capture The Flag (CTF) exercise. I’d try to get your organization to pay for this as it’s several thousand dollars.

The Practical Web Application Penetration Testing course is a Tim Tomes course. He’s a former SANS instructor who puts on this training several times throughout the year in public and for organizations. It’s a great affordable course that Tim tries to keep up to date with relevant information.

The blog post first appear on Exploring Information Security

OSINT resources for beginners

I know what you’re thinking, “not another resource for OSINT.” This post is more focused on helping people just getting started with open source intelligence (OSINT).

This is the second of several resource posts I’d like to do that point people to some getting started resources. This is not meant to be an exhaustive list. Instead I’d like to highlight some of the resources I have found useful and use on a regular basis. This is meant more as a gateway into the deep field of OSINT.

Websites:

• Google

• IntelTechniques

• OSINT Framework

Google is the primary tool I use for doing searches. Learning how to Google Dork is one of the most useful skills to have in security, not just OSINT. IntelTechniques has a lot of useful tools for doing specific searches. OSINT Framework has over 1200 tools available for OSINT. Plenty of opportunity to fall into rabbit holes.

People:

• Josh Huff

• Tazz

• Micah Hoffman

• Justin Nordine

• Kirbstr

These are all people I’ve interacted with regularly or had on the podcast previously to talk about OSINT and threat intelligence.

Training:

• SANS SEC487

• Social Engineer - Advanced OSINT

• Justin Nordine’s course

I took SANS SEC487 earlier this year and it is exhaustive. Lots of information, tools, and methodology in the course. I also recently took Social Engineer’s Advanced OSINT course at DerbyCon. It’s a shorter and much more focused course. It provides opportunities to play with certain techniques (Google Dorking) and tools (Maltego). Recently, Justin told me he was doing an OSINT course. Follow him on Twitter (above) to keep up with dates and links.

Podacsts:

• OSINT on Exploring Information Security

I think this is the easiest way to capture all the podcast content. Plus, it keeps this blog post a little shorter and more streamlined. I don’t want this to be a super long post. The links I’ve provided in this post will lead you to other resources, tools, and ideas in OSINT.

How to get started with OSINT

Something to think about is use cases. Penetration testers use OSINT for assessing and organizations security aptitude. Investigators use it to track down people and companies. Incident responders use it to track malicious domains. Threat hunters use it to identify threats and risks to an organization. Those are some of the things I’ve used OSINT for working on a blue team. I’ve heard of use cases for police, insurance companies, and organizations looking to make acquisitions.

Methodology is also really important. It’s what keeps us from jumping too far down a rabbit hole. Dutch OSINT Guy has a good post on methodology. It’ll take practice and experience, so really just go do it and learn.

This blog post first appear on Exploring Information Security

Information Security resources for beginners

I wrote a recommended resources post back in early 2017. I’d like to update that, as the resources I recommend have changed. I try not to think of my podcast as something for new people to the infosec field. However, the people reaching out to me the most are people who are new to the field. So, I’ve given in and I want to start creating a series of posts directed at new people or those trying to get into the industry. These posts are meant as a gateway, not an exhaustive list.

These are the resources I find the most useful. With out further ado.

Websites:

• Krebs on Security

• CSO Online - Steve Ragan

Krebs is considered the public Intrusion Detection System (IDS) for companies. If you’re getting a call from him, it’s probably not good. He covers various topic primarily around breaches, skimmers, and unmasking malicious actors. I’m friends with Steve. He reports on a variety of infosec related topics. When something breaks on Twitter he’s one of the first people I check to get accurate information.

Podcasts:

• Risky Business

• Security Weekly

• Peerlyst list of podcasts

Risky Business is the best security podcast out there. It’s the podcast with the best content and quality. The podcast allows me to stay up with the latest infosec news. He’s got sponsored (gotta pay dem bills) podcasts that are just as useful. Security Weekly was the first podcast I listened to. It’s great for getting information and gaining an understanding of the hacker culture. After a while, for me, it turned into a bit of a boys club where they go off on tangents and genital jokes. Episodes are usually two hours long which sucks up a lot of podcast listening times. Finally, there’s the Peerlyst list of podcasts. It has an exhaustive list of infosec related podcasts.

Conferences and local user groups:

• BSides

• Meetup.com

Conferences and local user groups are a great place to learn, while also meeting people in the field. The security community is inclusive and welcoming if you put yourself out there. That means doing that awkward social thing. There is very likely a BSides near you. Most local user groups can be found on meetup.

Training:

• Irongeek

• Pluralsight

• SANS SEC401

Information security is an ever changing field. To stay relevant in the field requires curiosity and a willingness to learn new things. Before getting to that point, we need to learn the basics. Irongeek and Pluralsight help with the basics and staying up-to-date. SANS SEC401 is a general course that will provide a good foundation for any security professional. I thought I was above the course, as I was taking it three years into my infosec career (and several more in IT). I was so wrong. The course helped fill in a lot of gaps for me from a security and IT perspective. I highly recommend the course for beginners and those already in the field.

This blog post first appear on Exploring Information Security

Digging into the new NIST password policy recommendations

How do you feel about NIST recommendation that passwords should no longer be rotated and instead have a longer minimum requirement?

— Timothy De Block (@TimothyDeBlock) June 14, 2018

I've had a few instances recently, where questions around the new NIST password policy recommendations have popped up. It first happened last week when I was at ShowMeCon. The second question for our panel was around the new NIST recommendation for passwords. Then I had someone ask me about it in the comment sections on this site. I feel like there was another instance, but I can't remember it.

I tweeted out the poll above on Twitter. As you can see two-thirds of infosec professionals like it. I am in that camp as well. There was some great discussion on why it's not a good recommendation in the replies to the poll. Dave Chronister was also against it on the panel at ShowMeCon. I decided I wanted to dig into it a little more.

My understanding of it is that NIST recommends increasing the minimum requirement for password complexity and ditching the rotation of passwords every 90 days. The idea being that people are more willing to remember longer and more complex passwords if they don't have to rotate it as often. I've asked some people at work about this and they are in favor of not having to change their password as much.

I know how easy it is to either crack or compromise someone's credentials via a phish. The question I have is if anyone on a penetration test has had their credentials stop working because that person's password was 90 days old (If you've had this experience I would love to hear about it in the comments). In my view this new recommendation improves the user experience while asking them to improve their password. Someone would still need to rotate their password if compromised.

Before we get to far down user experience, lets take a step back and look at what NIST actually recommends. The guideline is NIST 800-63b. This is my first time reading it as I'm writing this post (and having a delicious home-brewed chocolate milk stout).

We're looking at section 5.1.1.1. There it says password lengths, "...SHALL be at least 8 characters in length if chosen by the subscriber." It goes on to say later, "No other complexity requiremnets for memorized secrets SHOULD be impost." There is no mention, specifically, of rotating passwords. My assumption is that it was removed from the documentation. According to passwordping.com it added the requirement to screen for commonly used or easily guessable passwords. Which I see in 5.1.1.2.

Based on that NIST is suggesting we ditch password complexity and rotating passwords, but keeping an 8 character minimum. I'm not sure I'm on board with that. I'd prefer to require longer passwords and ditch complexity and rotation of passwords. I think there needs to be a give and take here with passwords. We'll require less rotation of passwords (they're just enumerating anyways) for longer passwords. That doesn't seem to be the case with the new NIST recommendation.

I like the idea of challenging some of our old ways of doing things in the industry. I recently talked to someone about passwords. They were complaining to me about how many passwords they had to remember. I asked if they were using a password manager. They were not. That was a red flag right there that they were probably using weaker passwords. That also meant they were probably enumerating their password by numbers or characters. Which meant that even if they rotated their password you could probably guess the new one.

I am a big believer in practical security. I think it's a good approach. It's a good balance between meeting people's needs and getting security most of what they want. If ditching the rotation of passwords results in longer and stronger passwords I'm all for it. I like the idea of checking for commonly used or easily guessable passwords. I really like the idea of checking for compromised passwords from a site like Have I Been Pwned?

This blog post first appear on Exploring Information Security

Petya/NotPetya ransomware outbreak thoughts and links

While I wait for Nashville traffic to clear (picture above), I decided to take this as an opportunity to write up some thoughts and provide links for the current “ransomware” outbreak. I became aware of this on Tuesday and started monitoring the situation via Twitter. I thought it a good idea to create a list and add people who are providing the most useful information about the current outbreak. I figured it would be useful for future security related events.

There are already some good blog posts out there with what we currently know. SANS Internet Storm Center and Symantec Security Response have really good information. What I’d like to focus on is the idea that this is outbreak is a cover up for a nation-state attack. As I watched Twitter it seemed like a very particular set of organizations were getting hit by this ransomware. There were reports in several different countries and different types of organizations, but something didn’t feel right. I didn’t know anyone experiencing this event or see reports of local government or schools getting hit with this stuff. If there is truly an outbreak I would expect to hear about outbreaks in those areas. They run IT (let alone security) on a shoestring budget. All the reports seem to focus on those areas in Ukraine.

On my ride into work this morning the Risky Business podcast floated the idea that this was a targeted attack by a nation-state (Russia) at Ukraine (don’t call it “The Ukraine). Based on what I’ve seen it makes sense. Furthering the idea is Matt Suiche who wrote up an article on Petya as a wiper not ransomware he dug into the code for the malware and found that some of it had changed. This makes things much more difficult to recover from. If this is a cyber attack on another nation then the goal is certainly destruction. Crafting malware to look like ransomware but make things irrecoverable is a good way to accomplish that goal. It also helps with creating disinformation (something Russia does).

Then there’s the article from the grugq. He tracks down the MeDoc connection, which is considered the starting point for the infection. MeDoc is an accounting software package. The malware was sent through it’s update service. Now, if I’m a criminal trying to make money of this thing I use phishing emails to send this thing out to as many places as possible. Targeting a software vendor to deliver ransomware seems like way too much work for not a lot of payout. In fact the email address for payments has already been shutdown. Even if you wanted your files back you’re not getting them, because communication with the attackers is gone. Last check of the bitcoin wallet is $10,296.2 USD, according to @petya_payments on Twitter.

The problem with news like this is that there’s a lot of information flying out there. Not all of it good. It’ll take a few days to sort through everything, even then we won’t have a clear picture. In several weeks US intelligence will have their say. Like they recently did with WannaCry (it was North Korea). I think this is a targeted attack involving countries. There will be collateral damage, but it’s unlikely to affect a majority of us. In fact it looks like the initial attack has long since passed. Again, it’s early and some of this information is likely misguided or incorrect or new information will come out. There are some researchers saying that it’s not a wiper. The link in the post is another good resource for information and a good example of the community working through early information. He does agree that the malware's purpose is destruction, he's just not sure it's a wiper. I'm not versed enough in malware analysis to make a distinction either way. Wiper or ransomware are minor details, both will cause a lot of destruction. We should have a clearer picture in the next few days.

Suggestions for defending yourself are in the SANS and Symantec articles. Simple answer is to patch your shit and evaluate SMBv1 needs. I also took this event as an opportunity to email some internal folks and ask questions about our systems and see how they responded. When people talk about war gaming a security incident, these are good opportunities, even if you’re not impacted.

Resources:

• https://blog.comae.io/petya-2017-is-a-wiper-not-a-ransomware-9ea1d8961d3b

• https://medium.com/@thegrugq/pnyetya-yet-another-ransomware-outbreak-59afd1ee89d4

• https://www.symantec.com/connect/blogs/petya-ransomware-outbreak-here-s-what-you-need-know

• https://isc.sans.edu/diary/22566

• https://twitter.com/TimothyDeBlock/lists/security-research

• https://www.malwaretech.com/2017/06/petya-ransomware-attack-whats-known.html

I think traffic got worse.

This blog post first appeared on Exploring Information Security.

Pragma and Cache-Control

I’d like to start posting more on my website. One of the ideas I had for doing that is to write about some of the more obscure things in application security. My career has been almost entirely on the job training. This comes with the challenge of trying to understand explanations that sometimes don’t state obvious ideas and concepts. I’d like to cover some of those obscure topics and really dig into them. In the process I’d like to try and answer them in a way that my younger self can understand. I’m hoping this will provide others with a simpler explanation while helping me to better understand the concept.

To kick it off, I’d like to cover pragma and cache-control. The reason why is because I see this regularly in reports from ZAP, “Incomplete or No Cache-control and Pragma HTTP Header Set.” It’s a low or information finding and it usually shows up in a lot of places. I did some research to better understand the finding several weeks ago.

What is pragma and cache-control?

Both are header settings for the browser. Before we get to far, I guess I should explain what are HTTP header settings. These are settings that the application will communicate to the browser to determine how they interact together. In the case of pragma and Cache-control the application is telling the browser not to cache any content or don’t keep any content pulled down in the browser after leaving the site. The reason is so that sensitive information doesn’t get stored in the browser for a malicious actor to take advantage of if the person’s computer is compromised. For a more in depth explanation on HTTP headers check out this article, HTTP Headers for Dummies.

Pragma is an older header setting for HTTP/1.0. Cache-Control is the newer header setting for HTTP/1.1. What that means is that pragma is used to control cache for older browsers. If older browsers are being supported by the website or application then setting that is important to ensure sensitive information isn’t being stored. If older browsers are not support then just cache-control is used. In some cases you may have both. The Mozilla Developer Network has a pretty good explanation. There’s also a good explanation and discussion on Stack Overflow if that’s your thing.

How and where to set pragma and cache-control?

Where the header settings will depend on the application and what is being sent as content to the browser. The only setting for pragma is no-cache. Cache-control has more directives to set for flexibility. Max-age and revalidation are two directives that can be set. The browser will have to stick to those settings. The recommendation I’ve seen is to set pragma with no-cache and cache-control with no-cache, no-store, must-revalidate, and private.

These settings are set in either code or on the server. How implementation is done depends on the language and technology used by the application. Google is a good place to look for how to set these settings based on those factors.

Simple as that.

Hopefully, this clears up some confusion for people. Writing this down has helped me understand it a little better. I hope to do more of these types of articles in the future. I would love feedback on this post. Also feel free to drop a comment if I missed something in the explanation.

References:

• https://code.tutsplus.com/tutorials/http-headers-for-dummies--net-8039

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma

• https://stackoverflow.com/questions/10314174/difference-between-pragma-and-cache-control-headers

• https://github.com/zaproxy/zaproxy/issues/2405

• http://www.bitordertech.com/resources/blog/73-how-to-use-the-zap-scanner-tool-a-practical-example

This blog post first appeared on Exploring Information Security.

HipChat's Security Win

<INSERT SCARY HACKER PICTURE WITH SALACIOUS HEADLINE>

I was disappointed not to find any of the HipChat coverage in my Feedly reader this morning from the infosec news sites. It hit plenty of main stream sites like engadget. I'm sure there is coverage on some infosec sites. It's just not as wide spread as I see for other breaches. Why is this?

Well it might have to do with HipChat having a good response to their incident. Most of the detail for the breach comes from their own blog. Over the weekend the detected a security incident affecting their servers. The incident was the result of a vulnerability in a popular third-party library.  The attacker may have accessed user account information for everyone using the service. Because of that they invalidated everyone's password and asked them to setup a new one via the forgot password link.

They were reaching out to 0.05% of their users who were more seriously impacted by the breach. For those users messages and room content may have been accessed. For everyone else it was just (potentially) account information.

While this is an unfortunate incident to occur, this is a security win for HipChat.

They detected the incident and within days made an announcement. This led to a very small percent of users being impacted. They went ahead and invalidated everyone's password. I logged out and tried to get back in with my old password and it wouldn't work. I had to use forgot password. This meant that password didn't need to be changed immediately if people were still work or hadn't heard of the breach yet. Unfortunately, I don't think they accounted for the demand on their forgot password page. The page was essentially denial of serviced causing some frustration among users. I'm sure there will be plenty of lessons learned this week.

I wanted to write this post because I think we should highlight more security wins in our industry. The sites I use to keep up on infosec are focused on NSA backdoor detection, BrickerBot, among other nasty things. All still relevant and scary. However, we are seeing some positive things in security. HipChat is a good example of that and I applaud them.

This post first appeared on Exploring Information Security.

JavaScript, PowerShell, and GitHub

It's been a while since I've updated the blog. I've gone through a pretty big transition. I've not only switched jobs but also moved the family to a new state. My new rule is a dream job in application security. To improve my programming skills I've begun populating my GitHub page (which I started in 2015) with some personally crafted code.

JavaScript

I've been working on learning JavaScript the last few months. I've gotten to the point that I really need to start writing code to get a better understanding of it. The only problem is coming up with an idea. While I'd love to create an infosec related tool, nothing is jumping out at me. One idea that did come to mind is an app for the Blizzard's Overwatch.

I sometimes like to play a random character when it comes to a game like Overwatch. Unfortunately, Overwatch doesn't have a random character selector feature. I decided to create my own with NodeJS.

It's a simple app that requires node be installed on a computer. I hope to make it into an actual desktop app with expanded functionality. I'd like the app to eventually do comp suggestions or counter suggestions for particular characters. For the non-gamers, I want it to give players suggestions for playing certain characters based on different scenarios.

PowerShell

I've uploaded two PowerShell scripts to my GitHub page. The first provides a way for system administrators to disable multiple accounts in Active Directory. This was written back in 2014 when I was tasked with disabling 800 accounts in AD. It's three lines of code that takes a .csv file input of account names and disables those accounts.

More recently I was tasked with helping the development team find hardcoded IPs in a code base. I spent a couple hours on Friday doing some research on existing PowerShell code. I found a couple promising leads.

The first looks in a specific file for IP addresses.

$input_path = ‘c:\ps\ip_addresses.txt’
$output_file = ‘c:\ps\extracted_ip_addresses.txt’
$regex = ‘\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b’
select-string -Path $input_path -Pattern $regex -AllMatches | % { $_.Matches } | % { $_.Value } | > $output_file

SOURCE

This works if you only need to look in one file. I needed to look into a large repository with multiple files. During my research I also had found this:

View fullsize

The code can be found at this link. This got me most of the way to where I needed to be. This specific code was looking for hardcoded IP addresses in system files for a user account. I needed to specify a path for the directory I wanted searched and also needed to get it exported to a .csv file for me to share with the dev team.

First, I changed $Root to $Input_Path and then defined the $input_path under in try{}.* Then I got the results exported to a .csv file by adding "Export-Csv C:\ps\extracted_ip_addresses.csv" to the end of the last line.

*Worth noting that the "I" needs to be captalized in the function FindFilesWithContent.

I also refined the regex a bit by changing what was in $pattern to this bit of regex found at this link:

(?:(?:1\d\d|2[0-5][0-5]|2[0-4]\d|0?[1-9]\d|0?0?\d)\.){3}(?:1\d\d|2[0-5][0-5]|2[0-4]\d|0?[1-9]\d|0?0?\d)

It only reduced the results by about 15-20%, but helps if you don't know what you're looking for. If the IP addresses being searched are known then the simpler regex, "(172\.\d+\.\d+\.\d+)" should work just fine. If the IP addresses being searched aren't know then the results will need to be sifted manually. The regex while good, will pull version and ID numbers from the code.

In all it took about two hours of research and two hours of fiddling with the code to get it to work. I am looking forward to my next coding challenges and sharing those here.

 This post first appeared on Exploring Information Security.