We are finally prepared to use the ZAP tool to perform some security testing in this part of the ZAP series.

If you are new to this topic, please check out the rest of the previous articles.

We will use DVWA (Damn Vulnerable Web Application) for this part of the series.

DVWA is a PHP/MySQL web application that is used to help security professionals to learn and test using security tools while staying clear of legal implications. It possesses many common vulnerabilities, so you don’t need to waste your time to set up the application from scratch.

To follow along with the testing, you will need to install DVWA. There is a great guide on installing it in a Linux environment (you should use the one we set up in the first part of the series (Kali machine). You can find it on this site.

We will divide this part of the series to cover a few topics:

· Setting up Dynamic SSL certificates

· Automated Scan – How to use Ajax Spider?

· Recommendations for Add-ons

· HUNT extensions for OWASP ZAP

Setting up Dynamic SSL certificates

We want to start testing the application, but the application possesses an SSL certificate, and we get the following error:

If you want to read more about Dynamic SSL certificates, check out this site.

Without importing ZAP Certificates in the browser, ZAP cannot handle simultaneous Web request forwarding and intercepting. So, we will need to set it up!

First, go to the menu tab Tools -> Options -> Dynamic SSL Certificates, generate and save the certificate file. 

Now we need to go to the browser we will use for the testing, I am using Brave, and we need to configure its settings. Go to the Privacy and Security section and use CTRL + F and look for “cert”, when you find the Manage certificates section, choose the Authorities tab and click on import and choose the certificate we saved from ZAP (when browsing to the cert file if you don’t see it, choose All files from dropdown).

The following window will appear, choose to trust the certificate (first option as it is in the picture).

That is it; you are ready to proceed!

How to use Ajax Spider?

By Owasp: The Ajax Spider is an add-on that integrates in ZAP a crawler of AJAX rich sites called Crawljax. You can use it in conjunction with the traditional spider for better results. It uses your web browser and proxy.

For more information about the add-on, you can check out OWASPs official site.

In the Marketplace, we choose Ajax Spider to install it first.

There are a few ways to do an automated scan, first and quickest is going to Quick start and choosing Automated Scan and then choosing the URL of the application you want to scan and clicking on the Attack button.

*In this step, you can also choose if you want to use traditional spider and/or Ajax. If the application you are testing is written using AJAX, you will definitely want to mark Ajax spider. Still, you can also mark the traditional one so you can cover the testing completely. The easiest way to use Ajax Spider is with HTMLUnit. If you don’t see it in the dropdown you would need to install it. Here is the place you can check out if you want to install it in Ubuntu.

After the scan (if you are using DVWA application) you will see the list of vulnerabilities in the results, such as in the following picture:

Recommendations for add-ons

From the toolbar choose Manage Add-ons (Add-ons Marketplace). You will see Installed and Marketplace tabs. We would like to add new add-ons, so we choose Marketplace.

This is the recommended list of add-ons:

• Directory List v2.3 (Provides files with directory names to be used with Forced Browse or Fuzzer add-on.)

• Directory List v2.3 LC (Provides files with lower case directory names to be used with Forced Browse or Fuzzer add-on.)

• FuzzDBFiles (Provides the FuzzDB files which can be used with the ZAP fuzzer. Some files which cause anti-virus software to flag or remove files have been split off into the FuzzDB Offensive add-on available via the ZAP Marketplace.)

• FuzzDBOffensive (FuzzDB web backdoors and attack files which can be used with the ZAP fuzzer or for manual penetration testing.)

• Python Scripting (The Python Scripting add-on allows you to integrate Python scripts in ZAP. When you create a new script, you will be given the option to use Python, as well as the option to choose from various Python templates.)

• JSON View (Provides a Request/Response panel view that shows JSON bodies nicely formatted.)

• JWT Support (Detect JWT requests and scan them)

• ViewState (ASP/JSF ViewState Decoder and Editor)

• Community Scripts (Useful ZAP scripts written by the ZAP community)

If you would need some other add-ons check out the list of add-ons on the ZAP official site and Github ZAP extensions. On the ZAP official site list, there is no information for new add-on JWT support; you can get more information about it on this site.

If you choose to download extension from Github you can also download add-ons and import them manually by clicking the File option in the toolbar and choosing Load Add-on File…” menu option (CTRL + L).

HUNT extensions for OWASP ZAP

There is one interesting extension you can check out, it is called Bugcrowd HUNT extensions, and it can be found on this site.

To use this extension, first, you need to be sure that you installed from Market Add-ons: Python Scripting and Community Scripts. Then, in ZAP options, choose Passive Scanner and mark “Only scan messages in scope” (enabled).

In the ZAP tree, click on the plus icon and add Scripts, new window will open, then expand Passive Rules and right-click on Hunt.py script and choose to Enable Scripts.

When you scan the application next time, this script will be included. The application will passively be scanned for SQLi, LFI, RFI, Path Traversal, OS Command Injection, Insecure Direct Object Reference, Logic & Debug Parameters, and Server-Side Template Injection.

You can finally start playing around and start scanning applications! Scan only your stuff or apps like DVWA so you don’t get into trouble!

Conclusion

We finally got to the stage where we started using ZAP. We have scratched the surface of its possibilities, but we will continue with ZAPs features in the next part of the series.

Hang tight!

#ZAP #AjaxSpider #DynamicSSL #HUNT

Cover photo by Markus Winkler

Supply chain attacks – when hackers breach suppliers to laterally invade their client’s IT rather than targeting the client companies directly – are nothing new. In 2013, hackers breached the formidable cyber defenses of mega-retailer Target by first breaching a small HVAC provider, learning their login credentials to Target’s system, then bypassing the security measures en route to costing Target over $300 million. Supply chain attacks may be a familiar threat, but it’s one that’s evolving at a breakneck pace…with sinister implications for the entire cybersecurity community.

After increasing steadily for years, supply chain attacks tripled in 2021. The pandemic explains some of that uptick as hackers exploited the widespread disruption in any and every way possible. But supply chain attackers have also adopted a potent new tactic: breaching software developers and hiding malicious code in their products to infect anyone who uses them. Hackers used this technique (known as software supply chain attacks) in the now infamous SolarWinds attack, as well as Log4J, Kaseya, and others, all of which occurred in 2021. And they will continue to launch supply chain attacks of all kinds for the simple reason that these attacks have proven successful, lucrative, and extremely hard to stop.

Hard but not impossible. The UK’s National Cyber Security Centre (which I have highlighted previously for their impressive efforts) recently issued guidance to help organizations harden themselves against supply chain attacks. At this point, most organizations have at least basic cybersecurity protections in place, but too many ignore the protections their suppliers have in place and leave themselves vulnerable to attacks as a result. Consider that good news, though, because it means that supply chain attacks are neither impossible, expensive, nor especially complicated to prevent. It’s more about due diligence upfront than being on-guard 24/7, and the biggest investment is time rather than money. That’s not to say that defending against supply chain easy is easy but rather to emphasize that anyone has the means to get more resilient. Plus, a clear five-step roadmap to follow courtesy of the NCSC. Here’s a quick outline:

1. Preliminary Actions – Before doing anything else, it’s vital to understand (in-depth) the importance of supply chain security and all the potential consequences for failure. Equally important to understand is how the company quantifies, contextualizes, and manages risk more broadly. Lastly, identify the key stakeholders across departments and the roles that each will play in supply chain security (this isn’t a one-person job).
2. Develop an Approach – Start by identifying mission-critical assets and the level of security each takes to protect. Then, develop a framework to assess whether suppliers can deliver that same level of security (or above). Write up contractual clauses to include in every service contract mandating minimum security standards, and create a plan for non-compliance so that security issues can be resolved (or suppliers replaced) as seamlessly as possible.
3. Vet New Suppliers – Use the framework to asses if new suppliers have the required security, and insert the security clauses throughout the contract life-cycle. Key to this effort is educating all staff, especially everyone in procurement, on why and how to make cybersecurity a priority, both when selecting suppliers and when managing ongoing relationships. Supplier reps have lots of leverage. They should use it to insist that suppliers take cybersecurity seriously and hold them accountable when they don’t.
4. Vet Existing Suppliers – Use the framework to evaluate all existing supplier contracts, considering how each supplier creates risk and mitigates it with specific cyber protections and policies. Start with the biggest or most important suppliers. Negotiate with any supplier found to have inadequate security about resolving the situation. If they’re unwilling or unable to improve security, decide if walking away or making concessions is more appropriate. Vet each existing supplier at least once, but make this an ongoing process in order to understand how supplier security has improved or declined since the previous assessment.
5. Constantly Improve – Evaluate how well the framework is working on a continual basis, making adjustments as necessary. The assessment process can be made more efficient and ineffective over time. Furthermore, it must evolve as supply chains, production demands, and cyber threats evolve as well. Prepare to have an ongoing (and sometimes difficult) conversation with suppliers about where and why their security falls short of standards.

This all sounds sensible enough to me, and I would encourage literally every organization (and individuals too) to follow it in some form. Helpful as this advice may be, however, I feel like the fundamental challenge of stopping supply chain attacks remains: it’s hard to accurately evaluate another company’s cybersecurity. They could have problems they’re not aware of or others they know how to hide. More likely, though, is that suppliers are unwilling to be fully transparent, or else clients don’t have the resources to continually do a thorough assessment. And for that reason, trust will continue to play a big role in supply chains – and attacks, I’m afraid, will continue as well.

#cybersecurity #supplychainattacks #NCSC #Trust #SolarWinds #Log4J

Binding Operational Directive 23-01 – Improving Asset Visibility and Vulnerability Detection on Federal Networks

A binding operational directive is a compulsory direction to federal, executive branch, departments and agencies for purposes of safeguarding federal information and information systems.

In November 2021, CISA brought us Binding Operational Directive 22-01. Almost a year later, CISA has unveiled their newest installment, BOD 23-01.

BOD 23-01 is an ambitious step towards strengthening the US Federal Government’s cybersecurity posture in accordance with President Biden’s Executive Order 14028. While the previous directive laid out the requirements regarding vulnerability mitigation and reporting for individual agencies, what we see in 23-01 is a centralization and streamlining of cybersecurity for all Federal Civilian Executive Branch Agencies (FCEB).

Ostensibly, the new directive focuses on asset management and vulnerability enumeration within all FCEB agencies. As one could guess, managing the cybersecurity posture of every asset, including roaming and nomadic devices, across a hundred or so individual agencies is an undertaking that requires a single system.

To combat this issue, CISA has laid out a number of required actions to achieve the following goals:

• Maintain an up-to-date inventory of networked assets as defined in the scope of this directive;
• Identify software vulnerabilities, using privileged or client-based means where technically feasible;
• Track how often the agency enumerates its assets, what coverage of its assets it achieves, and how current its vulnerability signatures are; and
• Provide asset and vulnerability information to CISA’s CDM Federal Dashboard.

The scope of these actions encompasses all FCEB unclassified federal information systems (including information systems used or operated by another entity on behalf of an agency). All reportable information technology or operational technology assets fall within the scope. Only assets like containers or third-party SaaS are excluded.

• The required actions are rigorous by government standards.
• Agencies are expected to perform automated asset discovery every 7 days.
• Initiate vulnerability enumeration across all discovered assets (including nomadic and roaming devices), every 14 days using privileged credentials.
• Vulnerability detection signatures need to be updated within 24 hours of their vendor release.
• All vulnerability enumeration results should be set up for automatic ingestion into the CDM Agency Dashboard.
• Have the ability to perform on-demand asset discovery and vulnerability enumeration within 72 hours of a CISA request.

Within six months of the publication of these requirements, all FCEB agencies are required to collect and report their vulnerability data to CISA. By 3 April 2023,

agencies and CISA, through the CDM program, will deploy an updated CDM Dashboard configuration that enables access to object-level vulnerability enumeration data for CISA analysts, as authorized in the Executive Order on Improving the Nation’s Cybersecurity.

If you aren’t aware of what the Continuous Diagnostics and Mitigation (CDM) program is, think of it as a vulnerability management system that encompasses all FCEB agencies. Information flows from assets within individual agencies to an agency-level CDM dashboard. The data from all agencies is then fed to the Federal Dashboard. This upwards accumulation of data allows CISA to provide a status report to the Secretary of Homeland Security, the Director of OMB, and the National Cybersecurity Director. It also enables CISA to monitor agency compliance.

Seems like CISA is cutting out the middleman when it comes to vulnerability reporting and mitigation to create a cybersecurity monolith.

#CISA #Binding_Operational_Directive #CDMprogram #FCEB

Image by DeepMind