Author Archives: Jerome

Are you oversharing (in Salesforce)?

Unauthorised access to data is a primary concern of clients who commission a Salesforce assessment. The Salesforce documentation acknowledges that the sharing model is a “complex relationship between role hierarchies, user permissions, sharing rules, and exceptions for certain situations”. It is often said that complexity and security are natural enemies. Salesforce empowers its users with a multifaceted sharing framework in order to cover a wide variety of business use cases. But with great power comes great responsibility. This blog post over on the NCC Group research site discusses the topic of misconfigured sharing, and announces the release of a new open-source tool Raccoon to help identify such misconfigurations, which could otherwise expose sensitive data.

Salesforce Security with Remote Working

With Coronavirus still active across the world, life is far from settled, but the uptake of remote working is surely here to stay. From a security standpoint, organisations may feel less comfortable at the moment simply because staff are working out of sight. Whether that feeling is justified will depend on the technical measures put in place to facilitate remote working. Salesforce provides logging of authentication events as part of the standard platform. This blog post over on the NCC Group research site takes a look at monitoring these events in various contexts as a way to increase assurance.

Common Insecure Practices with Configuring and Extending Salesforce

This blog post on the NCC Group research site discusses the most common findings from a sample of over 35 security assessments of Salesforce customer deployments. The assessments covered a mixture of configuration and code review, and the common issues were sorted into broad categories: Deviation From Salesforce Baseline Standard, Deviation From Security Best Practice, Authentication Issues, File Handling, Insecure Code, Unhandled Security Alerts and Critical Updates Pending (now since merged by Salesforce), and Broken Access Controls.

The Case of the Customer Data and the Third-Party Analytics Site

I recently had an article published on the NCC Group blog about a pentest during which it became clear that customer personal data was being sent to a third party. It’s common for websites to use metrics/analytics services to collect usage data on how users are interacting with the sites. I thought it would be useful to highlight the danger of sensitive data being accidentally sent to third parties without due care and attention paid to GDPR. Have a read!

JWT Attack Walk-Through

Over on the NCC Group website I published a solution to an open demonstration of the well-known JSON Web Token (JWT) algorithm confusion vulnerability (the one where you swap the token algorithm from ‘RS’ to ‘HS’ and sign your payload with the public key). I use OpenSSL to gain full visibility of what’s happening and, by walking through the method, if you ever need to test this vulnerability yourself, it will hopefully help to avoid false negatives.

Missing XSS flaws with innerHTML and jQuery

I thought a couple of gotchas when testing for XSS could be a useful post. Not new, especially, but I haven’t posted for a while. It shows how you might think you’ve covered an area of a web application and declared it free from XSS but in fact there might be a bug left behind. Continue reading

From CSV to CMD to qwerty

The ongoing breach stories of targeted email campaigns harbouring malicious attachments made me think of writing up a summary of a presentation I gave at the amazing NCC Con held in Dublin in January this year. The talk was based on a pentesting war story that started off exploiting the old (but I believe often overlooked) Dynamic Data Exchange (DDE) trick to go from an Excel export function in a web app to OS code running on users’ workstations. From there, the story takes us on to domain creds via some NTLMv2 theory (without a pentest laptop), a bug in hashcat and a new script “catflap”. Continue reading

The Why Behind Web Application Penetration Test Prerequisites

Before a web application penetration test is scheduled to start, the company performing the test will contact the client with a list of considerations and configurations that are required before the test can begin. Sadly, the importance of these can be lost in amongst the frenzy of ensuring the system is ready on time, or perhaps because the items listed don’t seem necessary. My whitepaper aims to address the latter, providing an explanation of the why behind the prerequisites, together with some general pre-test points for consideration. It is aimed at anyone who is charged with preparing for a web application penetration test, from project managers to developers, and as such it is written for both technical and non-technical readers. The paper ends with a one-page quick reference guide to help with future tests, which is available as a standalone document here.