 So, um, without further ado, uh, we have, uh, Steven Hooper and, uh, Philip Rish-Rush-Rush-Gosh. Okay, yeah, yeah. And, uh, please give him a warm welcome. Okay. So, hello to our talk about, um, OSOIP configuration interface security. My name is, um, Stefan. I'm a security researcher at the Fraunhofer Institute for Secure Information Technology. And I'm working there as a researcher for studying and dynamic code analysis. And, um, during my spare time, I'm working on IoT stuff. And with this talk, we want to share our new knowledge or experiences. I'm also one of the founder of, um, Hacking Team. It's called Team Sick. And it's a small hacking group, um, from Fraunhofer. So, Philip. Thank you, Stefan. Hello, my name is Philip. I'm also working at the Fraunhofer SIT in the Secure Software Engineering Department. And my main focus, my main, my main re- focus research is static code analysis and IoT vulnerability detection. And I'm also a member of Team Sick. First of all, some acknowledgement to Alexander Traut, Michael Dröger and Andreas Wittmann, who supported us within this project. Um, a short announcement. We, we brought some beer as we're from Germany and it's not the first time for us. And we always brought beer. And if you have some questions or want to talk to us, you're welcome to join us after the talk. So, in recent years we had several projects, um, which we also presented here at DEF CON. You, you might check it out on our web page. And after the last year, year at DEF CON, we, we wondered how do we get here this year again? And we were thinking about a topic or a, a research subject with a wide distribution, a complex software and which is readily, readily accessible because if you find bugs and nobody can exploit it, nobody cares about it. And we came up with voice over IP phones. So, the distribution, I mean it's in every office, on every desk, in every business. So the distribution is covered. On all of these phones runs a web server for management and configuration purposes, which is complex enough to build in bugs. And so this point is also covered. And the last point is the accessibility. I think in, in your business, the network is configured well and the voice phones are in a separate network and not accessible by any, any other participants of the network. And of course it's not accessible over the internet. But if you're familiar with, with how some, some companies handle their, their network, you, you might know this state where the everything is put in one network and the guests, the, the regular users and sometimes also the people from the internet can access all of the devices. So the third point is also covered. These phones are accessible from, from a lot of people and also from a lot of attackers. So this talk is structured as follows. I will give some short background about these phones. Then give an IoT hacking one-on-one to, to show you how we find our bugs. And then I will present all the, some findings. And in the end I will conclude the talk. Starting with the background. Each of those phones runs a, or has a ARM or MIPS CPU inside and on top of it runs a Linux. There you have some, the basic internet process, some watchdogs, the SIP even for, for the actual voice communication and then finally the web server which is used to configure all of this. And this web server is now, today our tech target. The methodology. We were, when figuring out these bugs we, we first set up the web phones as regular user or admin would do. So the web server is running. Afterwards we attach a HTTP proxy and just clicking around and see if we find some bugs in the, by, by just observing the traffic. If we don't find anything more there we extract the firmware to, to perform some static analysis for, for instance some secrets or, or some, some scripts which we can easily exploit. In the end for, for developing real exploits and emulation comes in handy and other dynamic analysis tools which, which are, are good for finding the real, the, the real interesting vulnerabilities. There's one exception. When, when you're lucky you find a way of injecting dynamic analysis tools directly on the phone you, so you save the step of emulation. Here are, here is an overview about some tools we used. You can check it out later in the, when the slides are online and I won't go through them in detail here. So the first step what you wanna do after you did the, the web pen testing you wanna grab the firmware. And this firmware access is not always this easy. Um, first of all it's out of scope for us to desolder chips and induce complex and expensive hardware setups because we are software people we, if we need to do this we, we skip to another phone. So what we, did we do? First we check the website of the vendor or the manufacturer to see whether we can download the complete firmware image from there. Some, when you're lucky you're done there. Sometimes you only get a diff or some patches to the base image already running on the phone or it's encrypted and you cannot do something with the app, update package from the website. Then another way is to, to trigger the update from the phone if this function is available and if you capture the traffic you might be, might be happy or lucky and you can, can get the firmware from there. But what we did most, most of the time was getting the firmware directly from the device because it's located there and so you can, can grab it from there. We used some, some cheap hardware adapters like the jeteculator or the bus pirate to connect that directly to the chips. And this for instance can be done as, as I show you here. If you find a chip on the device you may check the data sheet of this chip and see which parts or, or pins are provided. And if you find for instance the SPI interface you can connect the bus pirate to it which looks like this on the Akuvox and then you can directly read from the chip over the interface by using several tools. Here's an example with the flash rom tool which we used to dump the firmware. After dumping the firmware you can, can analyze as you wish for instance with binwalk to extract all the data. As you see on the bottom this is not the most stable connection as every output produces, every dump produces a different output but in the end it did the job pretty well for us. Another way is the UART interface. If you find a UART connection on the, on the phone you may connect the jeteculator as you see here in the picture and then you can see what happens. Sometimes you get connect, get access to the boot loader which has a minimum command set available and if you're lucky you can dump the flash memory from there with the dump command. This command is not always available but when you're lucky you, you get the firmware from there. But if you're more lucky you get directly into a root shell and have access to all the data on the chip with this root shell. The third way is a vulnerability inside the, the web interface. For instance if you find a command injection you may start a telnet daemon which allows you a connection to the, to the phone over with telnet and as it's not intended to run sometimes there's no authentication and you get a root, root shell directly and then you can dump the, the data. As the software on, on site the web phones is limited and not made for dumping all the stuff you need sometimes some tricks to get data on the phone for instance additional tools or you need some tricks to get data off the phone after you, you found what's, what's useful or what you want to investigate further. Here's an overview about some commands we used. You can check it out in the slides later. We won't go into detail here. The last step of the hacking 101 is the emulation. Once you got the firmware you, you want to run it in a, in an emulator to find the real interesting vulnerabilities and for doing this there are multiple ways. We focused on system mode emulation which looks like this. We getting a, a quimo emulator with the ARM or MIPS architecture and putting a respion on top of it. Inside the respion we put a CH root environment with all the data from the firmware we, we need to run up the web server and afterwards we attach our dynamic analysis tools for instance a GDB server or GDB directly or S trace in order to analyze the web server. Almost all the time you need to patch the binaries you execute as they are looking for some specific hardware interfaces which are only available on the, on the phone but not on your emulator. You can do this in multiple ways like hooking or, or patching with GDB. You need to be a little bit. There are multiple ways of doing it. Now the fun part. I will go through some findings and starting with the denial of service. If you imagine these phones are located in critical infrastructures or hospitals and the denial of service can cause pretty heavy damage or can, can cause lives. So denial of service is a, is an attack you want to avoid. So the first thing we, we found is by, by NMAP scanning the METAL phone you, you can cause the denial of service for around half an hour. So the, the hardware is so cheap and so limited that NMAP scan for a few seconds is enough to cause the denial of service. So you maybe want to spend a little bit more money on your, your hardware inside your phone. A little bit more interesting is, is this request at the Cisco phone. Can anybody guess what's the problem here? Right, it's the double quote in the GET request which leads to an assertion fail and causes the phone to reboot. This, this denies the service for around five minutes but then you can resend the, the request again and the phone is down forever. Whether this is good or bad, error handling everybody can decide on its own. As, I mean you avoid harder damage like remote code execution but yeah it's a denial of service attack. Afterwards we looked some known vulnerabilities like a CVE from 2017 which causes out of bound reads in the open SSL library which is used for the HTTPS connection for the web interface and we found four phones which were vulnerable to this and, and some cases the phone reboots and other cases just the web server crashes. But in any case you should update your, your libraries, your third party libraries to save you trouble in this, in this area. So another nice category is the bad crypto stuff. It's I think always present in every talk of us. Starting with the AcuWorks. And within, within this phone you, you can, can export all your, your configuration setting including the zip credentials and the credentials for the, for the web interface. And they claim it's encrypted as you see here it's not plain text but is it really encrypted. First thing we did is like checking whether it's basically phone coded which it isn't. So maybe it's really encrypted. So we investigated further and extracted the firmware and found the implementation for, for the decryption of these, these credentials and we, we, we found a phone AES decrypt method and we were thinking of our crypto lectures and we were able or we were curious about auditing the AES encryption from them but it turns out it's a self implemented crypto. It's a simple substitution and it's no AES at all. And so maybe we can break this, this crypto but it turns out you don't need to break the crypto. You get the key for free because it's provided in the firmware image and so it's not a secret. So coming to the classic web attacks. A classic the XSS. I mean by adding my favorite contact name into the audio codes. I get this. Just for completeness I mean we found it on several phones. Um yeah input sanitization is a thing. Keep doing it. Far more interesting is the Giga set Maxwell basic where we found two interesting vulnerabilities. First of all an information leakage by looking at the traffic. When, when asking this endpoint it, it returns two different messages. And what does it actually means? An attacker can ask the phone whether the admin is currently locked in or not. I mean that's not nice but it's not that bad right? Um I mean we just know that the admin is locked in but it's not, as it's not state of the art. We dig a little bit deeper and found the implement, implementation for, for this. Inside this snippet. Um I will explain it in detail here. Normally the admin locks in a session token is generated and stored for the, inside the database to check the further request from the admin whether he knows the session token. If an, if an attacker asks the phone something he does not know the session token so he sends an invalid token. And what the phone does right here is, is checks whether the currently locked in user is equal to user admin and whether the token uh which is provided is equal to the token stored in the database and then it tells you that the admin is locked in which is somehow weird because why would you tell somebody with an invalid token that the admin is locked in. So we dig a little bit deeper. We extracted the firmware as you might have guessed already it's a PHP, PHP implementation so you can read the implementation pretty well. And we find, found how the session or the authorization process is handled. For every request you provide a, a session token and then it, it checks whether a user ID is behind the session token. And if the session token is greater than zero you are allowed to do whatever you want to do. This is not nice but it's somehow okay. So we dig a little bit more deeper and found the following. The post parameters function is um used for, for setting all the uh several settings. And one of the settings is the admin password. So better secure this method. It, it starts as the last method um it checks whether a user ID is behind the session token you send. And it provides zero if the session token is invalid. And then it sets the, the para, all the settings you want to give. So changing the password is possible for nearly everybody. Except the, the admin needs to be locked in as this post parameters function is only, only executed when a user is locked in. And this I will show you in a demo. So on the left top you see the victim. And on the bottom you see the, the script from the attacker which just checks whether the admin is locked in with our first vulnerability. And then if it's locked in it sends the, the, the request for, for changing the, the password. Now the script is running and it sees the admin is not locked in. Now the admin locks in with this three digit password. And the script realizes that somebody locked in. And he directly changes the password. On top you will see that the admin is the real admin by, you see it right now. Interesting is also that when changing the password you don't need to know the old password. And now the admin locks out and the newly set password is 1, 2, 3, 4, 5, 6. And the attacker can, can lock in. And you see that, and the change password interface you see is the admin. So that's, was it from my side? Now Stefan will continue with the rest of the findings. Okay, thank you Philip. So at first a short introduction about past traversal who is not aware about this attack form. So imagine you have the web server and the web server can provide or the web application can provide some files or can write files by uploading. And for this file handling in a request the file name is send it to the application. Now imagine you as an attacker change the file name and for instance prepend some relative path information. If the web application does not verify this information or escaping or sanitizing it, it would be able for an attacker to escape from the default web server folder and can get access to, to different um, folder on the system. Such type of vulnerability we found on the YELLINK device so we can see here when we provide a few um, relative path information and the ETC shadow file to the file parameter. The device responds with the hashes of the, um, of the root user. This is possible because of two reasons. The first one, um, the input value is not verified and the second reason is the web service is running as, as root. As we saw the most, we'll see the most web services are running on root on our phones. But this is not enough currently we can just read. What we want to reach is now somehow get remote code execution. So we have to, to upload files. Um, one feature on the devices for uploading files is the ringtone upload. So our idea was now to, to use or override some script which is um, oh you don't see the full text. Sorry. Don't know why. Um, the, the idea is now to, to override some, some scripting file which will start at reboot and the scripting file contents then our code we want to execute. But the problem was um, the, the upload feature um, the upload or the overriding of the script file failed because the, uh, the application verifies the, the file content and says okay this is not a script file you have to upload some audio file and that's why overriding of the start script failed. But um, when we analyzed the software we saw that the um, application just verifies a few bytes of the file header. What we did is we take a few bytes of the file header, prepended it to our script file and then we were able to upload our file. Um, when the file is executed or the script is executed of course the first three lines are um, recognized as an error. But uh, the operating system still continues and our script um, will be executed. And so with this way we get um, file access and could execute arbitrary code again as root on this device. Then we were scanning or looking for some kind of back doors on the phones. We scanned the aqua box device and so okay there's a tenet port open. So um, the first question was is it running by default? Can we turn it off or why is it running? Uh, we don't know why it's running but you cannot turn it off. There's no configuration on the web interface, nothing. So this thing is running by default. The other thing is now to get somehow excess we need um, the password. Um, the firmware image of this device is not public available. We, we looked in different forums or on the, on the website. It's a Linux image but it's not um, public available. But as Philipp already explained we get some image dump via SPA. And when we extracted the file system here you can see these are the password hashes. And when you're a bit aware of password hashes you will realize this is a DS script protection and the problem of DS script is the maximum password length is eight. I have an old GPU on my um, office computer around four or five years and it took me 30 days to crack it. So you can imagine if you have a new or more modern device you can crack this in a few days. And when you know the root password or the admin password you can log into this device by design. Common injections. Another type of vulnerability. We found this type of vulnerability on seven or eight different phones. Um, at first a short explanation how it's working. Um, few, few of the, um, or the most phones providing their web interface some, some diagnostic tools where we can for instance um, ping or enter an IP address and then the phone will ping the IP address in the network. This should verify that the device is, is connected and working. So we enter the IP address. The IP address is forwarded to the web application and the web application constructs a command and this command then is forwarded to the libc system function and the function is executing our command. So here you see our ping. So what will now happen if you for instance append additional commands with a semi column and there is no sanitation. You can see um, the input is forwarded again to our application. Combined to one command and executed. So here you will see at first we will do zero pings because the minus C zero says zero pings. Then with the semi colon the command is finished. Then we execute a LS and the rest is commented out um, and so not executed anymore. So this is the idea of common injection. We found a lot of this type of vulnerability on the devices. We will just explain one here uh, of our findings. So we had an audio codex device and there we can um, can execute the telnet daemon again via common injection and then try to get some access via telnet. The problem here is you can see you need a basic authentication. So when you don't know as an attacker the credentials this can be a problem and later we will show a few information from our study and the most devices you can try the old admin admin and it works. But this is not um, the intention of the attack. We also tried somehow to bypass the authorization but um, we failed. So we searched another way to get somehow access to the device. And what we saw is um, there is also a change password, change password feature on the phone. Here you see the, the request and what you see is um, yeah, you see nothing. The first thing is there's no authorization header here. So this means everybody can trigger this request to change the password. But then you can argue okay, the attacker still has to know the old password. But same story, you see we have a parameter uh, an admin, admin, this is our user. Then we have the new password and we have to verify the new password. This means that you don't have to know the old password. So now as an attacker you can change the password of every user and we also have a common injection where we have to know the password. So when we combine this, you can say everybody can change a password and you can trigger remote code. We will show this in a short demo. So here, you will now see the original admin. He's logging in. To verify his, the original admin password you see here. It's from the um, authorization request. It's base 64 encoded and you see the original admin password is super pass. So now we log out. Here you see now our attacker script. And the attacker script will at first change this password super pass to pass. And in the second step, it will execute our common injection with the new set password. We'll show that the new password pass looks base 64 encoded in this way. And you see this is matching on our request. Yeah. It's not finished yet. Give me a second. So now we try to trigger our exploit, um, uh, on the device. But at first, um, to where we have to verify it, you see there's no tenet running. So there's no tenet service. So then we execute the exploit. So password changing. The ping. Log in. Admin. Password is pass. And again, we get a root shell because the service is running again as root. Okay. Thank you. Sometimes shit happens. And yeah, shit happens brings us to stack based buff overflows. We found on different devices, buff overflows. Um, in our abstract, we announced some arm based. But um, we also have MIPS devices. And MIPS is a bit, uh, is more rare. So we decided to explain the MIPS attack. Here you see one of the buff overflows. I have to mention this is not a pre alt overflow. You have to know or you have to be at least, um, user. But then you can use the buffer overflow to, um, escalate your privileges and get root. Um, by the way, this, um, bug or vulnerability is not fixed. Um, here you see to change again the password. There is a set security password command. And the internal code you see on the one side we have a target buffer with 32 bytes. And our input is forwarded as a parameter and used in a copy to common string function. You can imagine sounds like already like some string copy. And when we look into this implementation of the common string function you see this is a simple while loop just writing each character into our buffer. And the loop only stops on a bracket or on the null value. So it's, it's a buffer overflow. You find it in each, um, don't know college textbook. And, um, here you see a excerpt of the GDB of the debugging. You see we can control two registers. The most important is the return address. So we can control the program counter, jump to our code. And I will explain a bit more now how we get the final exploit. So one challenge when you try to exploit such a device is how do you bypass mitigations like NX, ALS, and so on. This was very easy. There is no mitigation. Then we were a bit lazy and at first decided, okay, we don't want to write, uh, MIPS shell code by hand because I'm not a MIPS guy. It would be too hard. So we auto-generated our shell code. The next step is we have to find, uh, the, the stack address on, on ARM exploitation. You simply make or use the branch to stack pointer gadget or on x86 you make a jump to ESP. Best of my knowledge that there is not such a, uh, gadget in, in MIPS. So we have to build it, uh, or simulate by, uh, other gadgets and we found two useful gadgets. The first one, simply use an ad operation to write the stack pointer to, to address ANO. Then we jump to our second gadget. This moves the ANO to T9 and then we can jump to T9 where our address of the stack pointer plus 32 byte offset. So, so, um, with this two gadgets we simply find our stack. Whereas shell code will be. We also have somehow to handle the bad characters. This means, um, when our shell code contains this type of correct characters it will not be written completely to the stack. So we have to somehow encode or obfuscate them. So for this we use, um, simply XOR encryption or encoding. Um, we took this idea from a good paper. It's from Jung Yang from Vintage Point. He wrote a very good white paper about MIPS exploitation. So if you're working in this field it's worth to read it. And with all this we can now design our final exploit. You see the payload structure. We have a few bytes padding. Our two gadgets, the decoder and then our shell code. But there's another challenge, especially on MIPS and sometimes on ARM. So here you can see this would be our stack layout. You see the decoder and our instructions. Here you see to, to add operations which should be just an example for our shell code. So now our decoder will modify the, the code in memory. But on the most MIPS CPU you have different types of, of caching. The one side you have the data cache and you have the instruction cache. And when you modify the, um, code in the memory the data cache is modified but the instruction cache not. And when you try to execute the code the instruction cache is executed but not the data cache. So our modification is not triggered and our shell code failed. So we get back and tried to, to fix the problem. There are two recommendations. On the one side there's a clear cache function but we did not find any gadgets in, on our device. Another option is, um, to use the sleep function to, to trigger a cache flush. We also tried this but after a few days we still failed. I don't know the reason but then we decided okay, back, um, two routes and we decided simply to write our shell code by hand and try to avoid null bytes or other bad characters. I want to give a few hints or, or what you can do to, um, avoid this. Here for instance you see, uh, instruction, uh, load immediate instruction to write a constant value to a register and some MIPS instruction have by designed, uh, a null byte included. So you can simply split it up, use some negative value, inverting and so on and play around and then you will get also your final result and this is null byte free. For setting zero values, classic tricks, some x, some xor function, xor two registers and in your target register you get your null and this instruction is also null byte free. It's sometimes, uh, especially when you need strings or other characters it can get a bit complicated but there we also used the xoring. This means we took our string value, um, xord it already with a constant value, put this as, as our baseline and then we can, um, xord it again during runtime and then during the runtime we have again our string and so we can bypass the decoding thing and the, um, shadow cache problem. After that we put everything in an assembler. In this case it was a good online assembler. We got our big ending assembly and can put this in our exploit script. Here we'll show a short demo. So in the lower window you will see our reverse shell listening. In the upper window this will execute our attack script. You see okay, our target device is online. Here you see the script. It's written in bash. Here you can see in the upper side our padding, our two gadgets and then, um, our handcrafted reverse shell. We will put this code, um, also online. So I think in the video it's hard to see but we also have written some advisory containing the code. You see again our exploit is executed. We are on the device. You see it in the lower window. We have access to the pass video and so on. We are again root because we already know all web services are running as root. Okay. Here you see a small overview of the devices we analyzed. Um, we had a lot of findings. The most critical findings we also announced CVEs for the minor findings. Uh, we did not. So this is so a few just for completeness. Below you find a link where we all uploaded all advisories we sent to the manufacturer. They also contain our exploit scripts and everything. So if you're interested you can read it. Here is again the overview of the vulnerability and the devices. As we can see, we found a lot of common injections, path traversal, a few buff overflows. Sometimes also a few classic, um, web based attacks. Um, when you look at short session ID we had one web server which is generating a session ID with the length of three characters. So we can say this session is very short. We also were curious, um, how, how much devices or phones are out there but you will not get any, any numbers from the manufacturer. And as, as Philip already explained normally this devices should not be reachable from outside. It's more a problem from, from an attacker from the inside. But we still made a short short scan and here you see the top four, um, devices and you see nearly over 10,000 devices were still reachable or this web interface reachable. We also made a few, um, sample tests if they use default credentials and we found also devices with default credentials. So, uh, you should take care about this problem because this can be an entry point to your company network when someone abuses or, or attacks the, the published or, or leak device. At the end you always should a few, give a few recommendation. I think the most are aware of this. You don't use default credentials. Keep the firmware update. Uh, you don't need a telnet server on a, on a, on a web phone. Even if you have a web server try to isolate it. Um, there are a few phones where we can also disable it. When you don't need it, disable it. And also we already mentioned network protection. Try to isolate your, your web network. Also for developers there are features called R, R, SLR, NX. Activate the compiler flex. Um, no hard coded keys. And also when you implement updates what we saw is there's just a manual update mechanism. So implement some auto update. It would be helpful. So this is now the end of the technical part. So at the end of more, more summary. Um, and I think the most already asked you, um, or wondered why we have such, um, back to the future images in it. The last part of the documentation we will make a short, um, time travel to a few, um, historical IT moments. You will see why. So when we go back to 92 or 91, everybody knows Linux was, uh, released. And from the concept we have a multi-user system. We have process isolation. So it was a good idea and a good baseline. So 96 then someone realized, okay, there are some bad C functions. We have a problem. We must do something. So different mitigations were introduced. NX protection, SLR. Now we also have control flow, integrity, relog and so on. So you can say from this time you have a good, um, desktop PC, PC. I think of course it's not bulletproof. You still can exploit it. But it, it was harder to attack. Then when we now will go to the year 2007, we get new, um, generation of devices. Everybody knows there are smartphones now. And what we see when the devices were released, again, everything was running as route with one user. Okay, we realized this is not such a good idea. What have we done? 2007, we introduced again mitigation techniques. So we missed our chance to, to produce, uh, new designs or protection mechanisms. Now we arrived today or the last two, three years. We are now in the time where IoT is in the focus. And when you listen or, uh, saw our vulnerabilities or read in the news, where are we? The state of 92. So in our opinion, something went wrong. And so you have to think when you use your web phone on the desk, in some cases, you're using technology which is on the security state from 28 years before now. Of course, we made responsible disclosure, we informed all vendors about our findings. We gave them 90 days or more to fix the bug. But sometimes also responsible disclosure can be a hard term journey. Um, here you see a few, uh, reaction. I have to mention, of course, most cooperated and also tried to fix the problem. But the first reaction sometimes were, why are you as investigating our poor phones? What should you say? Yeah, because we can. Um, sometimes they just argue, yeah, the device is not supported anymore. This is not our problem. Uh, I would say, yeah, it's your problem because your customers still, still use it. And sometimes you just have to, to argue. For instance, um, explain that you will publish all your findings on DEF CON and a thousand of people will listen and suddenly everything goes a bit faster. Um, I already mentioned that the bug overflow was not fixed. We had two vendors which did not react to our announcement. One was, um, HTAC. The other was Acubox. Um, we tried to contact them via email, via support, via Twitter, via Facebook, via LinkedIn. Um, the only thing we did not was going to China. But, um, if someone is here from the company, he can, can contact us. Um, we'll give him more details. Um, at the end, um, we had different, uh, we had 32 types of different phones. All in all we found 40 vulnerabilities. The most critical, we registered CVs so you can, can look it up. We realized during the pro, um, during the project, there's a lot of old technology out there. But on the other side, um, especially when you look at the newer models or at the premium flagship, Piper, whatever, super phones, you see there's a change. There are newer phones that are running, for instance, with Android, which can be good because you have, um, process isolation, sandbox, as Elinux, um, by design, which makes it, uh, more secure. But on the other side, you have now the feature to install apps. So when you install on your, on your desk phone some apps, you, you can, um, how can I say, you can bring in new, uh, attack or vulnerabilities, um, in the, um, installed, um, apps. And the question is now, do you really need a web browser or, um, WhatsApp on your web phone? So I think this is the end of our journey. Um, so as Philipp already announced, if you have some questions or want to talk to us, come to the front, grab some beer. If you have no question, just thirsty, also grab a beer. We brought them from, from Germany. It's good, uh, Munich beer. And so I can only say thank you for your attention. Here you see our contact address.