GitHub GitHub Universe 2022 - Security, 21 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Find vulnerable Kotlin apps while testing CodeQL - Universe 2022

Description

Presented by: Tony Torralba

When adding analysis support for a new language in a SAST tool, the best way to verify that it works properly is by using it on real projects and finding real vulnerabilities. This talk will cover how Tony and team did just that for the Kotlin language in GitHub code scanning and how the team uncovered vulnerabilities in five popular open source Android projects. Tony will explain the details of each vulnerability, how the team modeled them as CodeQL queries, and how the team helped the maintainers to fix the issues.

As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub

Thanks!

Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github

About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com

A

A

I'm, a software engineer here at GitHub and my day-to-day consists on writing some code that analyzes all the code and tells me whether it contains security vulnerabilities or not and where they are, which is pretty cool. If you ask me, I really: love looking for vulnerabilities, getting things broken and then helping fixing them and it's the best feeling in the world. So that's what I'm here to talk to you about today we will see how we used an in-development feature of a tool called codeql to actually find vulnerabilities in popular open source code link projects.

A

You will learn things about Android security code, ql and disclosure processes that hopefully will help your day-to-day. This is code scanning code scanning is a feature, a GitHub Advanced security that analyzes the code in a GitHub repository and find security issues and coding mistakes. It can be used to triage and prioritize security fixes and helps the developers not include the same mistakes over and over by scanning, all the peers and all the changes in the Repository.

A

Now, behind the scenes what's used to analyze the code in the repository is a tool called codeql and codeql is the analysis engine developed at GitHub that basically analyzes the code and extracts a special database which contains the abstract, syntax 3 the control flow graph, the semantics of your code and lets you query it using declarative, object-oriented language to ask you questions and get answers back now.

A

What we've been doing recently GitHub is adding the ability to scan the golden language with code ql, which wasn't previously possible, and there was a lot of engineering work going into this, like identifying the language elements of kotlin, making sure that it remains consistent with other languages like Java, but yeah. What I actually want to talk to you about is what we did after this basic language support was added to codeql. Once you have this basic support, and you know that. Well, this mostly works.

A

We have our unit tests, we have our integration tests, but after that, um what can we do to verify that what we built is actually working well, what we did is getting a lot of Open Source cuddling projects out there at GitHub and just getting them and running the ql analysis on them and seeing what we obtained. The thing is that if we start getting results, we are verifying two things: one that the language super works, because the language is being recognized.

A

Some issues are appearing and two if these results are correct and are true positives, we've actually found security issues in real projects used by real users out there. So we can report those to the maintainers and help improve the security of the world software. So that's great and that's exactly what we did. So this is the story of some vulnerabilities that we found using this method and the first one is a good all. Sql injection found in an Android called Lin open source application. Now the term SQL injection might be familiar to you.

A

This is one of the classic vulnerabilities and it's based on external input being appended in securely to an SQL statement in your application, so that the code that gets executed in the database can be manipulated from outside the good thing about how we built the content. Language support is that the existing work, the existing queries and libraries for the Java language could be reused in the kotlin language, so the SQL injection Java query was used right away out of the box in all of our codeine analysis.

A

So we didn't do anything new for our analysis to pick up, SQL injection results in these applications. Now you may be wondering why are you talking about SQL injections in Android devices? Application? Isn't that something more common in server-side applications which usually interact with databases? Well, in fact, Android applications also interact with databases, specifically sqlite databases locally in the device, and the only thing special about them is that if they want to actually export those databases that information to other applications in the same device, they use something called a content provider.

A

Now, content providers are interfaces that you implement in your application and act as a bridge between your data, storage and other components in the device so that they can communicate. The problem is that if this is implemented badly, then that external information coming from untrusted sources could end up in SQL statements used to query the database and that could reproduce the SQL injection problem in your application.

A

Now the only thing that codeql needs to know to be able to analyze those content providers is that those public methods, those parameters in the content provider interface are externally provided. So they cannot be trust, and this in the cultural world is called adding those as a source. So once you add those sources and you let calcul know that this cannot be trust, then the existing SQL injection query for Java can pick up also for kotlin security issues in this class. Now we did exactly that.

A

We run the SQL injection query in all those kotlin projects and one of them produced an interesting result which we assign this ID through the GitHub security lab, which is the team that usually reports the security issues that we found to the open source project maintainers. But the problem is that this issue hasn't been fixed as of today. So this means that we cannot discuss its details publicly because we follow responsible disclosure practices and we can't talk about unfixed issues for the security of users.

A

So sorry about that, instead, I'm going to talk about a very similar example that we found the previous year in another application, with a very similar encode pattern. Same query just in a Java project, instead of a cutling processor. This was found in the next Cloud for Android. App next cloud is a server which is mostly used to share files between users and organizations in a secure way, among other features and the next Cloud for Android application is actually a client for that.

A

So you can manage your files from your device and, as you can see in the screenshot, this was using a content provider and it did exactly what we explained. It's taking parameters from those externally accessible methods and the screenshot. You can see the sort order parameter which was one, but not the only one of the vulnerable parameters and I just using that in an internal method that is concatenating the these days externally provided data in an SQL statement. So we found this issue.

A

We reported it to the maintainers and we always include a proof of concept exploit in our reports and that's just because it's easier to understand the impact of a vulnerability. If you can see it working, if you can see it being exploited, so it's a good practice. We always include that, and that also is a validation that the vulnerabilities actually exploitable. It's not necessary that you understand all the code in here. I just want to highlight a couple things, one of them being the Yuri.

A

That's been highlighted there, which is the content you're used to Target these specific content provider, the vulnerable content provider of this next cloud, Android app, and then you can see some SQL code being injected in that column of an update operation in that database. The details of it are not important. The thing is what can be done with this exploit, and here we can see a couple examples.

A

One of them could be querying the sqlite master table to explore the database and obtaining the names of of all the tables in the database for further exploitation or another example could be stealing all the tokens from the OC shares table. Those tokens are used to generate safe links that you're intended as a user to share with specific individuals that you want them to access to the file pointed by the link.

A

Now the Assumption here is that only those with link can access the file so that, if any application installed in the device of on the same device as next Cloud for Android can exploit this vulnerability and steal these tokens, it means that they can regenerate those links and access the files without permission so pretty impactful.

A

We reported it with this proof of concept exploit and the next Cloud 400 maintainers fixed it like you see in the screenshot they, basically once they were aware that those pieces of data could not be trust, added validation to them to make sure that they didn't contain dangerous SQL code. We reviewed this patch, we found it to be enough and correct, and the vulnerability could not be reproduced after that, so we gave our thumbs up. They published the fix. The new versions went out, users could update and then be safe from this issue.

A

So that's great a great story um and it's the first vulnerability. Now, let's talk about the second one. In this case, we needed to do more work like the previous one, and we found that while we were analyzing other kotlin open source applications, we found some of those that are intentionally vulnerable right. This is done sometimes for educational purposes or for benchmarking purposes. You people create intentionally vulnerable apps with vulnerabilities in them, and they also provide a catalog with the vulnerabilities that the application has.

A

So that's very handy if you want to test your analysis, engine or your analysis tool, so that you know whether your results are missing, something or finding something that isn't actually there, and while we did that, we identified one vulnerability that wasn't being detected in one of those applications. That could be due to two things: one, the language analysis, not working properly or two that that was working properly. But we didn't have a query for that vulnerability class. It turns out, it was the latter, so we thought.

A

Well, then, let's add a query for that and we could start detecting this kind of vulnerability and that's what we did. We called the query, intend Theory permission, manipulation and we just needed to cover the new pattern of the vulnerability. Now. This vulnerability is about content providers again and it exploits a security feature in Android, which is aimed at users or developers that don't want to export their content provider completely.

A

You saw in the previous vulnerability way that could be a problem, but they still want to share some pieces of data with our applications in a more restricted way. Now what Android lets you do in those cases is provide the target application, the one that you want to give access to your content provider, a specific intent in this star activity call. So you start that application with that intent and it must contain specific data Theory pointing to your content provider, to the specific piece of data that you want to share and then some flux.

A

Those flags indicate the permissions that the application will have over your content provider. Those could be read, permissions, write permissions or both once you do, that Android understands that you're giving access to this application to your content provider and lets it access it. Even if it's not exported to anyone else so far so good, this is a very fine grained permission system, so everything looks fine. The problem comes when an attacker application wants to access your content provider by exploiting this.

A

Without your permission, so if they can trig your application to actually reflect backed such an intent with containing those pieces of data that the attacker application needs to actually access the content provider, then the problem can reproduce so what attackers do to exploit. This is basically start your activity with this star activity for result call- and this is a normal star activity method. It just tells Android that the starter application is expecting a result back and the result is return it as an intent too. So that's step one.

A

The attacker includes that instant with those data and flags that they want back, wants to access the content provider and then, if, for some reason, the victim application uses this set result call which is used to return the result when Star activity for result is used, and they include the obtained intent, so they just call get intent from whatever application started them and reflect it back with set result after adding it some data, then suddenly from the Android operating system point view your application has given access to the attacker application without you knowing it.

A

So this query we are creating needs to follow the structure of a data flow query. Data flow queries have three specific elements, the first of them being the sources we already discussed them. These are the untrusted pieces of data that you want to be careful with in this case, this is represented by the get-ins and call where you obtain the intent of the application that started you, and then you have the syncs the nodes at where the vulnerability occurs.

A

In this case, being the set result, call receiving an incense and returning it back to the calling application. So if you find a path from a source to a sync, then a data flow query will have a result. Optionally, you have these sanitizers, which are nodes and that if those the path of the vulnerability goes through them, they neutralize the vulnerability.

A

In this case, for example, if you delete the flux from the intent that you obtained from the attacker application, then even if you return it back since it doesn't contain this specific piece of data that it's needed for Android to give the permissions, then the problem cannot reproduce and the vulnerability cannot be exploited. So this is what we're looking for paths from a source to a sync that don't go through a sanitizer like you are seeing on the screenshot.

A

We built this query following this pattern and we run it against all those open source coding projects and again we found an interesting result this time in the WordPress 400 application. Now you might recognize the name WordPress. This is a very common content management system used to manage your blog sites or your websites in a user-friendly way and the WordPress 400 application is again a client for it that lets. You manage your website, your blog posts through your Android device.

A

The query showed the result that we're seeing here in the in the screenshot and as you can see, it basically reproduces the pattern that we previously explained it obtains get intent adds in some data that we don't care about and then reflects it back through set result. So this looked vulnerable.

A

Now again, we created a proof of concept exploit to this report and, as you can see here, we started targeting the vulnerable activity, in this case edit post activity and added those dangerous Flags, those critical flux to the intent to obtain access to the content provider. Then, after that we add some data just for the activity to not error out, and then we add this piece of data, the data theory that points to the content provider that we want to access now. This vulnerability is interesting because it depends on the content provider, implementation.

A

It depends on what it does so in this case, WordPress for Android had a content provider that gave access to the external storage of the Android device. External storage is usually the SD card of your device, and applications need special permissions to access that, so that the user is aware that the application is doing something with the external storage now WordPress for Android has that permission, because it has a content provider that interacts with it.

A

But by exploiting this, our application could avoid the necessity of having that permission to actually read or write from the external storage, because it's using Wordpress for Android as a proxy to access it and from the Android operating system point of view it's WordPress branded, who is doing the access.

A

So this is kind of like an elevation of privileged vulnerability. It lets you bypass some needed permissions and, of course the impact depends on what's happening on the external storage. Maybe someone some other application is writing some sensitive data in there and you can read it or it's reading data from there to perform some critical operation and you can manipulate that process. So it really depends, but still is an interesting vulnerability, and then we reported it to the maintainers again and that's how they decided to fix it. They actually made the vulnerable activity.

A

Just not exported They removed the access from any other external component to it, without changing a line of code, which is a valid fix, even if a dangerous one, because if at some point this was exported again for some reason the vulnerable code will still be there and the vulnerability will still reproduce. So it's not as safe as fixing the actual code, but from code ql's point of view. This is like removing the source because we are parsing, these XML files to see which activities are exported and only those exported are sources.

A

So from code kills point of view. This vulnerability goes away, and indeed it's not longer exploitable, but there's this inherent risk now. The good thing is that we have this query now. So if this application enabled code scanning on the repository and let code ql queries run on it, they will see this alert if they enable this activity again. If they exported it again. The query will alert them that the vulnerability came back, so it hopefully shouldn't reach end users again and now for the third one.

A

We can see that we actually found its pattern in three different kotlin open source projects, so it seemed more common. We call this vulnerability and save content Yuri resolution, and you will see that it has to do with content providers, but now it's at the other end of the communication, it's at the client side of a content provider on communication there, but first, why we decide to create this query. As you can see here, there are four cves in the Android open source project itself.

A

That has this issue at the root of its cost, so in the Android SDK and the Android default applications that go into your device four different times. This issue created a vulnerability, so it seemed common enough for us to create a query and maybe found results outside in other applications, since Android itself was vulnerable to this more than once so it seemed interesting. Now. The vulnerability itself is about letting external users, our external components, decide which content provider you're going to contact.

A

When trying to query One content provider right so for that you use this content, resolver object and normally you would pass it a Content Theory, as we previously saw in our exploits and that contain Yuri points to the content provider that you want to Target. Now. What some Android developers might not know is that the content resolver object, also handles Android resource and file schemeries and, as you can see in the code at the right, which is extracted from the implementation of the content, resolver object.

A

There are specific handlers for those two schemes and they don't go to any content provider. They just go to the local file system and read a file from there and return it back. So this seems a little counter-intuitive you're trying to Target a Content resolver. But if certain theories are passed, you instead read from the file system, which could not be expected, and if you don't control the you are actually using in this call, but things could happen now.

A

This is a different kind of query, because local files could be targeted by these content resolver code, but it all depends on what happens with those files later. It won't always be a vulnerability, 100 exploitable, it's an unsafe pattern, so it probably should be fixed, but sometimes it will give false positives right. It will have less Precision. It will require some manual triage to determine. Is this exploitable really or not?

A

But on the good side it has potentially more results, because if you wanted to make this query more precise, what you will need to do is model all the dangerous things that can happen with that file. After reading it and that's difficult to do, there are a lot of things that can go wrong with files that could be renamed. It could be updated, they could be uploaded, they could be removed.

A

So if you try to model all of those, probably you will miss some in your query and then you want alert on those specific problems, whereas if you only care about the content resolution part- and you say this shouldn't happen- I don't care what happens later.

A

You will definitely catch those cases, so this isn't a query too oriented towards developers because Developers care more about very precise queries that don't give false positives. They only want dollars when they need to actually find something, but it's more oriented towards security researchers, because those don't care that much about about false positives as long as they can find interesting results, even if they have to do a little of manual work. So that's why it's a different kind of of query Now.

A

Using this query, we found results in three projects, as I said, one of them being the tasks application, and this is an application to manage your tasks in your random device. Maybe your reminders, your calendar events like a sticky notes, kind of up and, as you can see in the code here, the app is obtaining some external data, passing it through some methods and finally reading a Yuri from it and passing it directly without validation to this content.

A

Resolver call now here's where the issue can happen, and this would be the proof of concept exploit that we use to report vulnerability. As you can see here, we are providing a Yuri to our local file to a private file of this application that we want to actually exfiltrate, because what the application does after it reads, that file is copying to a public directory in the device which means that any application in the same device can read that file.

A

In this case, we are exfiltrating its database because it in some configurations when it's using some Integrations, it can contain credentials. So it's an interesting file to steal from an attacker point of view. We reported this issue with this proof of concept and what the maintainer did to fix. It was actually applying validation to these externally provided Yuri.

A

It made sure that it only could contain or could use the content scheme, so no file scheme, not Android resources scheme and also it made sure that it was not targeting internal content providers of the application itself, so that this could only target external content providers of other applications that want to share their files with tasks. So this seemed correct. We validated again this fix. We gave our thumbs up. The vulnerability is no longer there.

A

Patches are out so another success case of this story, and that should be it. These are three different examples of the vulnerabilities we found following this process. While we were testing actually a feature of the code language, we managed to find real vulnerabilities and report them to maintainers to improve their security. In the end, we found five different bowler Villages. Four of them have been triage, so they have been already fixed or are being fixed right now and from those two of them.

A

We know that are already fixed as of today, as you saw in the previous examples, so that's it. Hopefully, you learned some cool things about Android security, about disclosure processes or of codeql.

A

In any case, thank you for being there and see you in the next one.