• Articles
    • Editorial Articles
    • Research Articles
    • WatchGuard Articles
  • The 443 Podcast
  • Threat Landscape
  • About
    • About Us
    • Contact Us
    • Contribute to Secplicity

Secplicity - Security Simplified

Powered by WatchGuard Technologies

Supply Chain Attacks Through an IDE

August 16, 2021 By Trevor Collins

David Dworken, a Google security researcher, presented a recent Defcon talk about how he found over 30 vulnerabilities in various Integrated Development Environments (IDEs) over the course of a few months of research. 

Many believe that source code on its own is benign as long as you don’t compile and run it, but as Dworken proved, simply loading code into an IDE can cause infections. A popular example of this comes from North Korea where they asked security researchers to investigate a suppose exploit they made, and then sent the researcher an infected code package that could run malicious code simply by having it loaded in an IDE without the researcher running the code itself.  

Visual Studio Code (VS Code) uses a scope for settings called Trusted Workspace settings. These settings come from inside the project itself and run when you open the project in VS Code. As an example of a security risk, the Python module in VS Code uses a feature called Flate8 to identify proper code. An attacker could exploit this feature by overwriting the Flate8 path to an executable in the folder. Therefor simply viewing the project, which calls Flate8, opens the executable in the project.  

Another setting file that runs when oping a project comes from the JavaScript VS Code module. This module checks in the projects node_modules folder for “jsint” and opens the file if available. An attacker could simply put malicious JavaScript in the “jsint.js” file directory which would then run as soon the programmer opens the project. Dworken found many more similar exploits including ones in Cloud-based IDEs.  

Dworken demonstrated the severity of the issue when he created a worm that infects the programmer’s computer using these exploits, then distributes itself to other repositories on their computer. With project update automation,  an attack like this could quickly spread through an entire engineering department. We should treat untrusted code projects the same way we treat untrusted programs. Don’t open the project unless you have verified the source. If you can’t verify the source, carefully open the project in a VM. 

Share This:

Related

Filed Under: Editorial Articles

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

The 443 Podcast

A weekly podcast featuring the leading white-hat hackers and security researchers. Listen Now
the 443 podcast

Threat Landscape

Filter and view Firebox Feed data by type of attack, region, country, and date range. View Now
threat landscape

Top Posts

  • Cybersecurity News: Free Cybersecurity Training, TrickBot Group Exposed, Major GoDaddy Breach, and Russia to Legalize cybercrime?!
  • US National Cybersecurity Strategy
  • 3CX Supply Chain Attack
  • Here Come The Regulations

Email Newsletter

Sign up to get the latest security news and threat analysis delivered straight to your inbox

By signing up you agree to our Privacy Policy.


The views and opinions expressed on this website are those of the authors and do not necessarily reflect the policy or position of WatchGuard Technologies.

Stay in Touch

Recent Posts

  • 3CX Supply Chain Attack
  • The NSA’s Guidance on Securing Authentication
  • Cybersecurity News: LastPass Incident Revealed, White House Issues Cybersecurity Strategy, FBI Purchases Leaked USHOR PII Data, and a Slew of Other Breaches
  • An Update on Section 230
  • Here Come The Regulations
View All

Search

Archives

Copyright © 2023 WatchGuard Technologies · Cookie Policy · Privacy Policy · Terms of Use