 And I ask for applause for our speakers Bruns fx and Greg who are gonna well We might see Google and Apple go down today Thank you So sorry for the delay. I'm not used to have co-speakers. So we had synchronization problems If you ever did parallel programming, then you know what I'm talking about So what's the motivation here? If you look at modern client platforms that many of you carry around and I'm not talking about your mobile phones But the bigger ones Then you see fundamentally different like they're not the general computing device anymore that you used to have like a PC Could be used for anything, but now we see things that have different general ideas different architectures different software sources and clouds and rain and everything so We will talk about two different devices One of them is like if you ever get spam Look at look at the ones that come from Apple because like the iPad is the actual only penis enlargement device You can buy on the internet that actually works Which you can you know, you can enlarge it So Alternatively if you're if you're more old-style and you actually want a keyboard you want to open this You can buy something like this. This is a Chromebook from Samsung and it allows you to actually type so What do we not cover in this presentation? We're not covering iPhones iPad to anything jail-breaking or sim unlocking and I promise that was the only penis you saw in the entire presentation So let's get a bit serious We had the question before about the fanboys I had this idea of having the Apple fanboys with turtleneck on one side and then the Google fanboys with bright colors on the other Any time you buy a device or you decide to use a certain device Keep in mind that they're not doing this for fun or Because they want to be nice to you or anything There is very solid reasons behind it In this case, it's 29 billion US dollars reasons Which essentially comes from 32 million devices sold only in last year and that makes 20 billion US dollars just income On top of that 30% of every sale in App Store goes to Apple That's another 6 billion and then 30% of the revenue that your mobile carrier does With your iPad actually goes to Apple which ends up being two dot eight billion dollars Which goes to 28,000 shareholders and that's the entire reason they make the iPad so Accordingly the design goals of a device like an iPad are centered around this idea of revenue So what Apple wants is a consistent fluent user interface that you all jerk off to They want integrity protection of the operating system and upgrades Simply because they want to keep control over them and they want to restrict everything third-party Where you get the software what this software can do what the content is what content you can see And what payment models there are Protecting your data is actually not part of the business model so You get your software from the app store which essentially is your only source for software if it's not any app store It doesn't exist like if Google doesn't find it. It doesn't exist, right? You have an Apple ID. You have a very restrictive and fairly intransparent Sign-up process for development We went through that ourselves and got rejected several times for Don't know You're supposed to pay like a hundred or ninety nine dollars a year If if you're a lawyer or aspiring lawyer, I highly recommend reading the Apple contracts that come with the app store They're extremely entertaining. So essentially Pretty much every right that you would like to have goes to Apple But the entire damage is limited to fifty dollars So whatever they fuck up the maximum damage they have is fifty dollars Which is half of the damage that a credit card Puts on you So the same actually holds true for the for the review process for apps when you submit apps for the app store Essentially, nobody knows what happens. So they could have a bunch of monkeys sitting there and like clicking on iPhones. Nobody fucking knows It actually takes a while and here's the first security issue would add and actually also takes a while for updates So if you are a developer and you fucked up your app and you want to ship a security update It will actually Possibly take about like two weeks Or be rejected for inappropriate content So if you ever Considered why there is no security software for the iPhone for example That is exactly the reason Apple doesn't want you to have the feeling that security software is necessary So on the other hand, why does Google actually make the Chromebook so You have to understand that Google actually makes 96% of their revenue Which ends up being 28 billion dollars a year from advertisement. So That leaves them with about 8 billion dollars profit They're not really paying that much taxes actually Which is to 67% voting power or 91% of the financial power goes to the two founders and the now former CEO so For that to happen for the user to actually supply all the data that they can Burn into profiles and then sell for this large amount of money The user actually has to trust Google that Google will do the right thing And if you ever wondered why Google comes out with like free operating systems for mobile phones This is what Warren Buffett calls a economic mode So you have a car so which is Google's money-making machine for ads and you don't want other companies to get close to the car So so you're providing free products in spaces where other companies actually need to pay and and actually Need to make revenue of the product and so you prevent other people from getting into your market And from this the design goals for the Chromebook Actually are derived and are a lot more a lot different So essentially what Google wants is exclusively running the web browser. You can't actually run anything else It really really doesn't want to have third-party software on the Chromebook For actual security reasons because here the protection of the user data is a design goal Because they want the user data to be safe. So the user is happy to use the Chromebook and sends the data over to Google Also, they want multiple users to be able to share the same device so universities can buy like, you know 500 Chromebooks and then Everyone uses them and they're all they're all safe and also Google understood very very early that winning the hearts of the nerds is most important. So If Google sets up a DNS None of the nerds will say well, they're collecting all this data because all of the nerds go like look at this IP address 8.8.8.8.8. This is so cool And well forgotten are all the privacy concerns and they understood that so Google also has a app store or in this case a web store and it follows the same principles They wanted to be open. You only pay like five dollars for Publishing you can only Publish Chrome extensions everything is HTML JavaScript Chrome extensions for the Chromebook cannot have NPA PI which is the old Netscape plug-in API Binaries because they don't want binaries on a Chromebook and the contractual relationship is actually fairly light compared to Apple's But then compared to Apple's everything is light So Let's go into details. I'm Greg here. We'll walk you through the iPad All right. Good evening everyone So for the iPad details First of all, we were going to have a quick look Over how Apple actually Implemented the iPad to achieve the design goals that fx already provided details on so The operating system on the iPad is basically the standard X and U system that you might already know from desktop OS X or you might not which is Mach microkernel plus a free BSD or BSD Subsystem based on that microkernel It's like the usual unique system like having a kernel and user processes and one non-route user named mobile Which is actually the user that runs all the apps on your iDevice There's a little bit of extra security on the system for instance a kernel module called seatbelt and it's Used to assign profiles to applications for instance this application is not allowed to use internet or it's not allowed to I Don't know make use of Location services and whatnot There is a signature scheme for binary files that is implemented Right from the bootloader on up to the kernel And this is what we were going to detail in the next slides Also, there is a system-wide secure storage for credentials like for your Mail passwords wireless LAN passwords, but this is not like a disk encryption system itself So all the data you put on the device is like actually not encrypted So like all the dirty images that might be on your iDevice All this is not encrypted and There is actually at least to our knowledge no app that performs like full disk encryption for the device Also, there is like in any decent operating system you'd expect there is a SLR and DEP at least in most recent iOS versions and that's basically it so The integrity protection scheme that is implemented on the iPad Which does all the signature verification stuff Is based right from the bootloader on so the bootloader resides in ROM, which is like real ROM It's not writable. You can only read it and within this ROM. There is the like first level bootloader Mmm Also, there is a apple public key in that ROM and the bootloader uses this public key to Subsequently verify all the bootloader stages that are loaded afterwards So the ROM bootloader loads the LLB from flash and Verifies its signature using the apple public key stored in the ROM Right so the LLB will then load the next bootloader stage from flash again Verifies the signature and the next bootloader stage can then load the kernel also verify the kernel signature And then the kernel starts and all the fancy user processes can can be kickstart and all that And that's that's basically it the kernel then makes use of the of a special Binary signature scheme to verify the applications on the actual device All right, that's at least a fancy theory behind it when they implemented it they Might have realized You know bootloader stages in flash can be corrupted So it wouldn't be very nice if the device was bricked just because the bootloader stages in flash get corrupted All right, no problem So they added support to the bootloader to support USB like USB based file upload So the bootloader says, yeah, you know, there is this special recovery mode, which is called DFU mode You can enter it by pressing a button combination during boot process and once you enter DFU mode the bootloader will actually allow Subsequent bootloader stages to be uploaded using USB. Still signature verification will be done. So this is not like Not like a very obvious backdoor that you could use still signature verification is done, but of course The bootloader Say implements an additional feature So basically there's a buffer overflow in the USB handling code and when you upload a bootloader image or yeah a subsequent bootloader image then You can overwrite memory exploit it to execute arbitrary code from the bootloader on and that you can use to break the whole chain of trust and this is interesting because Apple cannot fix it Because the bug actually resides in the ROM bootloader code and this cannot be replaced without removing the trip So this is the first fail here there is Some way to overcome the code signature scheme right from the bootloader on and it's not even patchable So that's that's for the first fail right but this bug is already known and So we were interested In how Apple actually implements all the rest of it so to do the code verification apple uses x509 x509 is like a Standard and so Apple probably thought it's good to stick with it So they use certificate planes to actually provide signatures for their code and Typical plane would be like there is a app root CA some intermediate CA's and finally an end entity CA Or and entity certificate which is used to sign the code When we disassembled the bootloader code, we found that for some reason it would not verify the x509 basic constraints So for those of you who don't know what basic constraints is X509 is usually Usually used to build planes of trust that is one certificate follows another and the first one signs the second one And so on and so on until you reach the end entity certificate And the end entity certificate is then not allowed to sign any more certificates Right because otherwise the end entity could just extend the trust of the root CA to some arbitrary other guys Which was not intended to do So the fact if a Certificate is actually a CA certificate and may sign further certificates is encoded in the basic constraints field And this is what Apple does not track in the bootloader So that basically means When we have a valid and entity certificate and the private keys that that belong to it then we can sign further Certificates more and more certificates are like with arbitrary content saying arbitrary things saying, you know This colonel is valid. Please load it And actually Ios Ios supplies us or Apple supplies us with a valid Sign certificate including public keys which they use for Authenticating against the post notification server and this certificate resides on your very iDevice along with the private keys So what you do is take off the certificate take off the private keys Use it to sign another certificate and then you have your arbitrary certificate that you can sign Right it all sounds too good to be true and it somehow is because the bootloader restricts the length of the certificate train so that We cannot actually use this hack to make the bootloader run arbitrary kernels because the train is just too long the train Including the post notification certificate is just not short enough for the bootloader. So um If you guys want your encouraged to find maybe more or shorter of certificate path that could be used to trick The bootloader into a loading arbitrary code. We haven't found one But still Such kind of buck is such kind of buck is Already interesting enough and so we decided to have a look at the user land at the user land x549 implementation Right, so that is actually the x549 implementation that your browser relies on And interestingly we found that also the user land x549 implementation but also not verify the x549 basic constraints and This will then allow you to impersonate like any website create certificates for Yeah, basically everything on the internet that uses x549 certificates, which particularly includes HTTPS Like all the TLS connections you make to your bank or to the Apple App Store I think we're going to get more details on that later on But also the all the all the encrypted mail communication that you use like the IMAPS and pop3s That's that's that you can all man in the middle We have set up a test website for it So if you're in the lucky unlucky position to have a still vulnerable device You can just navigate to this URL and if it says yeah, it's all right. You see the little lock icon then you're in trouble We Yeah, we're going to see a screen for later on We would have loved to save this book and to like keep it OD till now But it was a bit too severe to just let it Rot on our computers and so we already reported it to Apple and it's already fixed at least for those persons who don't own Too old hardware like on the iPhone 3d I think it's just not fixed because it just doesn't support any recent iOS operating systems And so much for like Apple cares about your security, right? Yeah, so that's that's the screenshot you see the fancy lock icon here It says yeah, it's all right, but it actually isn't because I've never in my whole life purchased a real certificate Okay. Um, the next thing we're going to see is the signature scheme they use in the in the binary files and this is also full of fail because Actually that that looks like very very intelligent idea to make use of binary signatures so that the kernel can verify the applications and all that but For some reason the signatures that are embedded in the binary files Do not contain Signature information about the whole binary file. It was about some Selected pages with which includes executable program pages and some other stuff But quite a bunch of meta information in the binary is not signed So this signature scheme has actually a long tradition of being broken in jail breaks This is what the jail breaking guys do exploit also and I don't know for at least three iOS versions I know of exploits for for this signature scheme. So this also can be considered fail the general General approach to break it is to make use of the unsigned parts of the binary to redirect the control flow of the program Which probably you'd expect so Up to iOS 4.0.1 You can use the library into position feature which is kind of like debugging functionality to make you or to enable you to redirect Library calls to your own code so that you can intercept it and debug it As you cannot directly supply your own code because you would have to sign that You just redirect the control flow Into some already signed binary and just do return-oriented programming. So that's a pretty straightforward way to get code execution there on iOS 4.1 They fixed the bug above But still there is of course still other unsigned meta information Which is called the initializer section that's similar to the constructor section in an elf binary Which allows you to specify an address of a function that has to be called when the binary is loaded and That's pretty straightforward to redirect to control flow to any part of the program that is already signed so again, you do return-oriented programming and that's it and Basically in more recent other versions like for the 2.1 You basically do the same but you have to pay some attention to overcome a SLR and do some fancy tricks to overcome some range Tracks, but basically that the the bug is the same that you exploit you still exploit the fact that not the whole binary is signed So also the signature scheme is considered a big fail at least from our point of view So just a short word about the update process on iOS the update process is actually pretty straightforward Operating system updates are covered by the integrity protection of the operating system So if you update the operating system, then you basically reinstall it using iTunes at least for Ios for older Ios versions The Ios 5 supports over-the-air updates, which we haven't analyzed yet So I can't make any claims here, but for older Ios versions. That's exactly the situation that the integrity protection scheme already covers it Application updates like all the stuff that you receive from the app store are also covered by the app store And this is what Bruins is getting to detail on So I won't won't Get too much into detail here There is one thing if you have a radio trip a GSM radio trip in your iDevice, then the carrier can actually push Say profiles to your device and those profiles include APN settings for the for the PPP connection all that stuff Also include proxy settings, but we haven't had a deep look into it So again, you're encouraged are to look into those profiles and see if there is anything Useful or interesting we can make of it All right, I think that's it So I'm going to hand over to Bruins Hi, so I'm going to talk a bit about the app store architecture the app store is mostly like a standard online store So you have content in HTML and JavaScript which is rendered by a browser and is transported via HTTP and For things like login and authentication and check out you switch to HTTP HTTPS So the client is mostly a web kit which only talks to Right-listed hosts and which has some special API which is implemented a native code So there are several problems with this if you want to profit from Browser security features then you need a browser's user interface because Well without an address bar HTTPS does not make so much sense and if you do not indicate the source of pop-ups Then the user does not know whether pop-up asking you for your password is actually supplied by a secure page Or by an insecure page Furthermore the JavaScript library kind of co-convents the same origin policy so well standard web security does not cut the cake for Apple and This is why men in the middle attacks are really really bad You can inject JavaScript into some harmless page and we dress the entire user interface and fish for passwords or you can install and Make the victim even pay for your historian by just calling this API API function iTunes dot by action and Things like CSIF tokens do not really apply because the native code will happily inject all the correct tokens for you This is really hard to fix for Apple Because the only thing that could do is switch the entire store over to HTTPS only So here we have a screenshot of how the login screen looks like You see no indication of the source of it It's designed to look like a native app and not like a web page the entire app store And here's the code how to render a fake login screen So however not even vanilla web security was done correct in the app store There were many things like insecure cookies allowing to take over accounts missing or well really missing CSIF tokens and Well, if you had an XSS bug anywhere, then you would get really really Trouble because you would get drive-by downloads And we had a we had an XSS in the search field actually so you would exploit exploit such a thing by redirecting from the Safari to An URL of the the special URL scheme which Yeah, which then starts up the app stock lines which visits the vulnerable page so In the search field, yeah It was this bug was a little bit hard to exploit because the red kid XSS auditor prevents The direct execution of scripts which are already present in the URL But you can inject an iframe with a data source in In decent browsers. This is completely harmless because Java script which executes in the data Origin in the context of the data origin can't do really anything. However, it can use the API so this got us a drive-by purchase download install attack and Here's the pock It's fixed by now, but maybe you can use it and find a different XSS bug like Anywhere in the whitelist of domains. So have fun with that so essentially bottom line for for the Apple story is They weren't essentially control your content, which you know bottom line means to control your reality and of course Apple could send you via Arbitrary means to the app store and push you an arbitrary app But now luckily we can do that, too If someone has physical access they can simply jailbreak your device and install additional stuff And remotely the app store vulnerabilities and that doesn't only hold true for Apple but for everyone with the app store concept Will be will be there and there will be high value bucks that people use to you know extend the functionality of your fancy penis enlargement devices So Is that me? Yeah So now let's look at a device that was built in order to be Secure in order so you use it so you put all your data into the Google cloud the Chrome OS is A Linux based device it has the regular linux security features Kind of user land process you have one uid running the user land processes You have a SLR and EP however like whatever they're good for in Linux You have a pretty strong prevention of native code execution So one of the evil things that they did which makes exploitation a bitch is There is no fire system that is writable and executable at the same time you can think of it as a fire system DEP You have a personal firewall after we mentioned it they added IPv6 support and You actually have like with the Chrome browser you have automatic forced updates So it will actually update no matter whether you want it or not The only thing that you can actually run on the device is the Chrome browser There's a few other things, but essentially it comes down to a very fancy piece of hardware that runs the Chrome browser Which by itself has a pretty solid security story it has a suid sandbox every process runs on a different user ID and You're not executing binary plugins It actually hides the file system from you. So when you're trying to save a file It will only show you the locations that you are supposed to see Funnily enough, of course the flash plug in coming from Adobe just you know completely endorse this idea and shows you the entire file system But this is not a security boundary this is just you know to not confuse the user Well, we found really funny as remember like 2008 when Alex Soteroff and and the people had this MD5 collision certificate for SSL so Firefox went that way that they added the certificate in order to set the block bit Well chrome did that too, but they left out to setting the block bit so It is in your certificate store Explicitly installed, but it's not set invalid Doesn't get you anywhere because that certificate is you know back to 2004 something However, that was kind of funny you have a Developer mode on the Chromebook. So you don't have to jailbreak it You have a little switch that you can turn on then you get a big scary screen that says well now you're violating your warranty or whatnot And then you actually get root access So how does the protection work on the Chromebook? So they they actually had some really good ideas the firmware and The the kernel and the root file system. They're there twice like there's two copies of each And every copy is like one chain So you have the read-only memory on flash that verifies the firmware key block that verifies the firmware pre-embled and you know, it goes on and on it verifies the kernel it verifies everything The key material in every stage obviously sits in a stage before And the two file systems and kernels and everything being redundant Allows them to actually have pretty decent recovery stories Also, the device system integrity protection is something new. It's called DM verities. So it's a DM Module for the device manager So what they what they do is they actually have the file system not covering the entire partition But there is Sha one hashes of the blocks behind this and then there is a hash over the hashes that gets passed as a kernel parameter Into them, you know into the kernel when you boot the kernel So that is pretty smart because you're actually checking the integrity of individual blocks below the file system once the blog is accessed and Once the blog is accessed and is in cash. You're not checking the signature again It's it's a principle that many embedded systems people should actually follow So there's a few imperfections that we found Well, Google guys are smart and we're not so smart. So But there's a few things that that you know showed the partition table is actually not integrity protected So, you know, if someone can write your partition table, you're pretty much fucked Then there's two partitions one is called the OEM partition one is called the EFI partition And they're not integrity protected So if you would actually buy the story that the Chromium OS is the same as the Chrome OS and you compile the Chromium OS And you put it on your personal laptop thingy You're not running the Chrome EFI bios. So it will actually load EFI stuff from your EFI Partition and Chrome doesn't care about this scenario and they just you know load whatever you have and this enables you to have EFI back doors Also, there's a funny Unfortunately, not exploitable but funny breach in the integrity protection chain because what they do is like I told you that they Passed the share one Of the file system when they load the kernel However, what they sign and what they check is this like when they when they actually load the kernel is this Parameter line and after the check they're actually passing in the GUID of the partition That is going to contain the hashes. So this is what's signed and this is what's actually booted So if the firmware can be made to you know Fuck this up, then it's actually using arbitrary disk space to verify the share one hashes Also, I mentioned in the in the intro that the Chromebook is meant to be used by many people so What Yeran who's unfortunately not here because he's deejaying right now at our party already What he found out is it's really trivial to you know solder two pins together and make the read-only flash area less read-only So once you install a different initial boot stop loader you obviously can do whatever you want So in this university scenario, I mentioned before it is to solder points to own every other student in your class forever Here's the user data encryption It's pretty decent. I'm gonna skip over that because we're running out of time. What is interesting is that What Google did was they actually connected your account password to the crypto scheme, so the part of Part of the key scheme actually depends on your account password, which is then truncated to prevent offline brute force however effective that is So web story. Yep. Yeah, so the Google web store is used to distribute extensions for the Chrome browser and So which are in most in HTML and JavaScript and These extensions get access to an additional API Depending on permission squandered to them by the user upon install These extensions are partially for free partially you have to pay for them But you always get the source code because it's JavaScript And extensions are really really good for e-banking trillions and this kind of things Because the API is designed to make it simple to inject into the DOM of other pages So, I mean, it's like like a work of a few hours to write something to attack an e-banking site in this the first thing to note is that You do not have to actually pay for paid extensions. You can just Construct an URL which allows you to download them This also applies to beta test to extensions and beta testing and Google won't fix it. They will update the documentation. That's their fix So how to install malicious extensions onto a victim's browser So the first thing is of course social engineering But otherwise what's interesting is Google sync so you can synchronize a list of installed extensions to your Google account and If you enable this then a point Google account means a point browser Furthermore, there was one really nice bug so Chrome exposes a special API to the web store domain and this one is used to install extensions and They kind of fucked up the white list. So there were HTTP domains inside So you so you could install extensions from a man in the middle attacker and The confirmation dialogue where the user grants permission also used to be rendered from JavaScript, which could be Forgotten by the attacker So another thing is There are really more things you could do with malicious extensions For example, you could run click-jacking attacks against internal browser pages in order to do things like insert new SSL certificates You could rewrite download links so that they point to malicious files afterwards in order to get full system compromise Okay, so much for the Google web store Another thing we looked at our Google apps Google apps are very different. These are just plain web apps like Google Docs or Gmail and You need to see if you use this then you completely trust into one session cookie or into a lot of session cookies if you lose one of them all your data is lost or if Google stops behaving fair to you and There are many many Google apps by different authors also many of the apps which are by now provided by Google we're actually produced by companies which Google bought and This is very inconsistent and Basically an authentication nightmare, so some of the inconsistencies One thing was macros in Google Docs, so you Google Docs you can upload macros and some javascript dialect and these are executed server side also, you're supposed to There's some kind of marketplace for macros where you can execute or import macros written by other people For example, one of the most popular macros was a credit card number validity checkup by some Russian authors Yeah, so Luckily you can inspect the source code this one was actually benign, but if I used it in my well spreadsheet then later on the author could update his script and it would update in my spreadsheet as well and be less benign Furthermore Uploaded loaded macros I executed server side and they can issue web requests and these come from Google servers so that's fun for IP address filtering Adverse filtering and it's really fun for denial of service because these Google servers have a big big pipe Only Google can DOS Google so somehow inconsistencies there when you serve long and look at the various different things that can happen between the Google pages we had one bug where Where when you when you switched accounts there was a token which was transferred in the clear so I think the details are not that interesting any longer it's fixed and You could exploit it by logging a user in from a man in the middle attacker So There were also some cross-site scripting issues. I don't think I'll Go into the details, but what's interesting is the quality of the code is really really inconsistent I mean, there are services like postini by Google which have an abysmal source quality source code quality like multiple cross-site scriptings and search panel in the search fields of an admin panel I mean, it's really different The quality of the different Google apps Another important point if you want to entrust your data to the cloud is How do these different? Well, Google how do these different web apps exchange your data? So it's supposed to work via protocols like o out or o out to or outs up and the idea is a page like if comm requests access to my my data on Google and redirects my browser to the Google page puts its Access request into get parameter and then Google asks me whether whether I should allow the access and Then a token is generated and passed back This is bad in view of URL redirectors like this Google wants to access my data on Google Well, better allow However, the data is sent In the end to us Because it's leaked in the referral because this Huge URL there we directed to our home page. So That's it for me Thank you So essentially if if you're a fanboy, then you don't want to hear this Essentially Google can do whatever they want to your data. That's the whole point If you know you follow the drama with g plus accounts People putting all their data in there and then you know having this account cancelled because their name doesn't sound like a real name We actually do think that there will in the future Be more and more ways that people can get your Google account or session The thing where with the whole cloud concept is the moment someone gets your session You're fucked. I mean literally cluster fucked in both in like all holes. So If you like to go to, you know cafes with Wayflan and hang around in the st. Oba cloppy in Berlin or somewhere You shouldn't actually use your Google accounts This can lay this can actually affect you really hardly. I talked to one of the HP Gary guys They were watching anonymous downloading their emails for eight hours before Google actually closed their account That hurts Back to the Chromebook if someone has physical access to the Chromebook And Google doesn't promise you any security on the on the physical access scenario they can essentially back to work but forever and That's bad because the design is shit. The device is designed to be shared and Well, if you install the crew a Chrome extension where you update a Chrome extension Be sure that you know that your ass is owned So in general Well, what we found after we looked at all those issues is this is not the security you're looking for Whatever altruistic reasons you think the company has to provide you with the core tools and the core web apps that's not the reasons they have and If you rely on a cloud system to have all your data in it's you're putting all your eggs in one basket And it's not your basket They don't care if they lose a single user. You will probably care if you lose all your data What is also interesting is that if we look at web security and I mean the company Google is To the rim full of brilliant engineers, but even Google Appears to think that over as top 10 is something that you need to achieve for compliance Which in fact, you know, you should actually not have And Greg wants to say something I think Yeah, right So the point here is Regarding the Apple data protection If Apple actually wanted to protect your data They would probably allow you to roll your own crypto on the devices to exchange the root keys and all that stuff But they don't that's not about your data. That's about Apple's security here. That's not your security, right? So that's that's just regarding the Features marketed as security for you. Maybe security for the vendor. That's that's the point here. I guess yeah and with that we thank you for being here and Now we you know open for questions because we actually have fucking time And then we go to a large party that we provide a bus schedule to so if you actually want to hop on a bus And then go to a party. This is the night to do so. Thank you Thanks very much to all three of you for that very thorough analysis. I I'm sure there are lots of questions and I guess the guys are happy to take them Thanks for asking questions that makes that brings drinking 10 minutes earlier Yeah, you know the deal we have the mics in the aisles so if you line up at those mics Okay, so thanks for your talk. It was very interesting, but What are we supposed to do now? I mean iOS and secure the Chromebook insecure. Yeah I might I might actually sound too old-school, but how about running your fucking own mail server? Hi, you mentioned that the iPad comes with a pre is shipped with a user certificate. I wonder is this the Is it really shipped with the certificate or is it the one which is downloaded during the activation of the iPad? As far as I remember it is not yeah, it is actually downloaded as far as I remember So but in that scenario it doesn't make any difference because you get the certificate when you register or activate the device So one question from the internet Does the two-factor authentication protect against the Google Chromebook attacks? I think he means two-factor authentication process helps against the Google Chromebook attacks. I think Matt is the Google two-factor authentication where you get an SMS message with a token for login So Most of the attacks like not just the ones that we found but the ones that we're expecting to see in the future deal with especially in the Google Cloud scenario deal with stealing the session cookie. So that's past the authentication So no matter how many factors you used for authentication at the end of the day the web applications need to Keep the authentication state and that's in a session cookie and this is what you usually steal That's it. Thank you very much for coming and let's have a party