Atomistic IoT Penetration Testing Methodology

okay let me know when you can see it okay great um i'm gonna make the yeah great so good afternoon everyone um i first want to thank you all for being here uh both the ones watching it online and the ones that are watching it recorded after some months um so the name of this talk is atomistic internet of things foundation testing methodology it is an entry level talk so hopefully everyone will be able to to understand it and the and the approach that is suggested and it covers the thought process that i followed um when creating this iot and testing methodology that i've made for my current employer during this presentation i will try to

answer the questions on why an iot penetration testimony is necessary is necessary and why surprisingly it is not as hard to apply as one would think both okay the word atomistic here is really important because one of the conclusions that will arrive at the end of this talk is that when doing an append test to an iot device it is better to to see it as a contest of many things uh hence atomistic instead of seeing it as a whole okay um before we begin with the content i'd like to introduce myself um i'm a telecommunications engineer and and holds several um fantastic and cloud security certifications my interests at the moment are in iot of

course and web security also i'm i'm looking into into the ways to add um security into the the devops model and i also play ctf in my free time and i'm getting started in the in the bounty scene i was born in in georgia here in in catalonia in a in a city up north and i'm based in barcelona since i started my studies i love music in all its forms and singing with our channel and i also do krav maga which is the this self uh defense israeli system so really into the offensive and defensive stuff um so let's jump to talk why this talk okay um my current employer is a company from

the beverage industry and it has factories across europe okay one of the things that we were worried about uh were all these um small iot devices that were being introduced into the factories from which security augmentation was rare and which we didn't know how to test okay these recent years we have seen several different type of breaches from heart implants as you can see in the screen to defibrillators to the well i think most of the cd professionals have seen the the funny car hacking videos that that have been released these last years um but there was one specific incident which got a lot of attention which was the barca data bridge in this um data

breach what happened um is that the access to an administration interface uh was lost so credentials were reused and the hackers got access to more than 150 000 uh like webcams um the image you can see in the in the left bottom of the of the screen it's the barcata camera in the madison county jail where you can see the inmates doing their daily things um so the question that was made from upper management and that is that is a recurrent thing so uh when there is the the supply chaining attack the case that was so famous so much ago they also asked like what can we do to stop this in this case they ask

how can we protect these iot devices are being introduced um and we have to take into account that when talking about iot devices we're not only talking about information security so we're not only trying to protect information that we store in our systems um more and more we see um iot devices that are used um by people like i don't know um you know these automatic drones or or vehicles that have some some autonomy but um are still manipulated by by humans um in the event that these speakers are hacked as with uh with uh car hacking for example so that the consequences are really really huge okay and and the first question that we that

we had is is there a wallproof solution so is there something we can do that will make iot devices secure so definitely not uh but there are things that can be done okay and before starting with the within test mythology per se i wanted to explain uh some of the things that we are doing and that i think that companies should consider uh the first one that is usually done using under the gdpr is the third party security assessments where we check the controls that the suppliers have and um if you are a company uh who who develops or who has other companies that develop iot devices for for for them and then it's also worth it

to have an iot security standard and enforce it moreover the the biggest um cloud competitors these are aws azure and and google cloud platform have lately also released um specific iot management solutions essentially was this what these solutions do is they allow you to onboard fan of board iot devices um which gives you visibility on on on them you can see them yes if they have for example they also do like kind of an ids ids function so you can see if the device has open boards if the device has no vulnerability and also if it detects that one day one for example iot device starts communicating with a command and control they can alert

you of that of that incident and you can respond appropriately the last item that can be done is spendtest iot devices for low hanging fruits and the low hanging fruits part here is is really relevant because we're not trying to use i know that is a technique and it's a totally valid technique for researchers who try to find very specific vulnerabilities in commercialized devices but we're not trying to use lasers to modify the state of the chip and do things which are i think very hard for us for the majority of us to understand in a 45 minute talks we're talking about mitigating the risk that the oasp internet of things top 10 has classified

as the ones to avoid at all cost and which are these these iot risks okay and we have the divas.10 here for those that uh didn't know um owasp has a top 10 only for iot vulnerabilities and this top 10 is intended for both researchers enterprises and security professionals and is labeled as the vulnerabilities to avoid at all costs one could think that these vulnerabilities are really specific and really hard to exploit but if you start reviewing the list and we're going to do it uh really fast but i think it's important to have this uh information for the for the rest of the talk um we see that the first one is weak guessable

or hardcoded passwords so yes a web page where you can log in with that mean and and one two three four that was the the usual thing in routers uh up until not so long ago but nowadays we are seeing this uh this mirai botnets which what they do is they hack iot devices using the four credentials that they did this huge botnet that can attack uh web pages across the world also we have number two in secure network services so again and this is related with the lack of secure update mechanisms so usually you have insecure network services because the iot devices are not properly maintained and what this means is having an ssh

service that is outdated an ftp server that can be accessed from from the outside number three is in secure ecosystem interfaces that means web pages apis cloud or mobile applications which are poorly made and introducing vulnerabilities to the iot ecosystem then you have the lack of security mechanism because one of the things that is really problematic with iot devices that you can plug a usb flash a new version of the of the of the firmware that the iot is using and if the iot doesn't have measures to control that well signature verification measures to make sure that the that the firmware that you're trying to flash is actually intended for that device uh then you're going to be able to i don't

know have a shell on the device have an endpoint that's always listening for your commands whatever you want and well and the rest it's it's a similar idea okay but uh in secure voltaic components of course if you can't update the device in a proper manner you you will usually have a insecure and updated components insufficient privacy protection is related also with number nine which is in secure default settings so we see a lot of things which are not vulnerabilities per se but design faults that are there because no one has actually made the risk assessment of the iot device um and well then the the lack of encryption number seven uh lack of device

management and lack of physical hardening okay these are the the ten uh vulnerabilities to avoid at all cost but before we start uh talking about how to address all these vulnerabilities with uh with uh pentest methodology i wanted to to like waste two minutes to also um show some of the documents which are really relevant and and for companies that are starting to look into iot security they can be interesting and isa has a super interesting documentation they have six pieces of information which start with a baseline security for iot and they have the smart cars hospitals airport cities and industry 4.0 so what they do and here for example i have the the part of the

of the smart cars is they do a document that first has an overview of the sector then the the assets that apply to this sector then they do a threat and risk analysis so where are the weak points of this specific sector and they analyze attacks as they have happened in the in the recent years lastly they suggest security good practices and recommendations to avoid these types of attack the last document that i wanted to show is the iot security verification standard for those of you who come from an application security background you are probably um so you probably know the application security verification standard from mo wasp which essentially um classifies web pages in three different

levels and then suggests um so requirements to make them secure um this isbs document follows the same approach uh what it does is it classifies iot um systems in three levels depending on the type of data they are treating or the place in the factory that they are that they are working and then divide the iot per se in five different sections this is similar to the to the to the division to the atomistic part that we're going to do for this contest methodology and essentially you can see that these um five sections are the iot ecosystem essentially web pages apis and cloud uh platforms then you have the user space where you well you'll see the the

credentials and you encrypt the data and then you have the communication part which essentially will be the wireless communications and the hardware platform which means the chips that you have physically in that platform [Music] um so with iot devices being idle infrastructure there was the need to first understand which was the attack surface of an iot device and then developed the pentesh methodology that would help us actually protect these these iot devices by finding low-hanging vulnerabilities okay so i did what everyone would do i went to google and started searching which were the the files the articles that were more relevant and that provided more information on on this topic um there was one mind map which was really

interesting by chirag here and essentially he devised the attack surface of an iot in three different parts hardware software and network what is interesting about this my map is that you can see which are some of the most used tools when attacking these iot devices for example when you have a hardware um part of an id device that you want to contest you can do bleaching attacks high channel attacks um but you can also try to to connect directly to the to the exposed debugging interfaces like urtsbi i2c and jtag the same happens with software so you have mobile applications web applications okay so this this idea that keeps repeating and then you have the

network part with the different wireless protocols but also the wired ones the approach that that should have followed to do is my map is very similar to the one that i later followed with the difference that when thinking it and and saying okay how do i explain this in an easy to understand a way because of course we have to to speak with people across the company to ask them to do uh iot pen test how do i explain the different parts that we're going to test and [Music] that led me to the to the following question and the question is what is actually iot cyber security and this is a a very broad question but if you think

about it so an iot can have the cloud it can have the web and api it can have a mobile application in which you can configure several aspects of the iot but then sometimes you also have like i don't know a distribution of iot devices as happens with the philips hue light bulbs and then you have a centralizer which controls how the light bulbs work so the architectures in an iot system are really really huge and a big part when testing them is to understand how they are made and what do you actually need to test okay which leads us to the five iot and testing categories okay the way uh the methodology in the way

that i have divided an iot pen test is in these five categories so essentially have the hardware which would be the physical security of the controller but also have they left um the booking interfaces um in the in the that can be accessed by an attacker uh do they have it's like some iot devices have all the information stored in a in a micro sd card so is the firmware there can i extract the the firmware and then do what i want with it then we have of course the weapon api um um category the mobile application within the radio communication ones hardware and firmware you will always have but the other thresh the other three sorry are optional and

and will depend on the architecture that you that you find um the the the key here and and the concept that must um i think the goal is to encourage uh people to to lose um like the fear of pentesting devices because they are too complex is to split the architecture in something that that they can understand because weapon api there's a lot of documentation on how to contest mobile applications is the same firmware there's also some documentation and apply this atomistic categories to an iot pen test as a whole um what i did during the research that ended up developing the methodology and let me like do a small um yeah update hear the methodology

is going to be public um it is not public at the moment i want to do it but um i'm waiting for the moment to update it with the with the well the last information that we get from from doing different contests in the in the company where i'm working from um but yeah at some point it will be public if anyone has a doubt about it you can drop me an email or or whatever i'll be happy to answer um how it's going to how it's going to work um during the following slides we're going to see the state of the art of each of these categories and then we're going to see which work was done to understand

actually how to test them and and the mapping of the test that a band tester can do for each category so the state of the art of hardware band testing was pretty limited if you go and search online for hardware security hardware and testing hardware offensive security um you'll see that the options are really very limited um there is one page which is called iot and testing guide which has a lot of interesting information but but limited but they had key concepts as the fccid identification that allows you to get an understanding on how the iot devices are made and there was also also articles from fireeye um that essentially explained that the first part when trying to break

a hardware is to research the device identify the components know how it works uh which parts does it have and then try to dump the flash and from there extract analyze the firmware um so what i did in this in this category was first try the fccid identification that i that i told you so the fcc id it's the federal communications commission from the united states essentially it gives an identification number to each device that has to be sold to the to the public and then they leave or they put some of the information of the test that they do to guarantee that the device works in the intended frequency and that it has like acceptable uh values as

according to the law and all those documents are uploaded online and but also i try to to find user manuals datasheets change logs and for example here you can see the example of an amazon echo i took the fcc id as you can see as you can see here and and then by searching for fixing guides you can see exactly which components it is using so imagine you want to dump the flash memory of the amazon echo then you know exactly what it is sitting you can then spin up the documentation of this specific chip and see where is the information stored it's not a simple process okay so soldering is it's another difficult part when you

want to receive this information but at least you know where to start okay and what you can see in the fccid page sorry is the essentially the disassembly and the model and the frequencies and the protocols that the device accepts so for example if you go to this webpage which is publicly available you're going to see an amazon echo uh teared up into pieces to understand how it actually works and we jump to the firmware um and and and and the state of the art of the film work and here we have so in throughout the presentation we're going to see the different uh tools that the wasp offers so here we have the finger security

testing methodology which explains in detail how to first understand how the femur is working how to extract it and then how to analyze it and also there were some articles explaining why didn't walk and maybe if there are some of you who play ctf's now and then you're going to know what being what is used for so it's a it's a tool that essentially passes a file and keeps identifying the magic numbers and then once he knows that the file has i don't know 10 uh smaller files inside it extracts them in a folder for you to review so essentially it's like a decompressor uh for for file formats which are not not known and what we have in the fstm guide

it's um so they have composed it in nine stages and they start by like gathering information and they explain the different methods of obtaining the firmware how you can analyze it how to extract it and then how to to analyze the file system in the file system is where you're going to find the goal is when you're going to find the credentials the hardcoded credentials and all that information that the wasp was um like warning us about okay so if you want to get to know if there are secure network services if there are we get several hardware passwords then you're going to find that in the file system which most of the times is something similar

uh to two lens um so what i did in this in this category was to first i bought a cam a baby ip cam which was known to be vulnerable in this case as you can see in the picture it was exposing the the urt ports so i soldered myself uh i soldered um well yeah the connection with the urt urt2usb interface and then i was able to interact uh directly with the uh iptv cam um what is also important to know is that most of the times you are banging your health into the world to extract the firmware from the from the flash memory chip uh but some of the manufacturers actually release it online so for example what

you can see in this in these images here is the firmware for a well-known uh router um for from the link and if you get this firmware then you can unpack it you see the binary binary then you can run bin work on it and you're going to see the different files that it's using um the goal when you get this framework is to be able to emulate it so you'll have to understand in which architecture it is running and then using qm or the appropriate tools you can emulate it in your machine and interact with it as if it were a live device and with that said we go to the third category which is weapon api and here

wasp has covered so we have all the documentation that we want all the multi guides on how to test applications which tests should be conducted we have the last of them for application security likewise we have the wasp.10 for api security so lots of good information but although you can find um so you can find any of the well-known web vulnerabilities in an iot device there are some specific vulnerabilities which are more relevant in iot devices which are the ones we are going to discuss now and i'm going to explain why so this vulnerability is an injection on their abilities buffer overflow and differing vulnerabilities the reason why these vulnerabilities are more relevant in iot

devices is that for example with injection vulnerabilities if the website is hosted directly by the iot device and you find a way to execute code as in a remote core execution and then you're already touching the device so you don't have any additional security measure that is going to impact maybe you can have users as a data slash data that will like restrict you from jumping to the root but then again we've talked about how iot devices are hardly updated so probably will be easier for you to find an exploit that allows you to escalate previous um um likewise if you find a buffer overflow um the most likely scenario is that memory protection technique protection

techniques like dev or aslr are disabled the reason for this is that you have to think how much it costs an id device so if you have an iot device that is that costs five euros and they have to build the device build the web page build the mobile application this is this stuff expensive so sometimes the usability versus security and wins the usability and then they decide to disable all these memory protections that we are used to in limit services and in linux operating systems to make the device run smoother and last but not least important beefing vulnerabilities do you think vulnerabilities have gained a lot of popularity well they have always been popular but for example this last month

i think we saw uh maybe some of you can recall the confluence vulnerability where there was a patch that was released and researchers um when they saw that it was a critical security patch they went they downloaded the patch they reversed it and they knew exactly what was the problem and in a matter of days they were able to develop an exploit which started to be exploited in the wild in in a matter of hours um with iot devices happens the same with the idea that most iot devices are never updated when when they need to be updated so now imagine that the secure researchers get your amazon echo device or gets your um the the the ip cam that you have bought

for your home which was only 10 years and seemed like the perfect deal and they see that there is a remote code execution vulnerability um and the manufacturer releases a hot fix um if the secure update mechanism isn't there if the device are not updating automatically then in a matter of days this vulnerability will be exploited in a while wild what you can see in the screen these these two screenshots um are basically a an academic dummy uh case to show the risk so imagine that you have the old firmware where you get you get the variable in php and then you you do an eval tweet eval has long been regarded as a vulnerable um

function and it's used in ctf for those of you who play um and now the manufacturer release releases a new file which essentially tries to uh sanitize the input okay this is what you need so what an attacker will do is they'll know that the new file has a security fix but they don't know where it is they'll just do a div and they'll know exactly where the injection point is they're going to then enumerate devices which they know have not been touched usually because there's the version number in the footer of the page or or well a lot of different measures and they'll have a remote code execution if that's the case um with that said uh we go to the fourth

category which is mobile applications and again uh has discovered okay um we have the waste attempt so we know which are the things that we we want to be secure for and we know how to test for these vulnerabilities because we have the mobile security testing live um what i did during the research here was first of all to understand how the i'm not uh i'm not a mobile uh then tester but yes understand how the process of contesting my application works how you can reverse it how you can extract these other files and how you can understand how the application works from there um one tool that is used to provide us apk is its apk tool and essentially when uh

reviewing some of the cheap mobile applications for for iot devices there was one which essentially was doing what and i'm going to the beginning again so what the wasp is warning us about so we guess about our hardcore passwords okay um so what they were doing is if the password is it's has not been set then the password will be no password so then if you just build your payload then you're going to be able to interact with the device um as if you were the owner of it so again we're not looking for that specific book that is going to be that is super complex and that needs uh two months of research to find we're looking about bad

practices from the from the iot uh manufacturing companies that could leave organizations at risk and we go to the final uh category which is the radio communication one so there were some articles in in radio communications um there's there are some articles on this on and i've seen lately some some extra ones which have appeared on how to test iot devices uh for the bluetooth low energy vulnerabilities and also there is a really good talk uh from black hat usa 2015 that explains how zigbee works where are its vulnerabilities how you can exploit them how in certain scenarios you can jump the communication to force a certain key to be sent and you can intercept it and then you can take over

the devices so all these ideas and while here this was a it was the first time i saw zigbee and ambushes of energy so i first tried to understand how they were they are really specific probably you have to think like they are like http or tcp like you learn them in college or on your own but you have to to study them and you need to understand how they work before you're able to craft requests and then using uh bluetooth low energy sniffer i was able to intercept the the request from uh above a lightning bolt which was vulnerable and i was able to change the color of the bulb using uh the computer

okay so um before finishing the talk um i wanted to present uh two real uh world uh case scenarios which we have tested in the company where i'm currently working um explain which have been the takeaways that uh yeah that we have that we have seen from doing these pendants and where we think um are the risks okay uh so first i've i've thrown a little bit which was the architecture of the iot system that we're going to we're going to then test so as you can see um so this so for you to understand these were like um smart lightning uh panels which are placed on on the factories in the in the rooftop

um so depending on the light that comes from inside um they can uh they can change the amount of light that they are emitting and also depending on the number of of sound and and the footsteps that they hear they can change also the the quantity of light that they need um the architecture that the company providing this this service was using is they had an on-site web appliance which was a linux server and then they would connect directly to our internal network siege they would place their network gateways there and each network gateway which would communicate with 20 to 50 um lightning panels so we had several network gateways so the first thing that we need to

understand was what uh needed test okay and in this case you can see it it is pretty clear um so we had the web appliance server configuration so it was an ubuntu machine i have really updated one we had the web application we had the different gateways uh we have the zigbee connection per se and we had the the lining panels and the and the physical security of those panels um when there is a gateway usually the the logic of the application sits in the gateway and the zigbee doesn't have so sorry the lightning panel or the end iot device doesn't have much intelligence and and all the magic to say in some way happens on the gateway okay

so which were the the high level fundings of of this pen test um so when we started uh like scrubbing the surface and seeing what was what was happening and what was there um we saw that the system was using outdated in this machine so it had an ssh open for administrative purposes and it exposed several additional outdated services like apache2 so imagine one day this ssh key or ssh password gets lost then um in a second all the bad guys can access i don't know several iot systems in in the world um also the linux machine was not updated was provided as is um when checking the web appliance https which is an internal requirement that we

have at the company was not being used there was no password complexity on the webpage um default launcher default credentials were being used both in the so in the ssh service as i have explained and in the web appliance um the lighting giants were also exposing some debugging interfaces and they had well several additional web vulnerabilities um so you're going to wonder where are the radio communication and hardware vulnerabilities and one of the conclusions of the of the pen test and and of the of the work that we have been doing internally is that um usually the company commercializing a service like this smart lightning for example um builds the webpage can build the mobile

application if there's one builds the server where everything is going to is going to happen but doesn't build the the zigbee modules because for specific network um modules it happens the same with the gsm gsm modules that mobile phones have um they are only a few suppliers in the world that produce them and they make sure that the that the chips are working as expected and that are implementing the the radio communications protocols as they are supposed to another thing that that can happen is that sometimes uh companies will tweak some of the configuration and there are um there are well there are occasions where you can find uh some security uh measures off that can put the system at

risk okay um the second scenario that we have contested is the connected works okay so essentially there is a fridge which has a cam and can take photos of how how so if the bottles on in the fridge have been emptied or not and if the fridge needs refill and this system had an ios application but it also had a web appliance that was built on top on azure iot um which in turn communicated with salesforce so you see again a pretty complex architecture uh where you need to test different things in order to to give some assurance on the whole system know and the things that needed testing here were the web appliance the ios

application the bluetooth low energy connection and the controller of the fridge and also the integration with salesforce um so which were again the findings and the idea repeats okay um several webinars were found okay so we had xss password release related ones session management and also several mobile application vulnerabilities um but in the other hand the device was really well protected so it was one in one of oaf's iot isbs recommendation as you can see in the screen so all the contents of the controller were filled with this type of glue which was in turn covered in a black um with black painting and it was impossible to know which chips were working if you could extract something

from there if there was a debugging interface that you could plug into um it was it was really really difficult to do we tried to pry it open uh but uh but yeah it was it was really secure and and also the bluetooth energy connection that the controller was using uh was using the authentication so first the mobile application would connect to the cloud and retrieve some type of credentials then the ios application would do a connection to the free using bluetooth energy which would in turn check with the online application if it was allowed plus so this made the bluetooth energy also non straightforward we tried to do a python script that would interact with it and

try to bypass it but yeah it was a lot of time and and we we gave it a a green check um so well um again which are the conclusions of this of these fantastic that we did to the connected coolers that the things that are sold at scale so for example i imagine that the company that that sells this this controller is selling millions of them are well protected they know that they have an ip that they want to protect and they do it really well um but then where you can find more opportunities or more vulnerabilities in the web is in the web application and mobile application where uh yeah it's something that is being pushed

or made and and and can be can be vulnerable and we have a right to the conclusions so if you have followed the talk i hope uh i have been able to convince you that although sometimes we might lack time and knowledge of a specific iot device there are always tests which can and should be done to make sure our specs iot top 10 vulnerabilities are avoided um it is not only limited to the to the pen testing effort so again uh if you go back to the beginning i i think it's really important to have a a really good third participant where the provider explains which security measures they have used for the iot device and also if

you are the one on boarding the iot devices use a platform that makes it easy for you so that that allows you to see which devices are communicating why you have some of them which are offline why you have an outbound connection to a service that might be dangerous et cetera et cetera and and yeah radio communications modules are usually out of the box devices that are acquired from a limited number of suppliers and are usually well protected so uh i think like there has been there has to be specific research there and it's not something that the companies can do and that if you want to try all these iot specific communication protocols you're going to need a

specific specific equipment but there's plenty of information online thank you very much for listening to me you have any questions you can drop me an email you can find me on twitter or you can ask here awesome thank you now for the presentation thank you okay um i'm not saying we got any questions almost like i do have one um so i wanted to ask you when you find those vulnerabilities on on the devices right and and you i guess you report that back to you to the vendor so how that processes and this brilliant track or sometimes you know yeah it's in the right way yeah it's super difficult so when they have a vulnerability uh getting them to

fix it it's hard for the first scenario that i've presented the one of the lighting systems uh what they said is oh yeah well because uh someone told us that you wanted the in so the internal um linux server option but we also have a cloud solution which is well protected and has been tested so you should probably just switch and and the company is like okay but we have just purchased the old system so why are you telling this now um and yes if you find stuff in the mobile and web application usually it's easier for them to find if you find that the block interface or for example in the connected cooler parts we found some

credentials which were always being sent to the mobile application fixing things which are in the in the in the skeleton of the application it's really difficult for them and and yeah it's it's a it's a difficult process but we try now well at least you haven't been prosecuted right as yet yeah did you did you manage to put some mitigation in place for those cases or some um yeah of course so for example some of the things that we reported and we said um so there are things that companies uh um can can can can refuse to do for example so if when we found the limus machine which had ssh this ssh service which was always open

with an updated machine and we said we don't want that there so we have a level of security in the company that we try to maintain across all our assets and you're breaching that security they say yes we're going to to do a small update and we're going to ship it even if it's just for you because they understand that it's something unacceptable um if you find stuff that is like well that is a vulnerability but exploitation is not so straightforward uh then um yeah it's more it's more difficult for them yeah it's the same it's the same idea okay i mean in those cases you you i mean like it's like internal you may in a company internally

if we do yeah yeah so for example what we do and i think this is a work that um other companies have to start doing is in our standard we define the things that we that we want to know for sure for example things that i believe not the majority of companies have like a good asset inventory knowing which versions are are running on the devices where are the devices because most of the people don't know where the iot devices are placed so we try to do some of that stuff internally having yes like tracking files and having a list of the suppliers that we have that have uh put um like services in our

network um as we would do for example with the vpn also vpns in in internal networks has always been a thing but nowadays they are trying to reduce it um but without the help of the supplier there's only so much a company can make but yeah can make but yes we we try to do our best thanks now so thanks so much for your presentation i said so it's great to see local talent here presenting in this conference and i hope to see you again and hopefully face to face on the internet conference and yeah all the best thanks thanks thank you