Hi, everyone. I hope you all are doing well. Welcome to the Fragment session on Plug the Vulnerabilities in your app. I'm Shruti. About me, I work as a security manager at AppSecco. What I do at AppSecco is taking care of clients and ensuring that they have a smooth journey with the work we do for them. AppSecco was founded in 2015, and we are an application security, cloud security specialist company. You can find us at appsecco.com. Also, I will be your moderator for today. So about today's session, the session is going to help you understand the common mistakes mobile app developers make while creating mobile apps. And it'll also help you understand how these apps can be vulnerable and how the attackers perceive the mobile app security. So our speakers will explain to you about the mobile application security and also why API design is crucial. With that, I would like to introduce our speakers for today, Rithi and Riaz. Say hi. Hello. Hello. OK. All right. So Rithi works as an application security analyst at AppSecco. She also leads the Nal Bangalore chapter, which is India's largest open security community. She's a developer and maintainer of YAPI, cloud-based vulnerable hybrid Android app. Then we have Riaz, who works as a head of security research and testing at AppSecco. He's also actively been involved with the Bangalore OAS chapter and NAL chapter for the last seven years. He's also one of the chapter leaders for the OAS Bangalore chapter. So Riaz also frequently lead a speaker at various security conferences and events around the world, including Black Hat, Nalcon, Cocon, and OAS AppSecco. So that's about our speakers today. Also before we start, I want to let you all know that we'll be taking questions at the end of the session. So there is a Q&A section on the Zoom if you're attending from Zoom. And also the YouTube has a chat feature where you can post all your questions. And we'll be answering them at the end of the session. So over to you, Rithi and Riaz. Thank you. Thank you, Shruti. Well, thanks, Shruti, for the amazing and really nice introduction to us and the talk as well. Thank you, Riaz. All right, so today we're going to talk about, you know, it's a cumulative thing about multiple things we've seen. As part of our application security journey back in office, as well as what we see around the world, the kind of issues that testers frequently find with mobile applications and common mistakes that developers do, right? And we'll, as Shruti mentioned, we'll be taking all the questions at the end. So use the Q&A section to post your questions there. And we'll take a look at them and try and answer as many as we can, but in the time at the end of the session. Right, so, Shruti's already done the introductions. That's Rithi, that's me. I'm wearing a hat because I'm a gray hat hacker, so that's how I define myself. As I said, we'll cover what we believe the idea of security is from an attacker and developer perspective. And we'll also take a look at a bunch of weaknesses that we've come across in our mobile testing journey for all of our, a lot of our customers who have mobile applications that they want us to test, right, the kind of weaknesses and the general trend of security issues that we find. Cover things that developers do, but ideally do not, right? And things that attackers commonly go after when testing mobile applications. We'll also talk about some generic things that developers can do that would harden mobile apps and their backend APIs and ensure that not to a hundred percent, but definitely increase the overall security of mobile apps. And I'll come to why I don't say a hundred percent in shortly in the slides there. We also have some bonus content around how do you, if somebody who wants to get started with security testing, right, mobile app securities testing, what are the kind of things, what are the tools you would require, how you would set them up, as well as some resources to get you started, right? And then we'll open the symbolic floor for our Q and A session. All right, so let's try and define what is security, right? And I've put mobile security, mobile application security in the bracket that I'll leave this comic up for a couple of seconds, right? Because there is an underlying message that this comic will pass across. And I'll come to that. All right, so security is freedom from or resilience against potential harm caused by others. This is like the Wikipedia definition. But essentially in the digital world, we are looking at the definition of harm would mean either the loss of confidentiality, right? Commonly see integrity or availability. As you would have seen the CIA triangle that a lot of security testers refer to as well as developers that are aware. Depending on how a violation of the CIA has occurred or a presumed violation when you're figuring out security issues that haven't been exploited yet, right? But you base it on the assumption that either CI or A is going to be violated. What was affected in terms of the component and what was the impact of the violation? As in what was an attacker able to do? And it is in case of a presumed violation, what can the attacker do? We can calculate the severity of the violation. As I showed you the comic earlier, the most secure system is going to be completely unusable. And this comes from, and this is a very popular security usability functionality triangle. The closer you move the black dot towards security, the less functional and usable it becomes. And this holds true for all kinds of systems, right? And not only applications, but any kind of system out there that has these three components independently. So which is why developers find middle grounds and they still end up having bug reports that deal with extremely low non exploitable issues, right? And then there is this whole confusion about whether this needs to be prioritized in fixing and stuff, right? But if you use this triangle to base your judgment, you'd be able to reach a middle ground. This is another obligatory Dilbert, right? As I said, completely unusable, completely secure system is going to be an unusable system. So coming back to the earlier comment I made about mobile application not being a 100% thing, right? Why is security hard with mobile apps, right? The first and foremost and the biggest thing is, aligns also with thick lines, especially desktop applications if you have them running. The code runs in an untrusted environment, right? You may be a seasoned mobile developer and you've written like the best mobile app out there with taken care of all the security aspects of the API, the app and everything, right? But the code in fact is running inside an environment you have no control over, right? And obviously you want to do this because it's a mobile app you want to ensure you can utilize more client processing power, right? It's easier to create, store and manage data as and when required. You can use the, you don't have to necessarily dynamic data when it is being created. You don't have to send it to the server to be stored. The simplified and fast architecture allows, right? The mobile apps to interact with the APIs for state control, right? But because the mobile application is running in an untrusted environment, all whole slew of security issues arise, right? The other thing that we've noticed is business logic and decisions are made client side to increase efficiency. And this could imagine recently we tested an app where there was a mobile, there's a file upload feature in the mobile app, right? When the file upload was successful or rather to ensure that if there is disruption of network traffic while the file is being uploaded, the temporary copy of the file is made in one of the temporary directories in the mobile app, right? And because the business logic ensured wanted, had a requirement rather that the file upload needs to be successful and it was in regulatory requirement for the application. And when the user logged out, the files from all the previous users were being stored in a common directory, right? And that itself becomes a violation because, believe it or not, a lot of mobile apps, mobile devices are shared between users. And I'm not talking only about old uncles and aunties, but even departments and law enforcement agencies that we've worked with in the past have department devices that they share between officers based on shift that they are, right? And there's also a disconnect between developers and security testers as to what kind of issues need to be prioritized, what is the significance of the issues, can we learn from previous bug reports, right? There is definitely a disconnect between developers and security testers and sometimes developers do have to wear a security tester hat and we come to that at the end so that they can understand security from the point of how security testers are looking at the mobile app in the API. Slight of full disclosure, Riddhi and I are not mobile app or API developers, but we definitely understand the security implications of what happens and how do you go about testing mobile apps and APIs, how they can be attacked and what could an attacker do with the access or data, right? More importantly, because all our entire career and Absaco for that matter has aligned with testing mobile applications for customers, mobile applications that back in the APIs, the maps and cloud related infra, that's something that we purely do, right? And which is why we may not understand all the nuances of what a developer does and in terms of mobile apps or APIs, but definitely from a security standpoint, yes. Most bugs that we are going to talk about, examples that we give from developer perspectives, most are what we have discovered in our real world assessments back at office, right? And some of them are really interesting use case studies, case studies that people have blocked about, right? There are a lot of familiar bugs that you will see in the next couple of slides. We will try and skip the why these mistakes occur that would be a subjective opinion. We're not here to, this is not a blame game presentation essentially because we see these mistakes happening day in, day out, but why these happen is a very subjective opinion, right? To understand why these mistakes in code or configuration occur. Next section, things developers do, which ideally they should not a bunch of examples on what we've seen in the past where developers have made mistakes and why and the how of what the mistakes are, right? Riddhi, why don't you take over? Riddhi, you're on mute. Am I audible now? Yes, yes, absolutely. Thank you, Riyaz. Hello all. So as Riyaz mentioned, we'll be looking at a lot of real world examples and this section, the section that I'm going to talk about is specifically about things that developers do that they shouldn't be or yeah. So the first thing is we depend on a lot of third party code, libraries, APIs, stack, overflow and we know that any developer cannot write the entire code and went on their own and we will have to depend on third party libraries and we will have to look into code written by someone else and we will have to depend on them. But for sensitive features and sensitive functionality we will have to be very careful when we are doing so. On the right side, you see there is a picture and it offers various options to you, options to log in. Now one of these had an issue which was reported recently and it was, it is, a zero day was found in sign in with Apple and the person was paid heavily in millions in Indian rupees. The issue was now how the authentication works when the user tries to log in using the sign in with the Apple feature. There is a JW token which is sent by the server and this JW token is then sent to the third party application which is trying to use the sign in with Apple feature. The third party application then verifies with the Apple server if this is valid token or not. If it is found to be valid then user is allowed to log in. What was the flaw in it? The flaw in it was anybody can, which I'll come in the next section. Here the problem was there was some issue. At this point we just need to know that an application is using sign in with the Apple feature which is not developed by them. It is developed by someone else. So in this case Apple becomes the third party. And using this feature it was possible for an attacker to pass any random arbitrary email address obtain a valid JW token and log in as that user. So user impersonation was happening here. Who was the victim? Anybody who was using the sign in with Apple feature they were vulnerable. What was the damage that a full account takeover of user accounts was possible regardless of whether the victim had a valid Apple ID or not. Now this is a continuation of this same issue that we just spoke about, but it is targeting on a different issue. The first we saw that we are depending on third parties without verifying if it is safe to use it or not. Second one is we oftentimes we miss validating authentication issues. So when we are using API and authentication and authorization play a very important role. So in this particular scenario if you see the top request this section here there is one parameter going in request body which is an email parameter and it takes an email. So any user can trigger this request and pass any arbitrary email address. If that is a valid email address then server was generating a valid JW token. And this is how the response looked like. ID would be obtained from here. So there are basically two issues which you could think of which is happening here. One is obviously authentication. Yeah, okay, let's not make the issue. So we are looking at authentication issues. The server is not doing proper validation and it's just accepting any arbitrary email address. This is just one example of real world but in other cases there could be like you have weak password policy because of which I can simply guess the password and login or there could be issues where your app allows both authentication, authenticated access and unauthenticated access. And it might be a case that maybe you have there are authentication has been missed for some screens and unauthenticated user can access that. So there could be authentications in different forms. So we should make a list of all the sensitive endpoints and we should make sure that authentication checks have been done properly for those endpoints. Third one is oftentimes, and I think this is very important because oftentimes authentication is mature. We don't find many authentication issues. We do find in rare cases but authorization issues are something which is prevalent in large scale. And authorization issue is something that we almost find in all the apps. We have found this issue in almost every app that we have tested so far. This is one example. This is not a very typical example but Amazon Cognito, some of you might have heard about it for some, it might be a new term but Amazon Cognito as you see on the screen from the web, it's taken from the website. What it saves is it allows you to handle, it does the sign up sign in and access control for you. So you don't have to write any code. If you just use frameworks like Amplify, you can simply implement this feature for your app. On the right hand side, you see the login page which is generated when someone uses Amazon Cognito. This is just a sample but yeah, it will look something similar to this. Once this has been set up, you can just, users can log in and they can access your app as required. Now there is a feature provided by Amazon Cognito. What is the feature? Amazon Cognito supports unauthenticated identities which allows customers to use the application without actually logging in. So this is not a flaw, this is a feature but there is a flaw which surfaces because of this feature. When we see the overall picture, we found somebody named as Andrea Riancho, he published a paper and the link is down there in the slide. So what happens in this is enabled. If this feature is enabled, that unauthenticated identities is enabled, there are chances that the person can also access your sensitive AWS services. It might be there that this AWS services permissions have not been handled properly and those services could be accessed by someone who has not authenticated themselves to the app. They're unauthenticated users but they are still valid users as per the app. But definitely they are not supposed to access the sensitive AWS services. So this is how the overall picture looks like if you are getting confused by whatever I said so far. There's a user who tries to use your app using Amazon Cognito, they try to sign in and Amazon Cognito user pool sends you a token. There is an ID, Cognito ID, which is sent. Once this ID is received, that ID is sent to the Amazon Cognito identity pool and you get a temporary AWS credentials. If the token is valid, these credentials, using these credentials, we can then try to access various AWS services via brute force method. So often times, and this is a very valid scenario in this case, in today's scenario. And we have found genuine issues using this use case. So if you see there's this, it's obviously it's not, the entire thing is not mentioned here. But if you refer this link, which is there on this page, there is a detailed description of how you can exploit this and how you can test this scenario. So this, using this enumerate im.py script, whatever temporary credentials have been obtained, you can pass it in access key and secret key respectively. And then it will enumerate just like this, what you see on the screen, it will enumerate every service that is accessible. So this list in itself is enough to prove that you can access services, which are not supposed to be, and this could be reported. Another very interesting issue that we often come across is for some reason, developers miss implementing rate limiting, or even if they have implemented, there are some misses because of which rate limiting doesn't work as it is expected. Like in this example, you can see that this screenshot is from a real project that we did recently. And the way rate limiting was API rate limiting was implemented here. You can see that it was Burp included was run. And you can see the serial number from one to 15, only 15 attempts have been made, but it started with 56 and again, 54, 55, it's never reducing basically. In fact, 15 minus 58, even higher than what it was initially. So this X rate limiting remaining was getting reset for some reason. So definitely this was an implementation issue. What was the real logic? I don't know, but definitely this is not secure. If rate limit is reached, requests are supposed to be blocked. Request should get blocked, but it was definitely not getting blocked. I was able to, it was getting blocked. It's very strange. So when I was using repeater and I was manually trying to trigger the request, even then this was increasing. So in reality, if you see, given this scenario, we can assume that there was no rate limiting implementation at all. It's as good as not having rate limiting here. Now, as for the documentation, you will see that there are three headers which are expected. And in this example, if you see there are only two headers, rate limit, rate limit and remaining, but there is no rate limit reset. So obviously the system doesn't know under what circumstances to reset and something wrong was happening. So if we are trying to experiment with some new features, we should definitely read the documentation, understand how it is supposed to work and especially when it's a security feature that we are trying to implement. And then we should definitely test it out. There were two real world examples around this rate limiting because there was no proper rate limiting. So it's not like rate limiting was not there in these two cases, which is Facebook hack and Instagram hack happened. It's not like rate limiting was not there. Rate limiting was there, but it was not sufficient. In the first case, if you see this N parameter, OTP was supposed to be passed here in the forward password new feature. And when the OTP is received, user was supposed to enter valid OTP here, but because of missing rate limiting, a user was able to brute force this password, whatever password was generated, it was valid for at least 10 minutes. And that 10 minutes was enough to break this fixed digit code, numeric code. And that's how this hack happened. It was reported on time. So there wasn't much damage. In Instagram, Gram hack also, it was a similar case. In this also, again, as you see it reads, Instagram had rate limiting, but it was not effective enough. And in this case also, there was a fixed digit security code. And yeah, it was easily brute forced. Really allowed a couple of things here. Sure. Folks, if you've come across this Facebook bug before, the basic idea that was exploited by the bug bounty person was that the www.facebook.com domain had rate limiting, right? The same URL, the same post request if you would make to www.facebook.com, right? There was rate limiting enabled there, right? But for beta.facebook.com and there was another domain, there was no rate limiting in it, right? This essentially shows the disconnect between even when an API is deployed, right? There might be security features that are administrative in nature. You would have something in front of the API as a middleware that takes care of stuff like rate limiting. In such cases, that rate limiting middleware was not available or applicable to beta.facebook.com, right? And for the next, for the Instagram as well, six digit security code appears to be safe. Because it has one million possible combinations and in real time you can't be brute posting this. But because the end point, the mobile end point for Instagram did not have rate limiting enabled, right? The web one had, essentially it ended up having, the attacker was able to set up multiple machines, right? And crack the six digit security code in under $150. So basically from the impact point of view and the investment point of view, the ROI was really, really high. And imagine the attacker could have gained access to anybody's Instagram account, right? That's because the place where the configuration was supposed to be implemented and where the security control was were two different regions. You want to? Yeah, thanks Reyes for adding it. So the next issue, which is very common, which again, I think gradually it was common, very common few, sometime back, but gradually this is reducing probably because people are becoming more aware and people maybe security aware they are getting, but we still do find these issues. This one is oftentimes, believe sensitive files in App Bundle. So the APK that we receive, what is APK? APK is nothing but it has all the files, it has assets, it has source code and any supporting file that is required for the APK app to work. So it's all bundled and it's very easy to unzip the APK or IP and see what is there in the bundle. And because APK is supposed to be distributed freely because only it could be distributed in various forms, but ultimately it is either an APK for Android or IPA for iOS. Once any person is out, you don't have control on who's receiving it. Anybody who receives it can simply unzip the bundle and see what is inside it. In this case you're seeing that there is an APK which has been unzipped and there is an XML file Android manifest and there are certain files and folders inside it. Now, whenever you unzip an Android APK, definitely look into what is there in the REST folder, REST folder. It will sometimes, a lot of information, a lot of interesting files could be found here. For example, this one. So this example has been taken from the vulnerable app which I built which is named as VIP. I did not introduce this deliberately but I was testing because I incorporated Amazon Cognito login feature in that. And I realized that in the APK when I unzipped it, I saw that it has placed the AWS configuration file in REST raw folder. And this is a very sensitive file. If you remember sometime back I spoke to you about the authorization issue in Amazon Cognito and there is a pool ID. So many of you might have questioned how will someone receive this pool ID? So this is one example that if a file has been not safeguarded properly and it has sensitive information and somebody gets hold of it, I can easily pick this pool ID and fetch temporary AWS credentials. And then I can see what all services I can get access using this pool ID. This is one way you can receive ID from different ways but in this case, the important part to notice that there could be and also if you see this file, this, if it was a proprietary music, nobody was supposed as people were supposed to buy it and they were not supposed to just access it. I guess just by unzipping this APK, I have access to this, right? Similarly, you should definitely explore, unzip the APK IP and see what are files are lying there. So you should never ship sensitive files in APK bundles. Next one, similar to the issue that we just saw, but it is slightly different. It's not a full-fledged file, but sometimes we hard-code secrets in the source code thinking that nobody will have access to it. How will someone see the source code? But it's very easy, especially in case of Android. And definitely it should never be in plain text. If you are having secrets, it should definitely never be in plain text. And sometimes we have found, and even in real-world testing or security testing, while doing real-world security testing, we had found a hard-coded secret and the funny part was secret was named as secret. So for some time I got confused that is it actually the secret or is it just a variable name? It took me some time to understand, no, it's actually the secret, which is lying there in plain text. So we did report that. So be careful, never put plain text secrets in your source code. Also, this all example, whatever we are talking right now, it's all related to data at rest now. Whenever your app is dealing with sensitive information, sometimes we have seen that, for example, in the left side, you are saying this is what that chat feature and people are talking, and then data is getting probably stored in a SQLite database and it is getting stored in plain text. So if your app deals with sensitive information, a lot of times SQLite database is used to store that data. If you need to be very careful when dealing with sensitive information, if it is sensitive, just do not store it in a database at all, try avoiding and if at all you cannot, then definitely it should be encrypted. We have also seen issues in cache files and this is a very common issue wherein caches are not cleared. Sometimes it is like caches needed for some feature to work, but definitely when the user logs out, we have also seen even after a user is logged out, there are files lying around in the device, the cache files, which still has sensitive information and obviously again in plain text because if they are encrypted, obviously it's of no use unless I can also break encryption. But we have seen data is there in the files in plain text, in cache files, cache is not getting cleared and caches can be in two forms. As you see here, they could be just random temporary files or they could be also in SQLite databases. It could be in both places and once few times we have observed that files get cleared but database was not getting cleared or vice versa. So we have to be careful when we are dealing with caches and ensure that caches are cleared. We have also seen that many times environment checks and this is, I think it is missed in most of the places where environment checks are missed. What is the motive of an attacker? Main motive of any attacker. They want to reverse engineer your app so that they can understand the app logic and find bypasses, business logic bypasses or to see if there are hard-coded secrets or anything. So they try to reverse engineer your app but reverse engineering is possible only when you have not put any protection in place and anybody can just use the right tools and obtain the source code. Intercept communication between server and app. This is also main motive. So if your app is doing some sensitive transactions if it is a banking app or it is a hospital app or something dealing with very sensitive information, the communication which happens with the server is very interesting and very crucial for app users and also for interesting for the attackers. So attackers do try to intercept these communication. So as Riaz had also mentioned in the beginning that you do not have control on the environment where this app will be running. So if you have not taken basic checks of where your app is going to run, then it might be very easy to break your app and steal information using your app. As Riaz said, it's not possible to make it totally secure, completely secure but still defense in layer is something that we want to look forward to. And few things that go missing is that apps don't check for if the app is being installed on a router device or jailbook and device, apps do not check if this app is being installed on an emulator or because once I'm able to install the app on a router device or jailbook and device or an emulator, then it's very easy to gain access to the system files. If my, I have not taken care of obfuscating the code, it becomes very easy to read the code, right? So I can read whatever is there. And obfuscation obviously makes it difficult to understand the code, even if I have, what do you say, obtain the source code. Encryption, we have seen encryption what could go on when encryption is in place, things that are very common and that go wrong are that your encryption keys are very sensitive. So where are you storing your encryption keys? Are you hard coding it? Or is it very simple? Can somebody guess it? Can somebody brute force it? Or the second thing is, are you using weak encryption algorithms which are already flawed? So using a strong encryption algorithm is recommended. And it's very important to pay attention to the key management. Certificate pinning, again, we have been able to bypass certificate SSL pinning by the passes had been very easy using the right tools. So it has to be, oftentimes it's not tested that thoroughly and it's very trivial to bypass SSL pinning checks. So these are some of the things, tamper prevention, I will let Riaz talk more about these, what developers should do. And yeah, but the thing to take care of here is oftentimes developers do miss out keeping in mind that where their app is going to run and because of which it makes it easier for attackers to get hold of your app, break it, steal information that the API communication and do damage to your app. So over to you, Riaz, I will let you add more to it. Thanks, Riddhi. All right, do you see the success kid? So essentially a couple of things to add on to what Riddhi's covered. She's kind of touched upon a lot of things that we see developers do and the kind of ways they can, if you obviously, if you know what the problem is, you can obviously encounter what different possible solutions can exist for the problem. So let's take a look at what are some of the things that developers should be doing. And then we've seen this in a lot of cases where applications that we've tested, couple of applications in our history where the application is extremely well built, very securely well built and we've had issues only with the backend APLs, right? Or vice versa, right? Either one of the components has been vulnerable. Couple of things, as in I have a bunch of them to cover, but essentially things to do to improve security, perform unit test cases, especially for complex apps. And when I say unit tests, I'm good for especially complex applications which require data input coming from multiple functions. You need to ensure that the business logic part is getting tested actively. So unit test cases would allow you to ensure some level of business logic testing is achieved, especially things around your authorization would become more clearer, right? If your code is written in a modular way, you can identify any loophole, security issues, and patch what is required instead of rebuilding the entire class, right? bug fixes, feature updates, and all of the other things are going to be done smoothly if you have code written modularly. To add on to what really mentioned earlier about third-party sources, we can't live without them, right? All mobile apps essentially at some point in time will have at least the analytics component from a third-party source. We need to be aware of the security implications of adding third-party sources, right? And this is not necessarily a library or an external binary. Even code copied from Stack Overflow, for example, or taken from another GitHub or open source project would essentially need to be scrutinized for security issues, right? Verify the source and be aware of the security state, and if any known issues have been published for that particular binary library before, because your circle of trust is your dog, and you obviously don't trust anybody else, right? From the environment point of view, and just to extend to what you were saying, as I said right at the beginning of the presentation, the application resides and runs in a very untrusted environment. You don't know who's going to run the app in a router phone. You don't know if the app is going to be run on a device that is going to be shared by multiple people. You don't know if the device is going to be run with applications that have been installed, unsafe applications that have been installed, right? With the lockdown, I'm sure all of you exist on at least one WhatsApp group where you have uncles and aunties sharing images and stuff. I'm on one of them where I, every two weeks or so, I get an APK file by one of my cousins, from one of my cousins, and with the insistence that I install it on my phone, and just because funny cat videos, and there's no dirt of that on the internet. But try and have an environment detection routine built into your mobile apps, just simply so that you can make it difficult for noise hackers to perform runtime analysis. If the app is able to detect that it runs in a, you know, a router jailbroken emulator simulated environment, it makes it difficult for, and there are obviously, there are ways to bypass it because you physically have the code with you, and the mobile app is running in a controlled environment in any case, right? You could still pass the code, but it kind of weeds out the people who would run after low-hanging fruits, right? Tools available with auto box, scripts to bypass standard checks are available on the internet. And essentially, unless you don't add a layer of obfuscation to the function, you know, using a combination of something like freedom and objection, you'll be able to bypass most jailbreak detection or root detection capabilities, which improve your detection rate by ensuring you have a larger list of things to detect. One of the common things that people, developers add into their code, if they want to do jailbreak detection is to detect the CDR.app is present or not, right? But with Checkrain, and the CDR, the package manager, it's not necessary to have these things available on the system. You could still have shell access, root shell access to a device, and you could be running in a jailbroken environment. And so your checks need to be more exhausted. Similarly, the default example for implementing, and we've seen this time and again for, okay, HTTP, the library, if you're using the certificate pinner as out of the box, right? The code to bypass the HTTP script certificate pinner is available, and it's just one simple command to be able to bypass certificate pinning for an app, right? So obviously that has to be twisted so that it can withstand the bypass itself. Ensure your local caches, files, and SQL storages are cleared upon user logout. More people share devices than you know, right? When, I mean, it's as equivalent to what you would do for your web apps. If a user logs out of the web application, right? And the server has ensured that the logout is successful. Any locally stored data, like your cookies, your local storage, your session storage, all of that needs to be cleared up, right? Similarly, when you have a mobile app and if your API driven with the logout and the authentication piece, any data that was created and belonging to that user, for that user session needs to be cleared up. And we've had cases where we've tested with mobile applications where we've seen data that belong to previous users on the mobile app reside in the sandbox. And although the sandbox of the app requires root access, it may entirely be possible to invoke if you have like an insecure activity to be able to read the SQL database from another app, right? That's definitely possible. Authentication, authorization checks, there's just no saying how important this is and then it's not enough, the number of times we reiterate this. Build authentication discussions into your app design, right? Questions like, and these are very tricky questions that attackers try to emulate all the time. Try and see if there are any race conditions that would occur or what would, how would the application behave if two users are logged into the mobile app at the same time, right? Or what would happen if the user logs into the mobile app from a different device, right? Treat all user input with caution because the context of the data is really important. At the login prompt, when you're providing username and your password for the mobile app, that is your credential for the application. But when it reaches the server, depending on how you're going to treat the data, it can end up being something else because the context is changed, right? With document databases like Mongo, if you have, you know, JSON queries going up, the JSON query itself in the data, you can add if the application on the, if the API on the server is going to parse the JSON input as is, you can pass your own document queries for so that the server can process, right? Because the context of the data changes. Offloading authentication to third party providers is great, like how we do with sign on with Google or Facebook or Twitter or Apple for that matter, right? But it can have its own set of troubles, which as recently as a couple of weeks ago, we saw with the Apple bug, right? Ensure the authentication documentation by the provider is followed and unnecessary storage and transmission of tokens and keys is avoided, right? This essentially also points to the fact that if you have a token that is set, you know, posted authentication with a third party provider, you need to ensure that this token doesn't get leaked to a different provider. Like for example, if you have an analytics component also in your mobile app, and if you're going to make a request to an analytics endpoint, the token may end up, you know, reaching the analytics endpoint through reference, right? If that is the case. So the token itself could be leaked to a very different third party provider in your mobile app because the way compactness and efficiency can come in. Authorization can definitely be tricky, especially for multi-user, multi-roll apps, right? Especially in apps where you are able to choose the attributes for a role, right? Avoid passing direct references to objects on the servers to clients. And when I say direct references, I'm talking about cases where you have an ID equal to five or ID equal to six, where the five and six is actually a database reference on the server, right? That's actually a data store reference on the server. Manipulating this, it becomes trivial then if you haven't implemented your authorization property, which is where the insecure direct object reference issues come up, right? We've seen some of our clients use UUIDs, which UUID identifies, which kind of makes it difficult for attackers from guess, doing guesswork and identifying who or what the ID for a different piece of data would be, right? But even then, using the UUID, if you're able to make an authorized request to a different endpoint, and that causes state change on the server for the UUID data trying, it is still broken authorization. Just generally that the attacker will not be able to guess it. The authorization is still broken though, right? I would recommend you start with the authorization matrix that shows exactly what feature a user has access to, right? And figure that out in code if that authorization matrix holds true, right? The default deny principle should be what is the default for all users, right? Follow the least privilege principle. We have an image of what it will look like on a network and a system, right? But essentially ensuring that all users are, you know, connected to the backend API with the default deny privilege, unless you prove who you are, right? That kind of builds the whole security in your flow. And this goes for, I mean, I've been parroting this for my entire career. Treat all user input as evil, especially for APIs if you're in the context of mobile apps. User data can only originate in many places and it's not only restricted to form submissions that the user may do, but could include anything that comes from the client that includes the request status, the file uploads, user agents, even the metadata of a file upload. Like for example, if you're uploading a PDF, right? The metadata of the PDF could contain malicious data because at the backend, when your API is processing the PDF file, the metadata might get consumed in a context that you're not even aware of, right? And content coming from non-human sources like databases and caches, which have already been created on the server from a different perspective. Like for example, if you have registered an account and that information is resides with, already resides in a database, and if that data is going to be pulled back from the database and use somewhere else, you could end up with having second order security issues, like second order SQL injection or second order XSS, right? When an error is encountered, you need to fail safely. That would be a problem. This is commonly done by a lot of developers, but the amount of information that is presented in the response is pretty high, right? You need to handle your error conditions without providing too many internal details and restrict the information that response is sent. For example, if you have something simple like your get profile, and that response sends back information of which only five items are displayed in the mobile app, but the response comes out to about 100 fields, right? That information may incidentally lead to disclosure of sensitive information that you do not want the user to be seeing in the first place. Because remember, if a mobile app can make a request to a backend API, a user can definitely make a request using a different tool like Curl or Postman, for example, right? Don't send excessive information in your responses. We're almost, we were about eight minutes to eight. We have some bonus content on how you could set up a typical mobile hacker lab, and it's not very exhaustive, but things to get you started, right? You need to have, definitely, if you're going to be testing mobile apps, you need to have routed or jailbroken devices with you, right, a router Android device and a jailbroken iOS device to start with. Android Studio definitely for to run emulators, to decompile APKs, to look at code in general, and if you want to build your POCs, that's very useful as attackers go, right? And next code, similarly, if you want to look at the device logs, if you want to create entitlements or run a simulator. Mob SF, I would highly recommend this to be like one of your first tools that you would run on an APK or an IPA if you've received, right? Kind of skims through the entire app, gives you visibility into water, water, services, activities, do any files contain any encryption related things, any weak hashing algorithms, if there are any hard-core secrets that were detected, right? Gives you an analysis, and although, because it's an automated tool, there may be a false positive that's true with any tool out there, but this gives you like an entire picture of what the APK or the IPA contains, right? And you can make an informed decision if, whether something is sensitive, something is a vulnerability or not. But, zap your or insert in your other favorite interception proxy to test and attack APIs, right? Hopper, Ghidra in terms of disassembly and function tracing, we find this really useful when we're looking at iOS mobile apps, right? We receive applications from our customers through test flight or, you know, Firebase distribution system or something. And once we have it installed on the device, we extract the unencrypted IPA out of the device and then we perform static disassembly using Ghidra or Hopper, right? JADX, an all-time favorite to decompile APK to Java classes as well as the internet itself, I suppose. Freedime objection, both, for both platforms, essentially to patch binaries at runtime to evade the jail breaks or root detection, evade sort pinning and you would have to, I mean, the true power of Freedime only is when you start writing your own scripts. But the objection to an extent has a lot of scripts written and then you can automate a lot of those things, you know, unless the code is written in a way that has incorporated the things that we spoke about including obfuscation and shrinking. 3U tool is a standard tool that we use to transfer files and, you know, browse the iOS file system, install push IPS to the device if you have an older version, right? And also it can be used to extract installed files out of the system. Couple of resources in terms of what you could read and learn about approaching mobile security testing itself, some getting started links. Highly recommend the mobile security testing guide, it's extremely expansive, contains information around how you would reverse engineer, how you decompile disassemble, how you patch you, how you would bypass any checks that are present, what to do when you're testing for APIs, all of that information, nicely compacted with a beautiful contents page. Please do take a look at the mobile security testing guide. The canidjailbreak.com right now is flagged by Chrome as malicious, but it's technically not, it essentially tells you if your version provided the version of iOS that you have, it tells you if an exploit or a method is available to jailbreak it, essentially gained root access to the iOS device, right? You can simply search through different exploit related things, even payloads as such, right? XDA developers, the Android forums and a very old collection of, I mean, it's really very active even now, but it's been on the internet for quite some time about anything to do with Android hacking, right? You'd have tools that would ease your life in terms of testing, even development, development of apps, for example. I mean, we browse this from an attack of perspective, trying to see if there's any quicker way or two fetch data out of NAPK. High-altitude hacks is from a null member itself, Pratik Gyanchandani, an extensive collection of iOS app hacking tutorials. And highly recommend that to anybody who wants to get started with iOS hacking, right? The Upta's API security book is really useful in case you want to understand how to build secure APIs, right? A link to VIP is also presented here. The tool author is my co-speaker, Riddhi, right? She, the Android, a vulnerable Android app will give you an idea of what kind of security issues exist, right? And especially with a cloud infrared, the backend. Mob as a documentation and the release candidate for the API security top 10. It's not very complete, but essentially gives you an idea of what kind of things to look at if you're going to be testing apps with an API backend. We've kind of come to the end of the content that we had. We'll take any questions if you have now, right? Our contact information is on the screen. This was like an introduction to mobile apps and testing and security and stuff, right? But if you need any consultation from a mobile apps perspective, security consultation around mobile apps, APIs, right? Or anything on those, on mobile environments, right? We are going to be having the office hours consultation on second of July, right? At 4 p.m., 4 to 5.55 p.m. And the link to register for that session is there in the slide here, right? So I would highly recommend if you have any questions around, you know, if you want to get some consultation from the other, I'll be joined by my other colleagues at Apsaco as well, right? Akash and Abhishek will be joining that day. So if you have any questions around design or strategy or essentially if you're trying to understand how you can build your security at the design or the drawing phase itself, right? We'd be happy to answer questions during the office hours on second of July. All right, Shruti. Hey, thank you, Riyaz. Thank you so much. Thank you so much for that detailed, informative talk and about telling what are the things you need to be not doing when you're developing a mobile app. Thank you so much. Thank you so much, Riddhi. So I think we can get started with the questions since you already mentioned about the next week's session, we can move on to our questions. So there is a question which Shivam is asking, even if encrypted data is stored, will the attacker have access to the data? If the encrypted data is stored where? On the mobile device? I'm assuming that's the mobile device that's there. I think he is referring to the point where we were talking about storing data in the app and the files, right? So I'll just add Riyaz and then you can add on top of it. I'll just say and to answer it. So Shivam, you can correct us if our understanding is not right, but what I understand, you're trying to understand if when we are saving data in the app, in SQLite database, probably, and if or in the files, you are saying if you are encrypting and storing, is it good enough or not? Yes, that is what is recommended. Whenever you are storing data on your device, it should be encrypted. And the next step becomes then how strong is your encryption? So we also spoke about if you are using encryption, make sure you are protecting your encryption keys and also you are using stronger encryption algorithms. You should check you're not using any broken encryption algorithm. Riyaz, do you want to add something? Yeah, coming to the point of encryption is not to be treated as a silver bullet solution in the tech world, right? Just because the data is accessible and sensitive, go ahead and encrypt it, right? That's what we always hear about. Encrypting with ensuring the security, the state of security for the kind of algorithm that was used where you need to ask yourself the question, where are you storing the key that would decrypt the data? Because if the application is going to encrypt it, it requires the decrypted data at some point in time for processing function, whatever, right? If the application is going to decrypt the data at runtime, the key exists in memory on the device, right? So you would have to make a trade-off between ensuring that the key is available to the application at runtime. The interesting piece that you can have there is that you have different keys for different users. So based on the installation itself, you could generate a key that is unique to that device, right? And then you encrypt the data. You'd definitely still be able to gain access to the encrypted data because it's like anything else, it's going to still be data, it's going to be in the file, right? But you would not be able to read it, right? So you could still go browse to the SQLite store and extract the SQLite file. You would have gibberish, it would be garbage. You would be able to read it, right? But the app definitely knows how to read it, which means the key resides in the system itself. So, but then if the key is unique per installation, the app or per user, in fact, the data that you have will not be able to, or rather if you have somebody else's data, you'll not be able to gain access to that data using your keys, right? Unless you obviously gain access to the keys of that user, have you got another question? So I think Riya, someone is asking on the same line where do I keep the encryption key? If at all I had to encrypt the data at rest? Well, the configuration file is where we've seen a lot of times the key resides, right? Or you could fetch the key from the server based on components that are unique to that installation, right? But again, from the point of having unique keys is what is needed to be stressed out, right? If Ridi's key is the same as my key, then she can look at my encrypted data, use the same key that I have, and don't bundle your keys inside the application, don't hard port them. I'm not talking about the static key for the whole world. I'm talking about unique keys per user. Also, I would like to add that when we are trying to save data, we really need to ask if it is really important to store that data on the device or not. As much, if possible, do not store data on your device, fetch it from server whenever required, right Riyaz? Yeah, so you need to quantify what kind of data it is, right? And if you're like storing nuclear codes, obviously you don't store it on your mobile phone. If you're going to save the picture of your dog or a cat in your mobile phone, it doesn't matter if it's encrypted or not. So quantify the kind of data that you're going to be storing, right? And if it does need encryption, store it on the server for the maximum security. Again, remember that it's an untrusted execution environment, so anything that's on the device can be gained access to, which is why different users have different keys. You are using the untrusted environment to have secure code. All right, thank you, Riyaz and Riddhi. Shivam and Adhu, I hope that was helpful. Next we have is the question from Love. So he's asking, as a UX designer, are there any best practices or general guidelines that we can follow regarding designing around inputs and errors that would be helpful for the development teams to ensure security? If I was too fast, I can repeat that again. No, I got the question. So I'll take a stab at this, right? And as I said, we're not the developers, let alone UI UX developers. But essentially what we've seen is the amount of information that you pass to an attacker, right? If you constrain that amount of information that itself becomes a challenge for security folks to try and figure out a loophole. I'll give an example. If you have your UI, if it says on a username and password field or on a login page, if you enter a username and a password combination, and if the application tells you that the password is incorrect, right? You're pointing to the attacker, the attacker inferences that the username was right. Right, and simply using the most common password set an attempt can be made to figure out the credentials for this valid user, right? Similarly, at least in one case where we've tested an application based on the response, the number, the content length of the response, we were able to identify if there was a valid user on the system or not. Simply because a lot of times if the username and password combination is sent to the server, a lot of developers tend to check if the username is present in the database first. If the username is present, only then do a password check, right? So in both the cases, if they're returning the same message saying invalid username or password, in one particular case, we had invalid username password and invalid username password full stop, right? That one byte difference allowed us to interpret that the username check was a separate function and we were able to enumerate like a bunch of usernames, right? So from a UI perspective, keep the information as vague but helpful as possible. So if you're trying to give away information about login or something like that, right? Minimize the amount of information that an attacker can use. Okay. All right. Thank you so much for the detailed explanation, love. I hope that answers your question. Next we have a question from Satjajit who's also who's asking, do we need a Mac to set up a mobile pen test lab, especially for iOS pen test? It would really be useful if you have a Mac, simply because Xcode is not available anywhere else. And as you progress into testing iOS device in more and iOS application, more and more, you would want to have a version of Xcode, especially because there are times when you want to create your own fake app, create an entitlement and then use the entitlement and to pack something else. The, to get started, definitely no. You don't need a Mac. All you need is an iOS device jailbroken ideally because Windows itself has a lot of tools. People have written a lot of tools on Windows to work with iOS devices. And there are a lot of tools available in Linux as well for you to get started with iOS app testing. Mac, at some point in time, yes, if you want to do more advanced related, one thing that we find really useful is if you want to check if the app is leaking any information in logs, right? Like how you have ADB logs in ADB log in Android, you'd want to look at the logs being generated by the iOS device, right? And we've seen that Xcodes devices and logs option is a very useful place to, the only place we know that we can see device logs. At some point in time, yes. All right, thank you so much. Satyajit, I hope that helped. I guess that's all we had. Folks, if you all have any more questions, please feel free to post. So if no more questions, then I think we can wrap up the session. We'll wait for a couple of more minutes, no? Yeah. All right. If no more questions, then I think we can wrap up the session. Oh, okay. All right, thank you so much, folks, for attending the session. Thank you so much for your time. I hope this session did help you all. Thank you.


Good morning you two. Did you get it? I got it. Good. Let's see it. You just do it. Let's just do it. Boom. I think it's the exact same one. That's what I wanted. And I got Papa something though. Whoa. Oh nice. Guys it's heavy. Here we go. Good job mama. Getting them a pool. Remember at the birthday party about a month ago? Almost exactly a month ago. Today July 9th or 10th. Anyway, Devin shout out to Devin if you're watching. The idea we just used it again for blowing up the pool using the hairdryer. Be careful. Don't rush moves. Good job. No kids were there. Alright. Almost got one wall done. Almost. Let's go show it to you. It's looking good. Does it? The lease is not leaking into our house. It's just leaking onto our roof. Shouldn't be doing that though. I'll fix it. I'll fix it. Painting is done for the day most likely. Got pretty far. Got pretty far. But it is Sunday. Our day of rest. Just relaxing. And Sarah and Troy are coming over with Lucy Flynn. Lucy, Finn and Claire. Happy birthday Sarah. They're coming over. We're going to grill some steak. Have some cake. You know. Good times. Good times on the patio. The pool. And just enjoying this summer heat. Man. Excited. Excited. Alright. Ah three. Here it is. Cheers. Hello. You're like whenever you're on the vlog. You're giving me a beer. You hear that livestock screaming? Let me out. Let me out. Troy this. This is the real deal. Okay. I'm glad I got this pretty hot. Well you know you only turned 30 something once. Right? That's a nice form. We got a lot of steak over here. Here we go. Hopefully that'll be breakfast tomorrow too. Right? What are you eating? Are you eating a motorcycle? Seth. Seth. You're supposed to go inside the car. The grill master is very pleased. Very pleased ladies and gentlemen. Woo. Not too shabby. Not too shabby. Uncle Troy causing trouble. Put your feet up Joseph. Oh that's fun. Hi Claire. List. Yeah. Okay. Watch the knife. Here we go. Oh thank you. I'm just pulling you guys in. One more time. You made a good one Troy. Does the birthday girl want to close out the vlog? Oh boy. Pressure. No. Seek beauty. Seek beauty. Love each other. Work hard. Work hard and then. See you tomorrow. See you tomorrow. Good job. Happy birthday. Chow chow. I don't know. He's always funny.


Hi, good morning, everybody. So as you said, I'm Jessica Forester. I work on the OpenShift team, been with OpenShift for a while now. And as part of OpenShift 4, we've been looking at what it means to have operators. So really quickly, when I'm talking about operators, what am I actually talking about? And really, all this is a way to package together, then deploy and manage your application on Kubernetes. Whether your application is something as complicated as the CUBE API server itself, or your own application that you want to give to other people to deploy on Kubernetes and make it easier for them to maintain over time. Operators are just a CUBE native way to do that. And so specifically when I say Kubernetes application, I'm talking about something that, as I said, deploys on Kubernetes, but something that is managed through the Kubernetes API, through CUBE control, through OC, if you're using OpenShift. And so the configuration contract for that application becomes an API and is more maintainable moving forward. So the OpenShift platform, particularly in 4.0, is almost entirely Kubernetes applications as I defined them before. So from the almost very bottom of the Kubernetes OpenShift API servers to the controller managers, the scheduler, the SDN, the registry, the web console, the Prometheus, the list goes on. And as you mentioned in the intro, over 40 of them, I think we may be up to 50 of them at this point, the list keeps growing because as we break the platform apart and make it self-managing, each of these applications needs its own things. And so, that many applications, we wrote a lot of operators. I don't want to get too far into what we actually did there because some of my colleagues are talking about this in greater detail later. So if you're interested in how we're operating the platform, go listen to them talk about this later. So when you write this many operators, you learn a few things that you realize, okay, maybe we shouldn't have done these things. Some of them, you know, we continue to work through. We keep finding new ones every day. So we may not have all the answers yet, but we at least have learned if you're getting started writing operators for your application, then there may be things that you should avoid. So I'm going to walk through a few of these today. And some of them may not be very technical. Some of these are about software engineering, right? So as an application author, your operator is probably not my operator, right? So it's important for you to remember you know how to operate your software. So when you're looking to get started, there are a lot of examples out there already, we've written over 40 of them. Ours may not be right for you.  So if you look at the Kubernetes API server, it has unique problems, right? It's what's controlling the platform, and if it rolls over too quickly, guess what, everything that was watching the API server suddenly has lost its connection. So it has unique things in its operator that are managing how it rolls itself out and responds to change. Our stateful applications like Prometheus and SDD, they have their own unique challenges, right? They have to worry about how they deal with disaster recovery. And then something as simple as our web console, right? It doesn't require a lot. It just has to be able to roll itself out. It has to, you know, use existing Kubernetes concepts to do that, so it doesn't require much over time. Its operator can be very simple and have very little configuration. So I told you don't start with someone else's, so how do you get started by not overthinking it? Don't think about it so much that you don't know where to start, right? And we saw this over and over on the teams that they're like, but I have to do this. I have to do this, and I have to do this. My operator has to do all these things. This is what an administrator has to do to run my software. And what was happening was people were just struggling to get starting. Just start, just start writing it. Start small, right? MVP, we write software all the time. What do we do? We build MVPs. Our operator should have an MVP. Install your application on Kubernetes, step one, right? Come up with what your manifest should be to run your app on Kubernetes. Put that into code. Have that deploy out. Step two, figure out how am I going to roll out a configuration change of my application? Not even an update. Just the administrator wants to change something, tweak something about my app. What do I need to do to listen to change? Macha, if you were here before, talked about controllers.  And it's the same rules, right? You should be watching for changes coming in and then addressing that change. And then, you know, once you get to that point, you can handle config change, you can handle upgrades. Then start thinking about what is the day-to-maintenance of my application, right? Backups, pruning, rotation, your application, you know what the rules are, what does it need to do? And try and operationalize what a human would normally have done and put it into code, make it easier for them. So the next problem we ran into was too much configuration. We're trying to make it easier, right? Easier to run applications, that's the operator pattern. So you need to actually hide some of the complexity of Kubernetes from the user, make it easier to run. And if you know Kubernetes, the simplest example that I could think of was the pod template. And last night, I was like, I wonder how many fields were up to the Kubernetes pod template, and I counted them, okay? 30 top-level fields on the Kubernetes pod template. If you dig down into containers, each container is specified, another 20 fields, some of which have some. So when you're talking about what do I need to actually let someone configure for my application, you know how to run it on Kubernetes. They don't need to know how to run it on Kubernetes. And that's what the pod template is, it's how to run it on Kubernetes. So really what you need to care about is what is unique, what is special about your application, and then bring that up into an API that you can define with a CRD. So the next one I wanna talk about is something we've hit with some of our applications as we're migrating over from our historical cluster topology to the new one out of the box where we only really have two kinds of nodes. So we only have master nodes and worker nodes.  And so we run into teams making assumptions that kinds of nodes existed that didn't, or kinds of storage existed that didn't. And so if you wanna make it really easy for your application to be adopted on Kubernetes out of the box on the platform, you should try to avoid making assumptions about what's there, if you can. And so when you can, rely on the cluster's defaults. And I'm gonna say specifically which kinds of defaults I'm talking about. So it needs to be things that the cluster admin is really under control of. So things that can change over time. First example, I wanna talk about node types. So I mentioned this, so out of the box with OpenShift 4, we're only giving you two node times. The master nodes where the platform needs to run. And the worker nodes where we're expecting applications to run. But we're expecting a cluster administrator is going to come in and change all of that. They're gonna want to sear their workloads places. They may have certain applications that they know need special machines. And maybe your application is one of those. Storage, right? Storage is gonna be different from environment to environment. And in four, we're actually doing work to try and make it easier to set up the right default storage out of the box. So if you're running on Amazon, we're setting up EBS volumes provisioning out of the box. But maybe you require specific things. So if you do need something special, let the cluster do the hard part. As an operator, author, you should be saying what the restrictions are. So if that's resource constraints, if you need GPU, huge pages, any other device plugins like Kubernetes now has, if you need special storage access modes, so if you need ReadWrite mini volumes, specify that on the cube resources that you create through your operator. And then if those things are not available, when the operator goes to roll out the application and Kubernetes goes to try and respond to that, you'll be able to roll that information up to the user to say, hey, I can't fulfill this request because the administrator hasn't set up this thing for you yet. And then as a cluster administrator, or for the cluster administrator, you should allow them to configure certain things about your application for the operator. As I mentioned, steering workloads. So a good example of this for us, I want to open shift on the platform, would be our logging stack. So elastic search, it tends to be very large. It takes a lot of memory. It usually requires special machines. Many of our customers like to put it onto its own special dedicated set of machines. So out of the box, we still wanted it to be able to install easily. Not really something we would put on a master machine. It's not core platform. So we wanted to make sure that it would install out of the box no matter what. But it needs to be able to be configured to go to infrastructure machines. Similar with Prometheus. Prometheus, we want to make sure that it can go to other machines that are dedicated just for that. Storage classes. So just because out of the box, there might be a really easy provision and solution and it'll work, you know, it'll be fine. Maybe it doesn't work under the load you need. Maybe you need higher performance rates. Let them just change what storage class. The cluster admin can define all the storage classes. They're providing on their cluster. So when someone's deploying the application, just let them pick a different one. They don't need to know all the information about it. Storage class. So the last one that I want to talk about is a little bit more of a complex topic that we run into in OpenShift because we're doing a lot of coordination between a lot of different operators. And so in our case, we actually have top level config that many operators are working together reading from and then operating on the platform. So as part of this, we have cases, you know, where we want the admins to define config, but then we also need the machine to observe the platform and provide additional information into the underlying operators to then control the controller manager, the API servers, and other pieces. And so what you don't want to have happen is your admin and your machine trying to fight over the same parts of the configuration. And so instead what we decided to do was to break this down and we said anywhere we have this problem, distinctly separate the parts of the configuration. This is clearly for the administrator and this is clearly for the computer so that there's no question who wrote what. We always know where that source of truth is coming from. So I'm going to end there. I wanted to open it up for questions. So I tried to keep this as high level as possible because the controller talks us right before mine. But if you have questions about what we've done, why we did things the way we did, and I'm happy to answer those. So we were already deploying all these applications on Kubernetes. So what changed, there were a few changes as to how we were getting configuration into the deployment level. So what our Kubernetes objects looks like might have changed but when it got down to the levels of the binaries, I don't think much has changed there. Both, yeah. So we ourselves as Red Hat are writing our own operators to operate the platform. We are also working with other people to write operators for their applications to then be easy to run on the platform. And in some cases, these might just be a singleton that's for the whole cluster. So you install something that adds something to the cluster. Some of these kinds of things, you can think of like Federation if you're familiar with Kubernetes. It's not core platform, something that can be added on. But then additionally, there are things that we actually have today like Prometheus for end users. So we don't actually give you access into the cluster level Prometheus as an end user only as a cluster administrator, right? But you as a user might want to do more with the Prometheus yourself. So the same Prometheus operator can be used by anyone for their own and also runs the core cluster Prometheus. And then, yes, at the end, if you just as an application author just for yourself want to have an operator for your application, just to make it easier, you could do that too. At least for the OpenShift stuff, we have the Prometheus stack installed by default and it's been done in such a way that our core stuff is monitored by that. So all of the operators and the applications are reporting up metrics and a set of alerts that then come out through the cluster monitoring stack. It already has some PB level alerting in the existing stack, but we keep adding. Well, thank you everyone.


This presentation provides information about the various product lines available in the STM32L4 Plus series. By choosing one of ST's microcontrollers for your embedded application, you gain from our leading expertise in MCU architecture, technology, multi-source manufacturing, and support. ST's product portfolio contains a comprehensive range of microcontrollers from robust low-cost 8-bit MCU's up to 32-bit ARM-based Cortex-M0 and M0 Plus, Cortex-M3, Cortex-M4, and Cortex-M7 flash microcontrollers with a great choice of peripherals. ST has also extended this range to include an ultra-low-power MCU platform. Extensive support through a combination of flexible and powerful development tools, training courses, consultancy, and web support gives you a plus for a faster time to market. The STM32L4 Plus series shatters processing capability limits in the ultra-low-power world by delivering 150 DMIPS 405 core mark score while executing from internal flash memory and by embedding 640 kilobytes SRAM enabling more advanced consumer, medical, and industrial low-power applications and devices. The STM32 family of 32-bit flash microcontrollers based on the ARM Cortex-M processor is designed to offer new degrees of freedom to MCU users. It offers a 32-bit product range that combines very high-performance, real-time capabilities, digital signal processing, and low-power, low-voltage operation while maintaining full integration and ease of development. The unparalleled and large range of STM32 devices based on an industry-standard core and accompanied by a vast choice of tools and software makes this family of products the ideal choice both for small projects and for entire platform decisions. To simplify the migration and give you all the flexibility you need, the STM32L4 Plus is pin-to-pin compatible with the different STM32 series and opens the door to the full STM32 ecosystem. ST's ultra-low-power MCU platform is based on a proprietary ultra-low leakage technology and optimized design. The wide portfolio offers a large choice of MCU's from the STM8L 8-bit proprietary core up to the STM32L4 ARM Cortex-M4 including the STM32L0 ARM Cortex-M0 Plus and the STM32L1 ARM Cortex-M3. ST's ultra-low-power solution is the right choice for applications operating on a battery or supplied by energy harvesting, which require an extra long life. With the industry's lowest current variation between 25 and 125 degrees Celsius, STM8L STM32L solutions guarantee outstandingly low current consumption at elevated temperatures. The MCU's reach the industry's lowest power consumption of 170 nanoamps in lowest power mode with SRAM retention. Wake-up times have also been taken into consideration and are as low as 3.5 microseconds from stop mode. The STM32L4 Plus series stretches the STM32L4 technology by offering higher performance, 120 MHz 405 core mark executing from internal flash memory, larger embedded memories up to 2 megabytes of flash memory and 640 kilobytes of SRAM and more advanced graphic features with no compromise on the ultra-low power consumption capability. STM32L4 microcontrollers offer dynamic voltage scaling to balance power consumption with processing demand. Low power peripherals, LP UART and LP timers available in stop mode, safety and security features, smart and numerous peripherals, advanced and low power analog peripherals such as op-amps, comparators, 12-bit DACs and 16-bit ADCs, hardware oversampling. The new STM32L4 Plus series also embeds advanced graphic features, enabling state-of-the-art graphic user interfaces. The Chromart accelerator, the ST proprietary 2D hardware graphic accelerator, efficiently handles repetitive graphic operations, releasing the main CPU capabilities for real-time processing or even more advanced graphic operations. The Chromart accelerator is coupled with the large embedded SRAM, the ChromGRC round-display memory optimizer, the high throughput octo-SPI interface and to the advanced TFT and DSI controllers, allowing you to achieve smartphone-like graphic user interfaces in a single chip and ultra-low power solution. The STM32L4 Plus series are available in different lines. STM32L4R5S5, STM32L4R7 or S7 with TFT interface, an STM32L4R9 or S9 with MIPI DSI and with TFT interface. STM32L4S5 and STM32L4R5 devices extend the ultra-low power portfolio and performance with an ARM Cortex-M4 core with DSP and floating point unit or FPU at 120 MHz. The STM32L4R5 portfolio offers from one to two megabytes of flash memory and from 100 to 169 pin packages. STM32L4S5 is available with two megabytes of flash memory and provides an additional encryption accelerator engine, AES or HASH. STM32L4S7 and STM32L4R7 devices offer from two megabytes of flash memory and from 100 to 169 pin packages. This version gets an additional TFT controller and Chrome GRC versus STM32L4R5 and STM32L4S5. STM32L4S7 provides an additional encryption accelerator engine, AES or HASH. The STM32L4R9 portfolio is the superset version of the STM32L4 Plus offering an embedded MIPI DSI and from one to two megabytes of flash memory and from 100 to 169 pin packages. STM32L4S9 with two megabytes of flash memory is the crypto version.


Now that we have discussed the core components of the IP Multimedia sub system, it is appropriate now to look at the additional functional elements which are equally important in IMS. These include BCGF, MGCF and MRF. As you can see in this diagram, the breakout gateway control function sets on the right side of the core, it actually interacts with the serving call session control function and through SCSCF it interacts with other entities. Similarly, the media gateway control function is also important that is not part of the core but performs important functions. And then we have the multimedia resource function MRF that has two jobs, one is the function controller and the other one is functional processor. Let's look at their functionality one by one. Breakout control gateway function actually is responsible for an exception that is it is a node that processes the user requests which come for routing from the serving SCSCF when the serving SCSCF realizes that it cannot provide translation or it cannot find a valid session to be provided through the DNS and enum numbering system. It means the call is being made to a call party which does not have valid DNS registry or enum record. This can be an example where a PSTN telephone is a call party. In such case, the call has to terminate so this breakout control gateway function determines which next hop shall be used for forwarding of this tip message. If the breakout occurs in the same IMS network where the calling party is also present, the breakout control gateway function selects a media gateway control function for interacting with PSTN because it has to activate a node or a functionality that can now talk to PSTN. If the breakout occurs into another network, it means it is now impossible to entertain this particular call within the same IMS. So the SIP request is forwarded through the interrogator SCSCF to another IMS which can handle it. Since there is interaction between multiple IMSs in the later case and even for the same IMS in the former case, appropriate charging and billing records have to be activated. The next important functional element in IMS is the media gateway controller function. We have briefly touched upon its functionality just now but we are going to look at it in a little more detail. It actually allows translation of the signaling from the NGN standard of SIP and any other standard which is not understandable by the NGN architecture functional element. An example can be the integrated services digital network user part that is signaling standard 7 which is used by PSTN. So if the signaling has to be translated from the calling party which is sitting in the IMS to a called party which is there in PSTN to the media gateway controller function now has to translate this from one form to the other. This media gateway controller function is the same for the system architecture evolution as in PGPP, 4G and so forth. There it interfaces the serving gateway through the stream control transport protocol over IP. So it means that media gateway controller function has actually been borrowed by the NGN architecture from the PGPP alliance. Then we have another important functionality performed by servers known as the multimedia resource functions. The multimedia resource functions actually deals with the resources required to handle the multimedia traffic. The multimedia resource functions are split into two parts multimedia resource function controller and function processor. As far as the MRFC is concerned it is a signaling node that understands the information which is coming from the application server and the serving CSCF and it uses it to control the media stream whichever is coming in the session. It actually means in simple words that multimedia resource function controller takes the control information coming in the SIP messages from the application server and applies it on to the traffic which is being sent in the control user plane. Then we have the multimedia resource function processor. It is a user plane node. It means it carries user traffic. It has a functionality that it can mix different media streams. For instance it can be used for multicasting. It can be used for adding audio, video, textual layers for receiving parties each having its own particular format to it which it has subscribed in the service level agreement and the contract. At times this particular node or this server can itself become the source of media stream for instance it can provide announcements for the multimedia traffic to its users and it can also provide media stream processing. Media stream processing actually means an example is flow control which user is going to be allowed admission into the network to attend for instance a conference call. So if there is a conference call between multiple users MRFP is responsible to make sure to make sure which participants can take part in the conference session.


Okay, so when you did fall in love though, mm-hmm Allison is your wife's name Suzanne. I call her Allison now Who I saw at we me and weird Al saw each other at a vegan restaurant called Crossroads now Did you know it was a sidebar? Did you know that Crossroads a vegan restaurant was one of three restaurants in the entire country that served the impossible burger back when it first started I Did I knew I did know that three in the country and then like six months later. It was a like white castle It was a real delicacy I did know that and it was funny to I went there with a woman It was funny to explain to she was British and was funny to explain to her who you were I was like he would do like Eat it. Oh like the Baron Knights and like fat and White and there and whatever I the funniest story is I told her your Kurt Cobain story Mm-hmm, which if you would tell the people quickly once again Yes, or the bad the one I'm thinking talking about is a lot when I got permission for a smells like nirvana I wasn't my manager wasn't getting through to their people and he said it's up to you You know stock Kurt Cobain track him down see if you can get him to orally agree to having to do the parody I love orally. It was a different. Oh man. Yeah better than the other way Yeah, yeah, so I had a friend on the cast Saturday night live and I called up and said if you can get Kurt Cobain on the phone Put him on the phone because I would love to talk to him. You know, this is the first time Nirvana played Saturday night live Yeah, I Heard after the fact that Curt may have been on the Friday. He went and got heroin. Yeah. Yes on the Lower East side I don't know But I called I talked him on the phone and he I said listen I'd like to do a parody of your song smells like Teen spirit and he said oh is it gonna be a song about food and I said no It's gonna be about song about how nobody can understand your lyrics and he said, okay. Yeah, great. That's funny.  Yeah Now if you'll excuse me I have a date with destiny. Hey, did you like that? Did you like that? Yeah? Did you like it though?  This is like when the weatherman says there's a high pressure system coming in I'm not really used to the green screen


Thanks from Defcon and Hack the Box, we are here and we have our amazing booth, an amazing CTF, oh my god, it's Pat, we inform everyone about our certifications, our VAP and we launched also our blue teaming path, thank you all, stop by and cheers!


Well, comparison is a major ego device for maintaining separation, and it's like, separation is just a belief, but it's hidden under a projected hierarchy of illusions, which is what preferences are, which is what favoring some over others or being more drawn to some and less drawn to others and so on and so forth. It's all part of a giant smoke screen that kind of is like a giant cobweb that can keep the spider hidden, like a massive cobweb so that it's so destructive and becomes so addictive and becomes so accepted and so natural that it's not questioned. In fact, that's the whole point of the world is to become so familiarized and so accepted that it's never questioned. Some of you saw the Matrix movie and Agent Smith, who was kind of an agent, an ego character, but he was saying that people accept the world with which they're presented, kind of talking about the human condition, like they're all suckers for whatever seems to be presented. What they perceive is what they believe and that's true. Actually that was one of the truisms that Agent Smith spoke, that you accept the world with which you're presented, when really what we're being taught now is we have to question everything about not only the world with which we're presented, but also the belief system underneath that world that made the world, because that belief system and the world are the same. They're the same cobweb and the ego belief is like hiding underneath it. So it's quite an intricate cobweb and it's a cobweb of comparisons. So first question is kind of like what do we do about these comparisons? Well, it's an addictive form of believing and thinking so addictive that all education in this world is based on comparison. All education. It doesn't matter what discipline you go into, it's all based on comparison. You might say that maybe quantum physics, you know, once it starts to get down below or lower beneath the molecular level, beneath the atomic level, and then underneath we'll say the subatomic level, there's this hint that everything is perfectly connected, everything is energy, everything is joined, and in that, that's kind of like theorized about. The quantum physicists will theorize, but that connectedness has no comparison because it's completely unified, it's unified awareness, it's pure energy, but everything else that we would say is studied in this world. All the disciplines, when you go to school or preschool, junior school, high school, college, graduate school, all of the disciplines, we could say the one thing that they have in common is they all are based on a curriculum of comparison. It's impossible to think of any of these disciplines without comparison. It's just the bedrock. And so once you go deep enough and you start to realize, wow, comparison is just part of the status quo, that's just a given, that's just accepted. Here people say, are we really capable of comparing? You'll never hear that on a commentary show, on a game show, on whatever, because it's already a game show, the news broadcast, the scientific discovery show, the whatever is being presented is already based on comparisons. And so in A Course in Miracles, Jesus says comparison must be an ego device for love makes none. Why can't I feel the love, why can't I feel the love and the connectedness, the connectivity is because comparison is a defense mechanism that was made, that love would never be experienced. It was made as such a deeply complex system, such an all-pervasive system. In fact in the Matrix, you know, Morpheus says the Matrix is all around you. Everything that you perceive he's basically saying to Neo is the Matrix and you could say the same about the world of comparisons. Everything that's part of perception is there and held in place, almost like the glue that holds the cobweb in place is the comparison. So you have to have an experience or even just a glimpse of an experience that transcends comparison. And most of the times when people talk about a very profound spiritual experience or a mystical experience they'll call it, it's a state of no judgment, pure total acceptance. There's just no duality to it, that's why there's no comparison because there's only nothing to compare, all knowing this is called described in many ways. There are symbols for it, I mean on the way here Francis and I took off and we started off in Camus and we came down, they had blizzards going on and up 12, 18 inches of snow just north of Salt Lake City and so on and so forth. So when we came here today we actually came through some passageways where it just got more white and more white and more white to the point that you couldn't tell the difference between the horizon and the mountains or the fields or the highway or anything, it just, you called it Antarctica, are we in Antarctica, it felt like we just drove right into the middle of Antarctica because it just got whiter and whiter and whiter and whiter and all distinctions faded in that whiteness. There was some slight gradations, some little slight like light grays and bright whites and then all of a sudden it just got white, white, thick white, like everything was, the air was white and it was just kind of interesting driving, it was like, it was like moving into abstraction because there was, there were no familiar lines anywhere and having had some revelatory experiences, that's similar to the experience I had where the three-dimensionality of the world collapsed and this light started streaming through then the world just disappeared and there wasn't any vestige of a world left, there was no gradations, it was just all pure light, just everything was light, there was no subject and object in it, it was just pure white light, everything and that we could equate with love, that's what the love is and so in A Course in Miracles again Jesus says, if you attain the faintest glimmering of what love means today, you have advanced in distance without measure and in time beyond the count of years, you might say every moment of every day in your life is all an openness and a readiness and a willingness to have the faintest glimmering of what love means today, you know it's like that's your prayer in your heart, you know instead of like the old movie that famous saying show me the money, it's like show me the love is really a call, a prayer in your heart to have the faintest glimmering of what that really means because love even in this world, the word love is used in many different contexts and everything from romantic love to bumper stickers, I love my Volvo, I love the New York Yankees, I love the bumper stickers, just put the I heart and you know you can throw whatever you want at the end of it but that's all just attachment, there aren't any Yankees in heaven, there aren't any Volvos in heaven, it's just I heart, you know even that merges together, you can stick with either one, the I is the all pervasive I am or the heart is the heart of it all and so you know that's really what we're going for and initially when you start to even open up to that idea of opening to that love, first you can feel all the ego objections in your own mind or maybe even if you would even speak such an idea to friends, family, relatives, colleagues or whatever, oh right like you're going to discover what love is, what are we talking about like unconditional love, agape love, you know this and this, you and how many others have attempted to even find that but actually there has to be a point where you sincerely in your heart say yes that is the meaning of my life while I believe I have a life that's apart from it all, the purpose of that life has to be the remembrance of that love that I am, you know that is the meaning of life, you know even though we know is Monty Python and all the hilarious attempts at looking at the craziness of searching for the meaning of life and in the end we do have to end the search, you know it's not we can't forever be seekers, we have to be a finder at some point, you know the search must end in an actual experience and so that's what you could say you can consciously devote yourself over to and then as we start to look at that and you read things like this course does not aim at teaching the meaning of love for that is far beyond what can be taught, it does aim at removing the obstacles to the awareness of love's presence then you start to see that it's not like you can just affirm your way into heaven it's not so easy it's just like with Popeye I am that I am and that's all that I am it's not just so easy as to say the words there actually has to be a transformation that occurs a complete transformation from what I believed seemingly formerly believed to an experience that transcends all belief and that's what you give your heart over to that's what we're here for when I talked initially about the little snubs you know as you do attempt to sink into meditation as you give yourself this quiet time out here there's not necessarily a lot of distractions out here in form this isn't like an amusement park or whatever it's a snowy cold canyon and yet you do get to watch your mind you know what it's trying to generate what is what gyrations it goes through you do get a better awareness of what's actually going on in consciousness and then you do have a better awareness of what you're going to really deal with and face you and with a trust that you you have strength within you you have the presence and the guidance and the love within you that will carry you into that experience so that's really what it's about that's what we call forgiveness is is letting everything up and it's it's pretty much a you could say it's a it's a daily practice it's a moment by moment practice so you you desire that experience of love and we might say just by desiring that by desiring that you're calling that forth you're calling that into awareness and anything that's unlike that experience of love will come up into awareness for forgiveness so that's how it works.