Sean Martin sits down with Abraham Aranguren at the OWASP AppSec Global event to explore the complexities of mobile application security and effective strategies for identifying vulnerabilities. Tune in to hear real-world examples, actionable insights, and best practices for building and maintaining secure mobile apps.
Guest: Abraham Aranguren, Managing Director at 7ASecurity [@7aSecurity]
On LinkedIn | https://www.linkedin.com/in/abrahamaranguren/
____________________________
Hosts:
Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]
On ITSPmagazine | https://www.itspmagazine.com/sean-martin
Marco Ciappelli, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining Society Podcast
On ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/marco-ciappelli
____________________________
Episode Notes
In this On Location episode recorded in Lisbon at the OWASP AppSec Global event, Sean Martin engages in a comprehensive discussion with Abraham Aranguren, a cybersecurity trainer skilled at hacking IoT, iOS, and Android devices. The conversation delves into the intricacies of mobile application security, touching on both the technical and procedural aspects that organizations must consider to build and maintain secure apps.
Abraham Aranguren, known for his expertise in cybersecurity training, shares compelling insights into identifying IoT vulnerabilities without physically having the device. By reverse engineering applications, one can uncover potential security flaws and understand how apps communicate with their IoT counterparts. For instance, Aranguren describes exercises where students analyze mobile apps to reveal hardcoded passwords and unsecured Wi-Fi connections used to manage devices like drones.
A significant portion of the discussion revolves around real-world examples of security lapses in mobile applications. Aranguren details an incident involving a Chinese government app that harvests personal data from users' phones, highlighting the serious privacy implications of such vulnerabilities. Another poignant example is Hong Kong's COVID-19 contact-tracing app, which stored sensitive user information insecurely, revealing how even high-budget applications can suffer from critical security flaws if not properly tested.
Sean Martin, drawing from his background in software quality assurance, emphasizes the importance of establishing clear, repeatable processes and workflows to ensure security measures are consistently applied throughout the development and deployment phases. He and Aranguren agree that while developers need to be educated in secure coding practices, organizations must also implement robust processes, including code reviews, automated tools for static analysis, and third-party audits to identify and rectify potential vulnerabilities.
Aranguren stresses the value of pentests, noting that organizations often show significant improvement over multiple tests. He shares experiences of clients who, after several engagements, greatly reduced the number of exploitable vulnerabilities. Regular, comprehensive testing, combined with a proactive approach to fixing identified issues, helps create a robust security posture, ultimately making applications harder to exploit and dissuading potential attackers.
For businesses developing apps, this episode underscores the necessity of integrating security from the ground up, continuously educating developers, enforcing centralized security controls, and utilizing pentests as a tool for both validation and education. The ultimate goal is to make applications resilient enough to deter attackers, ensuring both the business and its users are protected.
Be sure to follow our Coverage Journey and subscribe to our podcasts!
____________________________
Follow our OWASP AppSec Global Lisbon 2024 coverage: https://www.itspmagazine.com/owasp-global-2024-lisbon-application-security-event-coverage-in-portugal
On YouTube: 📺 https://www.youtube.com/playlist?list=PLnYu0psdcllTzdBL4GGWZ_x-B1ifPIIBV
Be sure to share and subscribe!
____________________________
Resources
LeaveHomeSafe Pentest Report: https://7asecurity.com/reports/pentest-report-leavehomesafe.pdf
CoverDrop Pentest Report: https://7asecurity.com/reports/pentest-report-coverdrop.pdf
Why You Need a Pentest: https://www.youtube.com/watch?v=oBVTlKrLw-k
Learn more about OWASP AppSec Global Lisbon 2024: https://lisbon.globalappsec.org/
____________________________
Catch all of our event coverage: https://www.itspmagazine.com/technology-cybersecurity-society-humanity-conference-and-event-coverage
To see and hear more Redefining CyberSecurity content on ITSPmagazine, visit: https://www.itspmagazine.com/redefining-cybersecurity-podcast
To see and hear more Redefining Society stories on ITSPmagazine, visit:
https://www.itspmagazine.com/redefining-society-podcast
Are you interested in sponsoring our event coverage with an ad placement in the podcast?
Learn More 👉 https://itspm.ag/podadplc
Want to tell your Brand Story as part of our event coverage?
Learn More 👉 https://itspm.ag/evtcovbrf
From Theory to Process to Practice: Cracking Mobile and IoT Security and Vulnerability Management | An OWASP AppSec Global Lisbon 2024 Conversation with Abraham Aranguren | On Location Coverage with Sean Martin and Marco Ciappelli
Please note that this transcript was created using AI technology and may contain inaccuracies or deviations from the original audio file. The transcript is provided for informational purposes only and should not be relied upon as a substitute for the original recording, as errors may exist. At this time, we provide it “as it is,” and we hope it can be helpful for our audience.
_________________________________________
Sean Martin: [00:00:00] And hello everybody. You're very welcome to a new on location here with Sean Martin. I'm coming to you from Lisbon for OWASP AppSec Global. And, uh, it's a fantastic event. Uh, two days, well, three days of training and two days of, of, uh, presentations covering all things AppSec and DevSecOps and everything in between.
And, uh, as you know, I've been talking to some of the speakers and trainers. To get a better picture of the state of, the state of, uh, affairs in, in AppSec. And I'm thrilled to have Ibram Erengarinen, uh, who did a training on hacking IoT, iOS, and Android. Yes. And glad to have you. It's been really good to meet you as well.
Abraham Aranguren: Thank you. So, so, yeah, so I was, uh, I never have an angurum from 70 security and we were doing the training for Android and iOS apps. [00:01:00] And then another interesting concept that we have in the course is to find IOT vulnerabilities without even having the IOT device. Just by reverse engineering the Android or the iOS app, right?
So, so we have some exercises where we give the students, uh, mobile apps, uh, and then they, they are supposed to use like the techniques that we teach during the course to reverse and analyze the applications. And then, for example, say, okay, This application is supposed to manage like a drone, right? So how does the application connect to the drone?
Is there a Wi Fi hotspot? Is there any password on the Wi Fi? Is there a hard coded password in the code of the app, right? So all these issues you can find just by reversing the application without even having the IoT device, right? So we have Some exercises like that, and then other interesting things we, uh, covered that, uh, our students found interesting are some applications [00:02:00] that, uh, Chinese police and the Chinese government use in China.
that we audited some time ago. So for example, there's an application called BXAQ that the Chinese install in your phone when you cross the border and then they grab all your contacts. Is this everybody? Yeah. Yeah. Well, not everybody. I think they do it like selectively, like if you look suspicious or something, I don't think it's like a hundred percent, but a lot of people, they get these applications.
So they ask you to unlock your device and they install this application. They run it and then they uninstall it. Right. But what the application does is. They install it and then it grabs all your contacts, all your SMS messages. Uh, a lot of information from your phone, what, what applications you have installed and other data like that.
And then they compress a zip file and they send it to a police server, right? So we did the reversing of this app. And this app is one of the apps that we also give to the students to play with and investigate and so on. And then we also, of course, covered like more traditional, like mobile application security [00:03:00] type of bugs.
So we were teaching, for example, things like task hijacking. Uh, screenshot leaks, uh, file system, uh, leaks, right? So So, so for example, and when I was teaching like the, uh, some of these vulnerabilities, I was giving them examples from the field, right? So we audited this application in Hong Kong, there was a COVID 19, uh, contact tracing application called leave home safe.
And uh, so for the, because I was talking about the file system, right? So yeah, Uh, this application, you could have like your COVID vaccination records in Google Drive where you require like authentication, probably also a second factor to log in. And then you could upload this file, uh, this like COVID vaccination to the Live Home Safe application.
And then the Live Home Safe application would leave this on the SD card of the device, right? So in Android, you don't even need to unlock the device. You can like physically extract the SD card in many devices and then just plug the SD card to a computer and you can read everything, [00:04:00] right? So it's amazing they spent like 7 million, uh, on this application.
And, and it had flaws like this, right? So this was for the file system, uh, like a big one on Android is the SD card just because physically you can extract it and read everything. Um, now that I'm talking about leave home safe, uh, when we were teaching about the man in the middle and the correct validation of SSL certificates and so on, the leave home safe application had a big vulnerability as well here.
This was the worst that we could find actually, which is that it had this code snippet. Like if I'm connecting to these Hong Kong health system, uh, website that the application uses, then skip the hostname verifier. Of SSL, right? So the attacker requirements to exploit this would be either wifi without guest isolation to have money in the middle.
Or you could even pull it off with DNS rebinding. So you could have, you don't even need to be in Hong Kong. You could be [00:05:00] like anywhere in the planet and as long as you reply with a very short DNS TTL, uh, spoofing this domain for the Hong Kong health system and pointing to the attacker server, then people in Hong Kong would log into your server instead of the other one.
And then what you have to show is like a valid, Uh, SSL certificate for attacker. com, uh, and because it's a valid certificate for attacker. com, the application tries to use this and says, oh, it's, it's signed by a CA, yes, but it's keeping the hostname verifier. It's a certificate valid for attacker. com. For attacker.
com, not hongkonghealthsystem. com, right? So this part of the validation is what they, uh, basically had like this snippet. They probably needed this in development or something for, and they forgot to remove it when they released, uh, into production. That's what it looked like, right? So, So yeah, this was to make it easier to test.
Yeah. Yeah. So it's typical, right? And then what would [00:06:00] happen with this is you can have an attacker that can get all the credentials for all people and the second Factor and everything to people using the health system in Hong Kong, right? Then eight million people were forced to use this application And they spent seven million dollars to do it.
And if you uploaded just the APK to MobSF, which are very popular tool for like analysis of mobile apps, you would have like this huge warning, like at the top, like critical man in the middle with this like code snippet. Right. So I don't know how this happened because like, even like basic static analysis would have caught these like, uh, uh, these like a man in the middle thing.
Right. But I don't know, they missed it. And, and since I'm talking about leave home safe, uh, another interesting question we got during the class is, oh, but static analysis is going to find everything and so on. And I said, not really
because
there's a lot of attacks, uh, in mobile and as well as web security and other fields of security [00:07:00] that are more kind of business logic or logic flaws.
And then I gave them an example from the leave home safe application as well. where they had this feature that to view the electronic records on the device, you, uh, you clicked on the electronic records and then it would prompt you for your Touch ID. But you could go into the settings, disable Touch ID, the settings of the application itself and disable this protection for the Touch ID.
And then you go again and it doesn't prompt you for the Touch ID, right? So it should, to disable this feature, it should prompt you again Right. For, like, do you want to disable Touch ID? Okay, put your finger, right? And then, yeah. But they didn't, they didn't do this. So both in Android and iOS, you could bypass the fingerprint check, like, uh, just going to the settings.
It's like, I always explain to the students, this is like an attacker that even your grandmother could do, right? Just going to the settings, disable this, and it's a logic flaw, right? And in mobile security, you find this a lot. When there's any sort of log screen or the application prompts you for a [00:08:00] pin, and then maybe in Android you can invoke, uh, the home, uh, activity.
And then this gets past the prompt, right? Uh, or in, uh, in iOS or Android, you could also do it sometimes with a deep link. You send the application that deep link of another screen, and then it shows you the other screen that is past the prompt, right? So. So these are examples of logic flaws. And that's in iOS as well.
Yeah, yeah.
Sean Martin: Because they have a lot of controls, obviously, for that.
Abraham Aranguren: Yeah, in iOS, it's generally a bit better in terms, like, you don't have, like, a bunch of activity services and other functionality like in Android. But you can also have this type of functionality with deep links, right? So you could have an application that has, like, a bunch of deep links, and each deep link opens, like, a different screen.
So you could also do this type of attack in, in iOS with a deep link and you just send the deep link and then the application opens the home screen, for example, and you'll pass the prompt, right? So, you know, you don't need to do this.
Sean Martin: And for those listening, an example [00:09:00] of where that's supposed to work, I'm correcting if I'm wrong, but that's, uh, might be you're in your photo app and you're, you're going to open into, uh, A photo editing app.
Abraham Aranguren: Yeah. Yeah. That would be an example of using a deep link or sending data from one up to another. Yes.
Sean Martin: Yeah. So you want that capability? Yes. Yes. You want to make sure that it's
Abraham Aranguren: yeah, that it doesn't bypass security controls.
Sean Martin: Yeah. So if you're a, if you're an app that has security concerns or safety protections in place.
Yeah. You want to make sure that the inbound is not nefarious. Yeah. Deep link. Right.
Abraham Aranguren: Yeah. Yeah. You would. Yeah, exactly. So you, you want Both to ensure. So there's a few things, right? So one would be in the case of a lock screen, you want to make sure you remain in the lock screen until the user has entered the password or the finger or whatever.
Uh, and then another example, since we're talking about this topic that I showed to the students is, is the validation, right? So, uh, with DeepLinks, for example, you [00:10:00] can, or we had this application that I also showed during the course. There's a very interesting attack where. Uh, the application basically logged, uh, logged users by connecting to a Google, uh, authentication, right?
So it will open a pop up to log in with Google and then do log in with Google as normal. And then this pop up would close and send a deep link to the application. And then the application would save the Google token and from there it would just log in as the user, right? So all this is kind of the intended functionality.
The problem was they had a SQL injection on the mobile app. With this token, right? So you could send an invalid token that had like a single quote and then you break out of the SQL query So like SQL injection, right? and then so we had like this SQL injection on the Android app, but it got worse because This Android app was using SQL cipher, which is a SQLite extension.
So because it is a SQLite extension extensions have to be [00:11:00] enabled, which is not the default in SQLite. And when extensions are enabled in SQLite, you can do select load extension, and you specify the path to the extension, and you can run any code you want. So you have SQL injection that you can turn into remote code execution.
Right? So we showed a few, uh, examples to exploit this, right? So one could be a malicious app on the same device. You could create your so library. Right? And then you exploit the SQL injection and do select load extension of the path to your file that you give all the other apps in the device permissions to read, of course, because you want to exploit them.
And then, and then the application runs the SQL, tries to load the extension, and then you have remote code execution with the permissions of the other app. And it was also possible to exploit this from the website. So we had, we also showed an example of this. So we had like two iframes. The first iframe started downloading the SO file immediately when you visit the attacker site.
And then the second [00:12:00] iframe waited like five seconds. And then changed the source of the second iframe to use the deep link with the SQL injection. And then it would load it from the MNT card. Downloads directory, it would load this binary and then you, you know, like from an arbitrary website you could get remote code execution, uh, with the permissions of this application on the device.
Right. So it was a very cool attack and I was also explaining to the students because it teaches you a lot of things, right? It teaches you a validation of deep links, right? So the first thing from a security perspective is, is if you're expecting a token from Google, why are you accepting single quotes, uh, and all this, right?
So this would be the first step for validation. The second step would be if you are running a SQL query, don't concatenate user input with the SQL query. You should have bind variables to completely separate what is data from what is instructions, right? All injection attacks happen when data and instructions are merged together.
[00:13:00] So you want the strongest possible separation, and normally databases give you this capability to have like bind variables. So it would be that and then the other topic would be more difficult because they were using SQL cipher. So they actually need to have extensions enabled. But if you didn't need the extensions and you disable this, at least you wouldn't have the remote code execution.
Right. You know, so that would be the other one. But, but this one would be like less, like more difficult in this case, just because they needed the SQLite extension, right? Because SQL cipher in general. It's a good thing because it encrypts your database, right? So
Sean Martin: The challenge I see with that last point is The environment is vulnerable with that app extension.
So if somebody does it and that doesn't do it right or correctly, then the whole environment is kind of at risk there.
Abraham Aranguren: Yeah, yeah. So you have the encryption of the database, which is good, but [00:14:00] you need to be sure you don't have SQL injection anywhere. Yeah. Because otherwise the impact of the SQL injection is higher.
It's remote code execution. Yeah.
Sean Martin: Um, Really great examples, and I'm sure I can imagine the fun your students had playing and exploring and hearing all your stories. I'm curious how, there's a few different views for me here. So there's the end user that's the recipient of all this fun, right? Yeah. So we'll leave them aside for a moment.
Not because I don't care about them, but just because I want to talk more about the business end of it. So there's, there's Building apps and then there's running in an environment. Yes, and those are two different things that organizations have to Care about so you talked about a couple different things that maybe you can paint a picture for how organizations might approach a Safe mobile environment for their users end users being in the business or [00:15:00] perhaps customers So there's building apps.
Yeah, and then Knowing that the environment you're in is Safe, which is partly configuring out. But let me put it this way. Back in the day, I used to do quality assurance and part of it was was looking at. I was trying to find paths through the through the function calls and the APIs and whatever to see if I could break out of and do something that's not supposed to where where we found Success was in clearly defined processes and workflows, and we expected to do this.
And if it goes out of those defined areas, then it's a bug. Yeah. Um, I'm just wondering how does, how do organizations today, because with so many maps, so many functions in the app, so many services, microservices pulled into the [00:16:00] apps, how do organizations kind of paint that picture today? To know this is the right configuration.
These are the right workflows. This is, this is what it's supposed to do and exceptions to that. And then, of course, the question is, how do we, how do we deal with the exceptions? Right? Yeah, it's a big question, but just some of your thoughts on that.
Abraham Aranguren: Yeah, it's, uh, it's, it's complicated, right? Because the defender has to defend against everything and the attacker only needs 11 flow to win, right?
Or to make you look bad. So, So the, the answer is really to do everything, right? So you should have, uh, training for developers. So they know how to write secure code. You should also have, um, processes that, you know, like code reviews, like one developer reviews the code of another. Uh, there should also be like, uh, internal tests for security.
People should also try to use like, automated tools. Like for example, in the mobile environment, mobile SAF is open source is free. Anybody can use it. [00:17:00] This is kind of the minimum, right? Uh, every developer, like before putting their application on the internet, right, they should upload it to mobile. It is be part of the, yeah, it should be part of the internal process.
To, you know, to see, review these findings and try to do something about them and improve things as much as possible. And then, uh, what people ask me all the time. Did you see this or that company get hacked? And I said, I said, yes, I saw it. But you know what? They got hacked because probably they didn't pay for the audit, right?
So whatever, whatever you do, like at the end, you need also to have like a third party to audit the company. Just to get that validation as well. So it's all complimentary, right? So if, if you don't train developers, if you don't do like all these other things that you just do, the pen test is also not good, right?
I mean, you can still use the results of the pen test to teach developers. And this is also like something we advise, but, uh, it's, it all complements each other, right? So, so the best approach is basically try to [00:18:00] do as much as you can regard, uh, you know, with the budget that you have, right? So I would say that like developer education, having processes to like before deploying something, someone else has to approve the request is not like, because you also have the malicious insider, right?
Like even if you're doing everything right, some of your developers could be bought by the Russians or the Chinese or whatever, and they could be putting a backdoor in your application. That's the first thing
Sean Martin: I thought when you mentioned the attacker. com not validating the other one. Yeah. It seems very suspicious to me.
Abraham Aranguren: Yeah. Yeah, exactly. Right. So you could have. Someone planting a backdoor and what processes do you have in your deployment process to catch that, right? And then, and then, yeah, and then you have the third party audit on top of everything. And you just keep doing this and you get better. You know, like we actually, I showed this, I did a talk like, why do you need a pen test?
Uh, you can YouTube with the security repo podcast.
Sean Martin: Uh, so find that I'll put a link into the,
Abraham Aranguren: [00:19:00] yeah, so, so, so these guys that, well, we did a podcast about this and it was really interesting because this was one of the, of the topics, right? So when you do a pen, there's one of the things is that you don't have like false positives, right?
You have like real findings with the real results, but, um, it has, um, you know, a lot of, it brings like a lot of value, right? To the. To the companies because like if, like with the back bounties for example, you get a lot of noise. Like, like people get burned out before because of all the like, bullshit submissions.
Sometimes people also like fake the submissions, like they use like burp out replace or something right. To fake excesses and so on. Uh, and then, oh yeah, and now I remember what I was going to say. So, and then I also gave, in this, uh, in this, uh, podcast, I gave some examples of. Some of our customers, right?
Like the first Panthers we found. Like some high, some critical, the second we, we found [00:20:00] less, but we still managed to find a high or something. But then after the third and the fourth test, we didn't find any directly exploitable anything because that this type of client that by the time we send them the report, they have already fixed everything.
Because during the test, we always share like the interim findings with the team that we always work together with the clients. This is also good because you get like feedback, like what is the business impact of this, right? Sometimes maybe. We think something is critical. We find a very cool payment bypass for Stripe.
And then they said, Okay. These are very cool bypass, but it only works because you're testing on staging and is configured in a slightly different way. But in production, this will never work. And so we, we, we had something we thought was critical. That was info like you can improve validation. Yes, but actually we cannot do anything with this, right?
And then we also have the opposite. Like we file something as medium during the test. And then they said, no, this actually critical in my environment. I don't want any customer to see this data. This in my business. This is not not possible, right? So you get this feedback during the test. So [00:21:00] this client, they, they fixed everything before we even gave them the report.
Right. And, uh, so the first, um, the, I think the first three tests, we still managed to find something right. Some high, some critical and so on. The first two, then the third, there was just mediums. And then from the fourth, uh, and fifth test that we've done for them, we didn't find anything directly. It's all like hardly any recommendation, like, yeah, you can improve this, but we don't have any access, anything serious, right?
No XSS, no, uh, open redirects that we can still token with, uh, for authentication, nothing, nothing serious. Right. So, so this is the value of Appent test is to keep doing them regularly. And then, You know, over time, the vulnerabilities go down on the effort to find any directly exploit or anything goes way up, right?
So I'm always asking clients that we've done like 34 tests for already, like, Hey, can you give us a little bit more time? Because this is going to be hard. Right. Like we know, like, especially [00:22:00] if they've been, you know, taking it seriously and so on. Right. And this is the same when your website is or your mobile application is out there for people to use.
If you've been tested it like three, four, five times, this is going to be hell. Like most attackers are going to say, okay, this is way too hard. I'm going to go to a softer target. And that's it. Yeah. And then you've done your job, right? Because you cannot make an application perfectly secure, but you can make it hard enough that it doesn't make sense to, you know, spend more time on it because there's just way softer target somewhere else.
Sean Martin: I could talk to you for hours, but, um, I'm going to close with this question because you described a scenario where the client is getting better.
Abraham Aranguren: Yeah.
Sean Martin: But at the beginning you described a scenario where. Something silly left in right where, um, the, the, the dev environment setting was in production in production.
Um, to me, that says process is paramount where you have a regime [00:23:00] and you might choose to ignore some steps because you don't have the budget right now, but at least the step is in there. So, you know, and, and. So you do the checks, you do the work, you do the checks, you do the, the validation after it's delivered, um, but that process repeatable becomes ingrained.
Yeah, um, you keep iterating and then you keep getting better. You get better, but because it's a process with all the checks in place, you're not accidentally. Leaving something out. Yeah, and then putting yourself exposed even though you've done all the like the seven million dollar one, right? Yeah, you probably done everything except at the very end.
You forgot to do that one thing because yeah the process broke. So how How when you're engaging with clients? Um, either, how do you advise or guide them or what, how do you experience working with them where they have a good process? I don't know, whatever you want to say on that point.
Abraham Aranguren: Well, we can see this pretty quickly [00:24:00] because of the results that we get in the test, right?
We've had some pen tests that we did where we almost couldn't find anything exploitable and normally this happened because they were Leveraging some library that has already been audited very heavily written by someone else. And they have just minimal code on top of it. Right. So, so the likelihood of them making a mistake is like so small and they also using like good frameworks, like react, for example, you have to dangerously set inner HTML to have XSS like the developer has to write this right to, to have XSS.
So it's kind of warning you, right? It's a, these frameworks are really good. Like they. They have eliminated a lot of the problems, uh, but then what remains is more like access control and logic bugs, things like this, the frameworks will never be able to save you, right? Because the framework doesn't know, like, can user A really read this or is in your business okay if user whatever is able [00:25:00] to read this like admin data or something like that, right?
This is all business logic and logic flaws I think are going to be the future of security. Okay. Just because it is so difficult, right, to like, this is going to depend on the different environment and setup and so on. And this is why we need to keep testing security. But at the same time, it's also possible to have processes and data maps and data models where Where you enforce the permissions, like from a development perspective.
So for example, years ago, I was, I was a developer first. So I was involved in building an application. And then what we did was, when you log in, we would enforce like a series of redundant foreign keys. Of, okay, you are, you are a developer. From this department with this role and so on. So all the, all the tables, all the results in the database are going to be filtered by your permissions, right?
And this was like, like done in a front controller. So there was like no way to get it wrong. Like this would be like enforced in every [00:26:00] SQL query, just the way it was built, right? So you can have some sort of data mapper, That for the developers listening to this, they will probably understand that will automatically like enforce the access rights that you want for everybody in the system.
And then this type of solution is what would be called centralized security controls, right? So if you have centralized security controls really well implemented in one place, this is a lot easier to maintain that if you have like if if whatever, if user admin and then this is like madness, right? As soon as they.
Application starts getting bigger and complicated, uh, you know, like the security matrix is all over the place and you are bound to make a mistake or forget something somewhere, right? Whereas if you have like a centralized security control in a point where you know all the code is going to all the path of execution is going to go through that, then you cannot get it wrong, right?
Because you are like enforcing it by default everywhere, right? So that is kind of the way [00:27:00] of the future. Of, you know, try to centralize the controls as much as you can and try to have like good processes to, you know, review what other people are doing. And yeah, and keep validating it. Right. Then at the end of everything, you also need like the pen test at the end to make sure like, okay, these, we think we've done everything correctly, but, but have we, right.
Let's test it. And you know, you have like an independent third party having a look. And then you use that as input, right? And you can share this report with your developers. And okay, this is what they found last time. So let's, you know, and we had some clients like, uh, yeah, we looked at the because we're doing like the second engagement now and they were like, yeah, we were making sure like everything you found on the first engagement.
That is not there and everything looks okay. And so on. Right. So they were like very proactive, like even before the second test, they were themselves retesting the stuff from the first test just to make sure they don't have anything similar going on. Right. So this is [00:28:00] also something you can do to use.
Pentecost reports as as an educational tool, right? And we were allowed to publish some on our website. So if you go to 70 Secure. com publications, the leave home safe report, for example, that I mentioned before this all public on this other. All the public reports as well. We did another test for the Guardian called cover drop this one.
We talked about yesterday evening about this protocol to anonymize the sources communicating with the journalist and it masks the, you know, the traffic from the source to the journalist with the traffic of the normal users of the app, which send like this, like noise traffic to the journalist, which is It's not really seen by the journalists, but this is like what the cover, uh, cover drop protocol that's right.
So the news, uh, the, so the Guardian newspaper in the UK is using this, but the protocol is open source and any other, um, magazine or newspaper can use this, uh, for the same purposes and so on. And they published like [00:29:00] a couple of academic papers, uh, on this protocol. And we audited this and the report is public.
So you can just search cover drop. Audit report, uh, probably in Google and it will come up as well. Um, yeah, this was very interesting because we did mobile, we did thread modeling, we did, uh, Kubernetes AWS, uh, and, uh, privacy audit as well, I think. And we also looked at the servers. So it's like, you know, regardless of what you are, you are interested in security, you probably will have something, something related.
Yeah. Something related to that. That's right. So yeah, so just reading public pentest reports can be useful. Yeah, very enlightening I bet. Yeah. You know, as an educational tool, right? Yeah. Like it's, it's free to just, it's a PDF, so you just get it regardless of the company that publishes it. And you can say to your developers, look, these are some Penta reports for this, uh, last year from some companies.
Take a look, look at the, for example, if you have mobile, you have mobile developers, take a look at these, uh, [00:30:00] mobile, uh, Penta reports, and let's make sure we don't have flaws like this in our apps. And, you know. It's another way of learning about security.
Sean Martin: I'm glad to hear that, uh, some of those reports, especially organizations that are just starting.
Abraham Aranguren: Yeah.
Sean Martin: Right, where they don't, they, maybe they attend a few OWASP training sessions.
Abraham Aranguren: Yeah.
Sean Martin: And, uh, and get some of the basic, look at the top ten list, things like that. Yeah. But to get actual reports and see it is pretty.
Abraham Aranguren: Yeah, because you get like the real examples, right? People learn more by example. Like sometimes when things are too theoretical, people don't really follow as well, but when I show them an example, it's like, Oh, I understand this.
Like I, this is like a normal app. And I know I understand what request response, uh, you know, like this is the ID to view this record and then I change it or whatever. And you know, So then everything makes sense in the head of the developer, right? Like it's, it's something that I used to work with. Right?
And we also said, for example, in the course, like you don't [00:31:00] send verb screenshots to your web developers because they would have to type the request from scratch by looking at the birth screenshot and in mobile security. You also don't send like a drowser command, you send like an ADB command, right? ADB is the tool that Android developers will use, right?
So you give them an ADB command of whatever you're exploiting and then the developer can run this command and verify, Oh, now I understand, like this is what the problem is. So you try to make the proof of concept in the report more useful to the developers, right? Or another example we'll be using, giving them a curl command as opposed to a verb screenshot.
Right? So bird screenshot, you have to look at the screenshot, type everything by hand to verify it versus a curl command. You can copy and paste and see what happens. Right? And then this is much more useful to a developer to validate a security finding. Let's change the parameters to match your environment.
Sean Martin: Right? Yeah. Yeah.
Abraham Aranguren: And then, you know, just try to make the report and the proof of concepts and everything else useful to the developers to verify the [00:32:00] finding and fix it. Right?
Sean Martin: Super interesting. Super interesting. Well, It makes me want to start coding again. Having this conversation, it brings me back to the old days where I was building stuff and breaking stuff.
But, uh, super fun chatting with you, Abram. I don't like my shirt. And, uh, it was a pleasure meeting you and hopefully we can stay connected and keep chatting about stuff. Um, yeah, you have a lot of experience and I'd love to keep picking your brain on some things. So, hopefully folks got some good nuggets here.
I'll, I'll put I'll find the links to those two reports and, uh, the video that you mentioned of your, I don't know if it's a video or podcast, but I'll find that as well. Yeah, yeah,
Abraham Aranguren: it's a podcast, but there's a video as well. It's called the security podcast, the security repo podcast.
Sean Martin: Alright, so I'll find that episode and link to that for folks so they can catch that as well.
And, uh, thanks again, Abraham. Thanks, everybody, for listening to, uh, this episode on location coming [00:33:00] to you from Lisbon, NOAA's AppSec Global. Uh, stay tuned for more, and, uh, see you all soon. Cheers. Cheers. Thank you.