Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

YAWAST v0.7 Released

It has now been over a year since the last major release of YAWAST, but today I am happy to release version 0.7, which is one of the largest changes to date. This is the result of substantial effort to ensure that YAWAST continues to be useful in the future, and add as much value as possible to those performing security testing of web applications.

If you are using the Gem version, simply run gem update yawast to get the latest version.

JSON Output #

One of the headline features is that YAWAST now supports producing JSON output via the new --output=<file> parameter. This will create a JSON file that can be used to record the actions of YAWAST in more detail, and be used in reporting automation. The goal of this feature is to capture all of the information that is needed to produce a report automatically.

If you specify --output=. or --output=/path/., YAWAST will automatically generate a file name based on the domain name and current time.

The overall structure of the JSON output shouldn’t change, but the details included may change over time as the output is refined to make it as useful as possible.

Enhanced Vulnerability Scanner #

The other major change in this version is the new vulnerability scanner, which adds a number of new checks, and opens the door to more easily adding checks in the future. This is currently accessed via the --vuln_scan parameter, as this is seen as a beta-level feature; when used without that parameter, YAWAST behaves as it has in the past. In the future, this will become of the default behavior, once it’s clear that it is stable.

It is recommended that you use --vuln_scan unless it is causing issues for you (and if it does cause issues, please open an issue).

One behavioral change is that the new --spider option works differently in each mode; --vuln_scan will always spider the site, so in that mode, --spider simply adds printed output to the UI listing the URLs found.

This new scanner leverages Chrome via an automated interface to perform certain tasks, that can only be properly tested by browser interaction; this adds some new dependencies, though the application should fail gracefully if these aren’t present.

The YAWAST Docker image has been updated to work with this new feature, making it the easiest way to use it.

User Enumeration via Password Reset Form (Timing & Response) #

One new experimental feature that I would like to point out is that YAWAST will attempt to use the target application’s Password Reset Form (specified via --pass_reset_page) using Chrome automation to capture the difference between a valid user (specified via --user) and a randomly generated invalid user. It will compare the responses and display a diff of the changes between the two.

YAWAST will attempt to automatically identify the form field that captures the username / email address, if it fails to find the field, it will prompt you to provide the name or id.

It will run this procedure a total of 5 times, and capture of the timing that each request took, to determine if timing information can be used to determine valid users.

[V] Password Reset: Possible User Enumeration - Response Timing (see below for details)
    Difference in average: 368.6ms  Valid user: 736.15ms  Invalid user: 367.55ms
    Valid Users     Invalid Users
    -----------------------------
         990.15            598.39
         727.22            312.19
         679.86            303.05
         796.91            319.85
         486.62            304.27

Change Log #

Here is a list of the changes included in this version:

  • #38 – JSON Output Option via --output= (work in progress)
  • #133 – Include a Timestamp In Output
  • #134 – Add options to DNS command
  • #135 – Incomplete Certificate Chain Warning
  • #137 – Warn on TLS 1.0
  • #138 – Warn on Symantec Roots
  • #139 – Add Spider Option
  • #140 – Save output on cancel
  • #141 – Flag –internalssl as Deprecated
  • #147 – User Enumeration via Password Reset Form
  • #148 – Added --vuln_scan option to enable new vulnerability scanner
  • #151 – User Enumeration via Password Reset Form Timing Differences
  • #152 – Add check for 64bit TLS Cert Serial Numbers
  • #156 – Check for Rails CVE-2019-5418
  • #157 – Add check for Nginx Status Page
  • #158 – Add check for Tomcat RCE CVE-2019-0232
  • #161 – Add WordPress WP-JSON User Enumeration
  • #130 – Bug: HSTS Error leads to printing HTML
  • #132 – Bug: Typo in SSL Output
  • #142 – Bug: Error In Collecting DNS Information

Adam Caudill

Related Posts

  • The (Questionable) Future of YAWAST

    The last release of YAWAST was on January 1, 2020; while the release history was sometimes unpredictable, the goal was a new release each month with new features and bug fixes. I intentionally took January off from the project. In February, I left the company I was at; the team of penetration testers there had helped to inspire new features while looking for ways to make them more productive. But something else happened in February, an issue was opened – something that appeared to be simple, but in fact, made me realize that the entire project was in doubt.

  • YAWAST: News & Mission

    It’s been some time since I last wrote about YAWAST on here, it was actually back in April when I posted the last update – that was for the release of YAWAST v0.7.0. Currently, it’s at version 0.11.0 and a lot has changed. It’s been rewritten from scratch, more people have become involved, it has moved to a (fairly) regular release cycle, and has expanded a fair bit in terms of functionality.

  • YAWAST 0.5 Released

    Today, I’ve released the latest version of YAWAST, a security scanner for web applications that provides basic information about the application, and performs common checks so that you can move on to the fun part of testing more quickly. YAWAST also remains the only tool I’ve found that can perform an accurate test for SWEET32. Here is the change log for version 0.5.0: #35 – Add check for SameSite cookie attribute #53 – Added checks for .

  • Testing for SWEET32 with YAWAST

    Testing for SWEET32 isn’t simple – when the vulnerability was announced, some argued that the best solution was to assume that if a TLS server supported any of the 3DES cipher suites, consider it vulnerable. The problem is, it’s not that simple. On my employer’s corporate blog, I wrote about practical advice for dealing with SWEET32 – and pointed out that there are ways around the vulnerability, and some are quite simple.

  • Exploiting the Jackson RCE: CVE-2017-7525

    Earlier this year, a vulnerability was discovered in the Jackson data-binding library, a library for Java that allows developers to easily serialize Java objects to JSON and vice versa, that allowed an attacker to exploit deserialization to achieve Remote Code Execution on the server. This vulnerability didn’t seem to get much attention, and even less documentation. Given that this is an easily exploited Remote Code Execution vulnerability with little documentation, I’m sharing my notes on it.