Robust exception handling is one of the tenets of best practice for development, no matter what the coding language. This blog post, published in full on the NCC Group research site, explores the curious circumstances in which a developer trying to do the right thing – but without appreciating the full effects – could lead to data integrity issues in a Salesforce Organization. These issues revolve around the automatic rollback mechanism that the Salesforce platform provides to try to maintain data integrity. However, as is so often the case, the devil is in the detail. On the basis of recent code reviews, it is apparently under-appreciated how the addition of exception handling in Apex (the Salesforce development language) can affect the rollback mechanism, which in turn can affect data integrity. The precise impact will vary according to what’s being done to which data, but the potential for consequences detrimental to security is clear.
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.
Salesforce Policy Deviation Checker
SFPolDevChk is a quick tool to show which Profiles in a Salesforce instance have become desynced from an Organization in terms of password and session policies, with any deviations highlighted. Published as an NCC Group open source project.
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
A Thick Spread of Logjam
This article dissects the recent Logjam paper from a pentesting viewpoint to reveal a number of different factors that affect the impact of the vulnerability. One of those factors includes the use of common primes and I’ve included a small change to OpenSSL that you can use to look out for this. Continue reading