Slightly SOSL'ed: Locating And Testing SOSL Injection

okay hi everyone um these presentations always start off with the usual disclaimer clearly I'm showing you all this stuff for testing and not to take over the world's Major Crimes minor crimes or

whatever um brief agenda we're just going um in a typically recursive way you're looking at my intro in the intro there and a bit of a who am I go through a quick overview of Salesforce how many people in here are already familiar with it okay and then um Salesforce overview for anyone not familiar with it quick overview of the soil language quick overview of how the intro works and then we'll go through finding injection vulnerabilities by code review and application testing slightly more interesting exploiting the what you found and then mitigations and defenses because we're all responsible people uh quick split on how many red teamers here or offensive and how many blue team or

defensive people um so and then finally conclusions so I'm basically some uh guy who started off developing secure software in the financial sector doing some uh secure soft software

developments okay something's gone horribly wrong hold

up right as I said started off in Secure software development which was like turned out to be a good grounding for moving into security consultancy where I sort of moved on to a lot more code review application testing threat modeling which is something I'm still working on today which is how I initially came across this issue right just to be clear on what the talk is and isn't about um does uh this is about a vulnerability that's present in Apex cones so it found in uh customizations and extensions built on top of Salesforce and it's just going to show you how to locate that in other people's custom code how to exploit it or go

about testing it and uh it's partly happening because when I first came across the issue I could not find any payloads online anywhere no tutorials and so had to go through the horrifying experience of doing the own research and writing it up it is not a talk about Salesforce and this vulnerability just to be clear it's something to be found in extensions built on top of Salesforce apis talking to Salesforce there will be no zero days here and on the subject of Salesforce I am not a Salesforce expert uh I'll happily answer the sole questions but if anyone asks Salesforce questions I'll try to answer but I might look confused while doing so having just told you I'm not an

expert on Salesforce I'm get to patronizingly explain to you what Salesforce is it's a CRM system and it has a couple of things called sites and lightning apps that allow users to build extensions and apps on top of that and uh it has these records incorporated into it which use this uh crud way of of uh applying permissions any user with access to records will have create read update or delete permissions but uh those permissions can vary across users which again is why the injection issue can become important as we'll see later and it does look like this but usually a lot more polished because that's my thing that I did with uh Salesforce free

developments thing you use a free developer version to play around and learn more but um you will be limited to a very small number of users on that which can hinder attempting to uh to to sort of play around with user permissions and any any exploitation that depends on user

permissions um I've just mentioned the create read up update delete stuff that applies to Salesforce objects which are the things manipulated by different Salesforce languages soil is only one of those languages um the best conceptual way I think of looking at the objects as a bit like spreadsheets where um Fields can kind of relate to the columns and the spreadsheet records to the rows and the objects are like the table or sheets of the uh of that metaphorical spreadsheets and as I said different users may have access to different fields within uh th those objects now the data handling the languages I've just been talked talking about rather than just using SQL Salesforce has this Apex language

derived from java which uh if anyone's everever used Java Apex will look very familiar to your um comparatively easy to read it's a lot like Java to build apis that interact with Salesforce custom components on top of Salesforce socle is virtually the same as SE SQL or SQL but uh only interacts from Salesforce with Salesforce data and only does queries DML again very similar to SQL or SQL but that only does modifications and deletion of the objects soil is a query language that has quite a sort of different syntax to sule and gets used in different circumstances and it is specific to Salesforce like the other three so you won't see it anywhere else and that stands for Salesforce object

search language and it generally gets used to like search through your collection of objects that you have in in your Salesforce [Music] implementation and uh Salesforce the Salesforce website's great because it's filled with tutorials and and other details it gives these reasons why you might use one and not the other um SOC is used in very similar circumstances to SQL where you've got a really specific idea of what you're searching for and you'd build up a select statement knowing which Fields you're looking through which tables you're looking through sole is a bit more Free and Easy in it's uh searching abilities it will literally search everything that that user has permission to see it's you can use the syntax to

narrow down those searches but um when you see it it looks like a bit like this this is stuff again taken from the Salesforce tutorials um so as I've said there like if you're a c programmer the first time you see Java there's enough familiarity for it to kind of make sense and enough differences for it to be immensely confusing but uh basically it has these sort of constructions the find keyword is always present and then it has these number of other optional Fields after away and search different groups or fields and return different objects from Salesforce and that thing right at the bottom there that's what it looks like when it's used within Apex code or

called from Apex codes SLE injection as I've heavily hinted it's an accepted known vulnerability type that you will find in Apex code where someone's uh built up Dynamic queries of the type we've just seen but with uh poorly validated inputs or with not a lot of for thought as to what can go wrong um there are information disclosure issues but it's almost impossible POs to get uh anything any sort of real disaster built upon that unless someone's done something weird in Apex like a mass mailing based on a social query or some of spammy kind of thing like that and the Salesforce information page uh you can read faster than night and talk so I'm not going to read all that

out um does give that uh definitive view on what sazzle injection is basically a repeat of everything I've just said that uh unsafely constructed Apex queries can result in this sazzle injection issue from seeing the Salesforce description you're probably wondering how can I find out more like I did and the uh the first answer to that is that you can't um when I initially looked for issues around this or for payloads I could use writeups on how to exploit it I found I guess that description on the previous slide was the longest write up I could find I found one website that told me it exists and no no real kind of stuff that I could use for

the testing I was doing so um what we'll go through is like those three ways of finding this you can find it by code review you might find it in web application testing and far more likely to find it API testing than web app testing the Salesforce lightning apps and site stuff that I've talked about earlier is a no code or low code way to build websites there's a lot of stuff in there to stop people from shooting them themselves in the foot and it's almost impossible to uh to mistakenly create sazzle injection that way but we go through for each of those go through a fairly standard kind of hacking methodology that you're probably

all familiar with of the initial footprinting and outlining of the issue and then a bit of further testing to look at sanitization what how easy is it to inject and how exploitable things are as I say in this case because of the crud sort of permissions the EXP exploitability is going to be information disclosure but for a user being able to see records that should have been hidden from them so suil code review you will be carrying it out in Apex or in Java I've come across a few times jav code that interacts with Salesforce does um the standard advice that we saw on the Salesforce website is to always use Escape single quotes which I think not everyone does

from some of the code I've

seen but um you can also build up the um the sazzle this way for Java codes um for anyone looking at those two and not not not initially seeing the difference which is understandable the uh Apex code has that uh single quotes around the search string and the Java code has the curly braces around the search string but uh the syntax is very simple it's a lot simpler than SQL the the code will always start with defined statements and so that's will be present for any sole query so it's reasonably easy to grp for that on that basis so for um you can use like a nice sort of well there's no such thing as a simple regex

but um it's a bit of a Dark Art but I think but uh find it's important this is not uh it's not a case sensitive language it's generally written in capitals the same way people always write select and capitals for SQL but uh it can be both cases so those two rag axes at the bottom the might be other correct versions that are available but uh those two will find the boundary of the word find case and sensitive followed by zero or more spaces and followed by single quotes or curly brace which should allow you to enumerates a full list of of those instances from the code from that point you have a a full

set of results that you can start looking for injectability and uh the more important thing about user permissions

from finding this in an app test you might find a a number of uh search par search things within an API or the web app test and it's not immediately apparent which ones a SLE and which ones a sockle these payloads here are are the ones that I accidentally discovered how to enumerate with um those uh th those three there and well four when used for the first three you'll always get the same error message that would indicate that the search API or the web application that you testing is using sazzle and not socle um and just to explain it says You must have two or more characters even if you've put a as asterisk or a asterisk

in quotes that's because SLE generally puts things and allows you to put the double quotes around separate Search terms within the find category and also demands it says two or more characters it means two or more non wildcard characters so those uh would all bring back a perfectly working search for socle but not for sazzle and for the fourth one you would get a set of results in the web application it looks like that top one there that's what uh a failed search look like for my sort of homemade Salesforce appc Salesforce developer test um for for the API you will get a HTTP 500 error if you do this which again massively speeds up the

enumeration if you're using those payloads for

fuzzing and the Su successful search would look like that of the either successful search results or a list of uh a bit of a a response from Salesforce explaining that that search term wasn't found you can use a few other values that will again help in enumerating these sazzle or socle kind of things they would things there would be errors in socle from their weird construction but that uh double quotes around known good you whatever your value is or some other value is a a valid construction to fit inside the curly braces or the single quotes of the fine statement that's obviously not so good for some fuzzing payloads because they depend on you knowing the known good and

known bad values but these are massively more useful when investigating the the exploitation possibilities and the information disclosure stuff and just when you do come to investigate these though you will frequently find for a lot of Salesforce stuff it's a a single sort of database all users will have varying levels of access um it's generally much more of an issue in apis than web applications as I said earlier because the Web building interface just really prevents people from doing anything too silly or too unsafe the web API also so it does kind of restrict the the web application itself you can that restricts searches to data allowed for your user the apis are generally written in

Apex they will generally run in Salesforce as two modes system mode and user mode so the data visible to an API running in system mode will be everything uh which is where the information disclosure comes in E every sort of object will be searched but by the API written in system modes an API search in user mode will bring back exactly the same as doing a similar search for the web

interface uh when it does come to exploitation attempt one of the I guess real serious difficulties socle and sule don't have a comment character so you can't treat it like SQL injection and then just cut off the rest of the statement afterwards uh it doesn't have any data modification constructs and there's a much more restricted syntax you can't interact with the the OS in the way you can in plsql or

tsql so chiefly like when we do have those uh moving on to that next stage of that methodology when we've built up that list of code review kind of findings what we have to go through those looking for what would seem to be a level of exploitability the Dynamics uh social statements will generally look like this with the single quotes and the plus signs surrounding the user supplied

values one sort of thing that I've just been inferring earlier from the apis I appreciate that's very small and hard to read up there but um the search on all Fields according to the Salesforce website here the search through all Fields runs a system running in system mode will return values and that a user does not normally have access to it ignores those crud permissions when searching all

Fields um to to look at how you can sort of identify this from a code review perspective that is an extremely contrived example there but if this was some search situation where the US of supplying a string such as uh that their search criteria of name email phone number and sest selecting what they want from a drop-down list of name email phone that uh despite the use of the Escape single quotes would be vulnerable to a a I guess a weird sort of Quirk of sole injection which has these different encloses and different fields can be specified as we saw from the earlier slide that all Fields ignores their user permissions when it searches so one way that could be

written up as an an exploitable code issue would be that uh from comparing the two the two examples there the normal usage would return whatever email you're searching for wherever it's found found in email Fields the exploited version lower down would literally search ignoring user permissions across all objects within that sales force tenancy or

implementation and usual sort of thing I would say about code review do check What's Done afterwards if that um SLE search has been used to modify records or to generate mass email or mass mailings for people then uh obviously the seriousness of that is raised as well in terms of user mode versus system mode that we've just talked about um as I said default V uh Apex runs in system modes and will search everything but you can enforce user user mode could have been enforced by the developers so do check that as well as part of your code

review in terms of investigating uh for for your app test results a bit more thoroughly it can all all be done I guess with generally the simplest Bare Bones of web app tester tools and just move on from your initial footprinting to test those end points you found that did appear to be sule end points the initial tests that you will need to do from this would be to check for the sanitization check what happens with curly braces or or single quotes being put through those if there's been any escaping of those or sanitization by the developers you will get no error it will just behave like it's searched for the the objects for a single quote or for a

curly brace what you are looking for really is for any fields or data that have been exposed that shouldn't have been and in terms of the application testing it's good to test the apis and web interface at the same time you can look at how the search differs across the two for for like an API response you would um this is obviously a fictitious fruit searching API not any real clients kind of thing but uh successful search results for for that kind of social payloads would bring back the query results like that so that that API doesn't appear to bother about you messing around with those kind of social constructs with within there and brings

back uh various data that satisfies the search criteria if we were doing this as an API test alongside the web app test then we might try running that through through the web app as well to see what results come back I will just show you something

um ah this isn't going to work because I've got no web

connectivity

I will go back to just showing you that page without bothering to try and get connectivity and Sh demonstrate it but um as a default you Salesforce web app page will always have this completely safe I should add sule search that's right at the top there and that's something you can always use to test the API results as compared to the web app results to see if you're getting anything back that you really [Music] shouldn't so you might see something like the code review example from earlier can be sort of inferred if if you have fields that look like

that and that that again is some injectable points the be besides this stuff like the find and field there are other Clauses within Salesforce there is a a Salesforce sule syntax page that gives you the really sort of constrained and narrow syntax of the language where you can find stuff like this so it has a returning clause which again you might find that uh Dynamic codes been constructed around this wear clause which looks like this so using the returning with a wear Clause it can have some additional search values within there which again could be injectable depending on [Music] sanitization I appreciate the language might look a bit bit weird for anyone who hasn't seen it

before but that could be if that's not sanitized that's on the uh example query there if not sanitized could be exploited in the way you might be familiar with SQL injection where you just match up your own opening and closing single quotes

from that previous page you might have thought there's a lot of uh I I guess it might have looked a bit impossible to construct that because you might might not know what the objects are but the Salesforce implementation has a large number of standard objects which uh you can look through and use them those to build up that kind of thing we had on the previous page so any sort of other objects that you might want to try can be found by just reading the standard documentation now since we know there's blue team people in the room and for offensive people our job is to give recommendations after we've broken the stuff so there are mitigations that you

can have around the sort of things I've been

showing queries can be executed in user modes which um you can do for sometimes that might not be desirable but um for instance if somebody wants to search the entire sales uh or has to look through all customer complaints that might have to run in system modes Ju Just because uh that's the only way for them to see all all of those records created by other users but yeah yeah user mode wherever possible massively reduces the risk of information disclosure although I've been discussing a lot of this Dynamic stuff with uh inserting user searchable things within single quotes there is a a colon operator that you can put before variable names instead of doing all the

close quotes and plus sign stuff to build up uh queries in a much safer way the last one at the bottom like the I guess that avoiding in direct use of user controlled string literals again always a really effective thing the deliberately contrived thing I showed you where you could have searched for email name or or whatever Fields could could have just been prevented with a drop-down list that M numbers on the server side onto allowed fields so like some examples so safer statement construction there you would either you you you would um I either Escape single quotes or or use that uh double quote operator that I've just mentioned

and again same thing there that's proper input validation but that uh final thing at the end that is how you would apply user mode to a search so that it only searches objects that are readable or modifiable by that user okay that's covered a lot of the sazzle stuff the the payloads for sole are quite different as you seen from SQL injection I'm really doing this talk because Normal payloads in my fuzer didn't find it but so I thought other people should have some workable payloads for for SQL injection payloads should I identify SOC injections so much less of a need for for for that sort of discussion here so just brief conclusion as I said

you can read faster than it and talk but yeah we've seen it's an information disclosure issue the the main issue here is whether or not somebody can see hidden data that they shouldn't be allow to it's quite counterintuitive for anyone used to SQL injection because rather than being some user injectable thing in the select statement it can be uh stuff towards the the end of the statement in in other parts can be quite sort of much more useful than what you might class as a useful injection point and SQL injection but uh I guess the other sort of thing to take away from this is around uh user permissions and what is re requir by the

client or person running that instance it's it's not really not an issue if all users should be able to see more d but this is what I've achieved in like a a short space of time it's only I guess an introduction to to to the subjects and based on my experimentation so if anyone wants to do more research based on that and I hope this is a suitable starting [Music] point are there any questions yeah

can we have a first round of applause first for [Applause] next uh thank you that was a nice talk I just wanted to ask that one if there is any automated tool like SQL map you know that automates the process of um exploitation of uh this this V ability that you have described social injections and other injection the other uh point is about the use of colony you know which you described as much safer than the function so what could be the possible reasons you reason that you know the colon function is much more safer than you know the escaping functions and sanitization functions thank you um I guess it it's kind of safely sanitizes what's being imported into

that statement and the the way you might have seen it in some the way some languages like C it if you've seen the way that builds safer Dynamic SQL statements they that they are sort of sanitized before being used there by the system so is it the equivalent of I would say the parameterized cues in SQL yes okay yeah now I get it thank you and in terms of the automated tool for exploitation of these issues is there any tool that automates the process of exploitation I didn't find anything I've done the talk because I found nothing online at all okay thank you thank you um So within your talk you described as an example somebody being

able to select the description of secret contract or something like that trying P information is there anything that tends to Exist by default which would be of interest to to an attacker that they could regularly pull out potentially this would probably be a good time to go back to the I'm not a Salesforce experts slide um how prevalent is this vulnerability in your experience is it in every application using SLE or is it pretty rare um I'll caveat this by saying um the the number of sole applications I've come across and tested has been single figures not double figures um there's been I guess

uh it's had it's bit been there in in in all of them but with that level of seriousness caveat that a lot of these implementations all used users were allowed to see all data anyway so although there were no fixes in place there was also no damage being done the the real thing that came out of it was I think the lack of awareness of it means for egotistical purposes you can find issues that weren't found on previous tests or or the other people have missed or that haven't been fixed it it's it's certainly something I've been met it it's been met with confusion every time I've raised it when I have found it and and but a lot of the time it's been

found in in a a really nonserious kind of way if I know it's not the best sort of most helpful and ser um maybe just one question from my side are you aware whether any application Cod scan tools would pick that up is it in scope um I I've been told that some uh commercial tools would will search for it or locate it um I think I saw someone online saying check Mar will find it I don't know if that's true but I'd also be interested to know how they uh went about defining how to find it because there's I I guess so little information about the issue okay if there are no more question

thank you very much Nick and a big round of applause for you