00:00:00.083-->00:00:04.000 >>Alright good morning! Thanks for coming out to my talk, thanks for having me here. Today 00:00:04.000-->00:00:08.583 I’m gonna be speaking about microservices and [clears throat] functions of the service 00:00:08.583-->00:00:14.250 for offensive security. Alright who am I? My name’s Ryan, I work as a pen tester at Centurion in 00:00:14.250-->00:00:19.708 Singapore and my first obsession with functions of the service happened in January of 20 15 00:00:19.708-->00:00:24.583 with AWS Lambda this is when it became available to general public. Uh essentially what it 00:00:24.583-->00:00:29.292 allows you to do is upload your code whether it’s like a python script or node JS or whatever 00:00:29.292-->00:00:35.208 you want to do and AWS takes care of all the scaling and um running of that code from the 00:00:35.208-->00:00:41.417 server onwards. So they give a million executions for free every month. Uh when it was 00:00:41.417-->00:00:47.000 first released they only supported Node JS uh but then I found lamb dash by Eric Hammond 00:00:47.000-->00:00:52.000 and that allowed me to uh get kind of shell access in this temporary lambda environment. So 00:00:55.083-->00:01:00.000 uh what you could do is you could uh upload use lamb dash up create a function and you could 00:01:00.000-->00:01:04.250 type in like a shell command and then that would run the function it would run the shell command 00:01:04.250-->00:01:08.958 get the output and report it back to you so you could start exploring this uh temporary 00:01:08.958-->00:01:13.958 environment that the lambda is running in. And this leads to the idea of serverless and the 00:01:16.292-->00:01:20.417 whole concept of serverless which I think is a terrible name um is the idea that there’s no 00:01:20.417-->00:01:24.292 servers right? That’s what it kind of gives you the perception of but the idea is that you 00:01:24.292-->00:01:28.667 don’t have to worry about the servers so you don’t need to have servers running that will 00:01:28.667-->00:01:35.417 uh manage them and know how to like be a system that can scale up very quickly. Um so if we 00:01:35.417-->00:01:40.958 look at the stack you basically have the function of the service you just run your code and um 00:01:40.958-->00:01:46.333 the cloud service provider takes care of the interpreter whether that’s like a python interpreter 00:01:46.333-->00:01:53.250 and everything down in the stack. A good example of functions of the service is um 00:01:53.250-->00:01:57.500 for like lambda you maybe you take a photo and it get’s uploaded to a S3 bucket uh that 00:01:57.500-->00:02:01.917 triggers a lambda worker which takes that photo applies some kind of filter to it and the 00:02:01.917-->00:02:06.667 returns that image back to the user or stores it somewhere else and see. There's been a few um 00:02:06.667-->00:02:12.208 security example security use cases for uh functions of the service and Airbnb had stream 00:02:12.208-->00:02:17.667 alert and this essentially the the a good way to scale your logging infrastructure. So if 00:02:17.667-->00:02:22.083 you imagine you have a very scaleable uh server infrastructure, you also need to 00:02:22.083-->00:02:26.292 have uh scalable log processing and and monitoring. So you can have lambda function which 00:02:26.292-->00:02:32.583 ingests all these uh logs apply some rules and then triggers another lambda function to maybe 00:02:32.583-->00:02:37.583 uh call pager duty or slack and get some alerts. Uh some other examples of using lambda are 00:02:39.792-->00:02:44.917 like having a API endpoint which a developer can uh call to and then that’ll change uh the 00:02:44.917-->00:02:49.792 firewall rule and EC2 instance and like an SHN or you could have a you can monitor like 00:02:49.792-->00:02:55.375 cloud flares um public IP addresses and only and update your firewall rules so that uh 00:02:55.375-->00:03:01.917 only cloud flares, web servers can talk to yours. AWS also has a web application firewall and 00:03:01.917-->00:03:08.167 they use AWS lambda um to do kind of some same kind of uh concepts in terms of like log 00:03:08.167-->00:03:13.875 monitoring and and reacting to some of the alerts from the web application firewall. Alright so 00:03:13.875-->00:03:19.208 now I”m going to run through um some very quick examples of a Hello World. Uh, In lambda 00:03:19.208-->00:03:23.125 basically you just go and create a function. Um and we can have a lot of triggers which you can 00:03:23.125-->00:03:28.625 run so you can integrate it uh with different AWS services so that will trigger your your code 00:03:28.625-->00:03:34.708 to run and we’re just going to do a very simple like 3 or 4 line python script uh which 00:03:34.708-->00:03:41.250 gonna go you use your able to go in and call up open DMS, get the current IP address and and print 00:03:41.250-->00:03:47.625 it off the screen. Um so we set some basic limitations. We want only need to use 128 megabits 00:03:47.625-->00:03:54.125 megabytes of memory and uh we’re going to timeout in one minute. So you run the code and we get a 00:03:54.125-->00:04:00.208 we see what IP address we’re running for and we can see that this this uh script ran for 224 00:04:00.208-->00:04:06.750 milliseconds and AWS is going to bill us for 300 milliseconds. There’s also other platforms 00:04:06.750-->00:04:11.917 like play with Docker uh which kind of lets you experiment with Docker Swarm. Uh and you can 00:04:11.917-->00:04:16.833 just go to play with docker dot com uh you all you have to do is click a captcha and then you get 00:04:16.833-->00:04:23.417 4 hours to explore around in this temporary uh environment, and they’re running on top of 00:04:23.417-->00:04:28.417 AWS and they have a python interpreter there um so you can go to play dash with docker dot 00:04:30.792-->00:04:37.208 com and you you have 4, 4 hours to kind of explore and try out their docker. UH what’s 00:04:37.208-->00:04:40.667 interesting about this is that uh it’s anonymous. You don’t need an account, you don’t need 00:04:40.667-->00:04:45.250 to sign up, you don’t need to identify yourself in anyway but then you only have a time limit 00:04:45.250-->00:04:49.917 of 4 hours and it’s a captia so it’s difficult to kind of automate kind of getting that 00:04:49.917-->00:04:54.917 temporary shell. Um now let’s talk a little bit about cost. So if you go to serverless calc dot 00:04:57.708-->00:05:02.042 com you can see a good comparison, an overview of the cost of different uh cloud 00:05:02.042-->00:05:06.833 service providers and if we think back to that simple Hello World example where it ran for 00:05:06.833-->00:05:13.333 300 milliseconds uh you could run that 10 million times for only a dollar 80 every month. So 00:05:13.333-->00:05:18.917 it’s very cost effective. Um now different cloud service providers have different levels 00:05:18.917-->00:05:25.542 of uh kind of maturity in a sense of where they support this uh functions as a service. AWS 00:05:25.542-->00:05:31.083 has 14 regions and Azure has 23. So they’re kind of the most uh committed to functions of the 00:05:31.083-->00:05:37.125 service. Uh it this is a good overview. So we have um Google. Google gives you a negative IP 00:05:37.125-->00:05:44.042 version 6 address and IBM supports docker so if you think about um functions of the 00:05:44.042-->00:05:48.250 service just uploading your code, um if you can have like a docker image you can have much 00:05:48.250-->00:05:51.333 greater control over the environment that your code’s running in and what else is 00:05:51.333-->00:05:58.250 there. Um and so AWS has 14 regions and Asure has 23. I think Azure is probably the most 00:05:58.250-->00:06:02.750 uh mature kind of service offering in terms of functions of the service. They support the 00:06:02.750-->00:06:09.500 most uh the most uh scripting languages um but they only run on Windows so some limitations 00:06:09.500-->00:06:14.500 there depending on what you want to do. So in summary I think there’s 3 uh main advantages to 00:06:16.875-->00:06:22.042 functions of the service. It’s very low cost there or some are free in most cases um when you 00:06:22.042-->00:06:26.500 sign up they give you a sign up credit and it’s ver due to the lost cost of most of the 00:06:26.500-->00:06:31.625 services they offer it can be difficult to use all of that credit and you get a unspecified 00:06:31.625-->00:06:35.583 source IP address. So what these cloud service providers are doing is they take your code 00:06:35.583-->00:06:40.917 they inject it into kind of like a a random server which they have and then your code will run 00:06:40.917-->00:06:43.958 there and then they’ll take it out and put it in different different servers so you're kind 00:06:43.958-->00:06:50.083 of running your code in a different environment almost every time. A lot of them have 00:06:50.083-->00:06:55.083 uh like global data centers and data centers in China so you can use that to your advantage. So 00:06:58.417-->00:07:04.208 this lead me to start a small project of mine called project thunder struck and the goal is 00:07:04.208-->00:07:10.083 to find use cases for functions of their service in offensive security and I explored 00:07:10.083-->00:07:13.833 different cloud service providers and I wanted to get supercomputer resources without 00:07:13.833-->00:07:19.167 paying super computer prices and uh earlier this week I spoke at B sides about searching an IP 00:07:19.167-->00:07:24.125 version 6 and today I’m going to talk about distributed denial of service without servers and uh 00:07:24.125-->00:07:29.125 brute forcing SMS OTP’s. Alright so we we had this client that purchased the anti DDOS service 00:07:33.417-->00:07:37.375 and they were kind of concerned whether or not it would work. Um they wanted to know like is is 00:07:37.375-->00:07:42.125 it going to work at 2 AM. Is there someone manage monitoring a console and manually doing 00:07:42.125-->00:07:46.458 something or is it an automated and does it really work. So I came up with this plan uh to 00:07:46.458-->00:07:52.458 find a very simple HTTP D DOS tool written in python to something really script kitty 00:07:52.458-->00:07:57.667 and then upload it to a cloud service provider uh trigger it and then monitor the target and 00:07:57.667-->00:08:03.583 wait for the results and what I found was uh Golden Eye. Uh Golden Eye’s pretty cool, it has 00:08:03.583-->00:08:09.667 some good S key there and um so I just modified it to hard code the target in with some uh some 00:08:09.667-->00:08:13.333 of there kind of like man line parameters they just hard coding everything and then I had it 00:08:13.333-->00:08:18.208 time out after a minute so I only want to do D DOS for a minute and then I want it to 00:08:18.208-->00:08:23.417 stop. So this is the modifications I made. Just uh look at line 5, 6, and 7 remove 00:08:23.417-->00:08:28.250 everything down from there and then hard code in all the parameters. So I set up my test 00:08:28.250-->00:08:33.375 server I ran the function and then I tailed my uh Apache logs and I just start seeing all 00:08:33.375-->00:08:37.792 these requests coming in. So it’s making post requests with like large amount of data in the 00:08:37.792-->00:08:42.792 URL and and uh post data so I can see it’s working. So it’s time for the the real attack so 00:08:45.125-->00:08:49.167 I I triggered triggered the code to start and I just waited for the abuse email to come in from 00:08:49.167-->00:08:55.292 the cloud service provider and and from the client and uh but then the site was still up so 00:08:55.292-->00:09:00.167 something something strange was happening um so I took a look using curl and I realized that 00:09:00.167-->00:09:04.875 the the site was responding with a location header and this location header’s part of the 00:09:04.875-->00:09:10.250 anti DDOS solution that they they purchased and they basically want to, I I guess 00:09:10.250-->00:09:14.125 they’re trying to see that it’s a real user so if it’s your web browser a web browser just 00:09:14.125-->00:09:18.333 handled that but if you’re using some tool then obviously the tool will not be able to uh 00:09:18.333-->00:09:24.250 follow the redirection. So um I went back to Golden Eye, uh went to line 336 modified it a little 00:09:24.250-->00:09:28.667 bit just to get the response, get the location header and send the request over there, tried it 00:09:28.667-->00:09:33.667 again and it worked. So I was using uh AWS route 53 uh health checks uh and essentially it’s 00:09:36.792-->00:09:41.542 like doing a curl to that web server looking for a certain response then determining 00:09:41.542-->00:09:46.375 whether or not it’s like up and it’s working. If it doesn’t get a response it assumes it’s down. 00:09:46.375-->00:09:51.542 Um So it has a very nice graph over here you can see that where we started the attack and then 00:09:51.542-->00:09:56.792 uh it went down and then we can stop the attack and immediately come back up. Uh and another 00:09:56.792-->00:10:01.208 good thing about using AWS uh route 53 health checks is that it does a health check from 00:10:01.208-->00:10:06.750 different regions so you can get uh uh different perspective on the server from like Tokyo, 00:10:06.750-->00:10:10.083 Singapore, Sydney, Ireland and all these different like worldviews to make sure that 00:10:10.083-->00:10:15.542 it’s uh available from uh different different locations rather than uh maybe it just 00:10:15.542-->00:10:21.167 goes down from where you’re checking. So here’s the results uh I managed to to generate 00:10:21.167-->00:10:26.167 about uh 30 Mbps of uh DDOS traffic um but I only used 1 region and 1, 1 zone um from 1 00:10:29.792-->00:10:34.375 cloud service provider. I managed to get pretty good uh bandwidth out of that. Uh so if 00:10:34.375-->00:10:41.042 I was to maximize this over multiple regions and uh multiple service providers uh it would 00:10:41.042-->00:10:46.208 grow to be quite a lot of bandwidth and the best case about this is that uh the abuse 00:10:46.208-->00:10:51.208 was not detected by the cloud service provider and our account is still active. [Laughing] So 00:10:53.875-->00:11:00.208 in summary I think uh this is and anyone who knows how to copy and paste a python script can uh 00:11:00.208-->00:11:05.292 become a DDOS king and they can get access to really high bandwidth um and almost for 00:11:05.292-->00:11:10.292 free. Okay so now I”m going to talk about brute forcing SMS OTP’s. Essentially when you go 00:11:15.333-->00:11:21.542 to buy a credit card purchase online, uh your bank will send you an SMS with like a 6 digit 00:11:21.542-->00:11:27.458 OTP and it expires within 100 seconds um so this is this is similar to verify by Visa kind 00:11:27.458-->00:11:34.250 of setup which I looked at and if we look at the architecture diagram there’s a kind of 2 main 00:11:34.250-->00:11:39.958 components. One is the access control server and the merchant plug in and the access control 00:11:39.958-->00:11:45.458 server is uh kind of the key component that’s responsible for the OTP verification so it 00:11:45.458-->00:11:49.750 checks to make sure that the cardholder is like registered and enrolled, if it can send the 00:11:49.750-->00:11:56.375 SMS and then it pardons the SMS and makes sure that it’s uh correct or it’s incorrect. Um So 00:11:56.375-->00:12:01.000 it’s up to the ACS component to detect a brute force and most of the time these components are 00:12:01.000-->00:12:06.875 generated by or there created and provided by third party providers and they can either be 00:12:06.875-->00:12:13.792 hosted in house, integrated into the banking system or they can be uh uh externally hosted um 00:12:13.792-->00:12:18.792 service for the bank and um these it does a little some basic compliance testing of the 00:12:22.958-->00:12:28.333 ACS and merchant plugin uh but it seems to be more around um making sure that it it’s 00:12:28.333-->00:12:32.625 instructability that it functions and it kind of meets the spec and they clearly state 00:12:32.625-->00:12:39.375 there's not uh any kind of endorsement of warranty to the security of the system and uh 00:12:39.375-->00:12:44.375 yeah so it’s up to the ACS to check that the um OTP when entered is uh correct and to 00:12:47.583-->00:12:52.208 implement any kind of security controls that would be necessary for this for this uh component 00:12:52.208-->00:12:57.208 in the system. So I came up with this plan uh I need to get a 6 a 6 digit SMS OTP value. Uh 00:13:01.833-->00:13:06.917 there’s a million possible values and I have 100 seconds to do so. So The plan is I start a 00:13:06.917-->00:13:11.917 simulated online purchase, I load the SMS OTP page I submit 1 OTP, I capture the HTTP request, 00:13:14.167-->00:13:20.792 I load that into Thunderstruck, UH start all the workers, they start guessing the correct value 00:13:20.792-->00:13:25.417 and when they find it they will report back and I can take that request, put it back in the 00:13:25.417-->00:13:32.292 browser and uh continue with the online purchase and I have to do all of that within 100 seconds. 00:13:32.292-->00:13:37.292 So it seems like a good use case for functions of the service the scale is. So this is the 00:13:40.000-->00:13:46.750 architecture of uh the script that I came out with. [Gulp] Essentially I have this python 00:13:46.750-->00:13:52.667 script which is going to create a random OTP value, it’s gonnas uh clear the guess counter cause 00:13:52.667-->00:13:57.167 I want to keep track of how many guesses I’ve made and how long it takes to brute force all one 00:13:57.167-->00:14:02.875 million possible values um then just gonna keep pulling elasticsearch to wait for the 00:14:02.875-->00:14:07.375 result and then trigger all the lambda workers they’re gonna recursively call themselves to 00:14:07.375-->00:14:11.542 try and help with uh scaling and then they’re all going to start attacking the this Google App 00:14:11.542-->00:14:17.292 engine server that I set up to simulate kind of the online purchasing uh payment processor 00:14:17.292-->00:14:23.375 and the and each Google App uh engine instance is going to talk to a mim cache server to check 00:14:23.375-->00:14:28.208 if the OTP is correct, increment the guess counter and then return some kind of message to 00:14:28.208-->00:14:34.542 indicate wether it it’s the correct OTP or the the wrong OTP and the AWS lambda worker is 00:14:34.542-->00:14:38.417 gonna look at that response and then if it’s the correct OTP it’s going to report it into 00:14:38.417-->00:14:42.250 elastic search and then that’ll get picked up by the python script that’s constantly 00:14:42.250-->00:14:48.708 pulling. So I created this uh Google App engine basically learning how to scale the server 00:14:48.708-->00:14:55.500 to handle about 16-->000 requests per second. Um so I used 200 instances and I have uh like a 00:14:55.500-->00:15:00.500 50 line uh python script, very simply just uh handle setting the OTP storing it in mim cache 00:15:02.583-->00:15:09.333 uh getting the current OTP that was um guessed checking the value returning the message and 00:15:09.333-->00:15:13.292 then uh incrementing the guess counter and and kind of reporting a little bit back 00:15:13.292-->00:15:19.417 about uh how many guesses have been completed out of uh how many there are for that possible 00:15:19.417-->00:15:24.417 OTP value. Um I used a mim cache dedicated back in with a uh that can support 20-->000 operations a 00:15:28.042-->00:15:31.583 second and I set a daily spending limit of 10 dollars cause I don’t want anything to 00:15:31.583-->00:15:36.583 go out of control. Um so just to cheat cloud app deploy and my 200 servers running. On the kind 00:15:39.833-->00:15:45.042 of attacking side I have this script called trigger worker AWS. Uh basically just calls to 00:15:45.042-->00:15:50.042 the Google App uh site and sets the OTP and then it pulls the elastic search to kinda to keep 00:15:52.792-->00:15:57.792 searching for the correct value and then I invoke all the lambda functions and then uh wait for 00:15:59.917-->00:16:05.375 the result. Uh for the lambda first function itself it’s the worker dot POI um IT’s basically 00:16:05.375-->00:16:10.375 just going to um receive uh uh like a meh a message um from the trigger worker AWS to say uh 00:16:12.875-->00:16:19.625 which OTP’s it should try brute forcing it’s gonna um call itself with each different OTP 00:16:19.625-->00:16:24.625 and then brute force uh to the Google App engine site. So I have this simple test that’s set 00:16:27.542-->00:16:34.333 up so I could call the set OTP I can see I can set it to 013370 I can see how many OTPs have been 00:16:34.333-->00:16:40.167 guessed and I can try an OTP like 1, 2, 3, 4, 5, 6 and I can see that it’s wrong but I’ve 00:16:40.167-->00:16:44.958 tried one guess so now I have a good test server to test out my theory and see if this will 00:16:44.958-->00:16:49.958 work. So I started small, started with 4 digits uh I was able to split up the work so 00:16:52.208-->00:16:57.208 that each worker does guess guesses 100 OTPs and so over a 100 workers I can do this in 00:16:59.292-->00:17:05.250 about I can I can find the OTP in 12 seconds but I can brute force all possible values in 26 00:17:05.250-->00:17:11.458 seconds. So this includes um like from the time I started to setting the OTP value to 00:17:11.458-->00:17:15.542 triggering all the workers to pulling for the response in elastic search and getting the 00:17:15.542-->00:17:20.542 value back. So I split up the work a little bit more. UH give less OTPs to more workers and I 00:17:22.750-->00:17:28.583 can reduce the time down to 11 seconds and uh if I do it uh even further I can get it in 7 00:17:28.583-->00:17:33.583 seconds and uh so I scaled up a another order of magnitude to 5 digits and I was able to do it 00:17:37.750-->00:17:42.750 in 100 seconds uh with 100 OTPs a worker and 72 seconds and 24 seconds I split the work even 00:17:46.167-->00:17:51.167 more. Then I started on the 6 digits and in 6 digits um it’s a little bit sketchy so sometimes 00:17:54.500-->00:18:01.375 it it can find it in 31 seconds so I found the OTP in 31 seconds but then it took about 3 minutes 00:18:01.375-->00:18:06.375 and 43 seconds to brute force all million and so I split the work up a little bit more but it 00:18:08.708-->00:18:14.500 didn’t seem to really have much effect on uh doing it faster and so I managed sometimes I managed 00:18:14.500-->00:18:19.500 to get in about a minute and 16 seconds or 76 seconds which is still under the 100 second uh 00:18:22.333-->00:18:27.333 time limited window but it used some uh different geographic regions or different regions 00:18:30.125-->00:18:36.208 from AWS to uh try and make sure they’re closer to the test server this Google App test 00:18:36.208-->00:18:42.708 server I’m using and maybe to deal with some latency issues and so I did some more tests and 00:18:42.708-->00:18:47.708 I managed to get in like 68 seconds, 101 seconds using a different uh using AWS regions 00:18:50.208-->00:18:55.917 which are closer to the Google App engine region where it’s the code is running and so 00:18:55.917-->00:19:00.250 eventually uh yesterday I did another demo and I recorded it so I’m going to show you the 00:19:00.250-->00:19:05.250 video soon and I managed to get it in 29 seconds. Okay so now’s the demo time. Oops. Okay so I 00:19:23.833-->00:19:28.833 ran the script it generated a random OTP value of 6 6 1 2 2 6 it triggered uh all these 00:19:31.208-->00:19:35.000 workers across different regions, it took about 8 seconds to start all those lambda 00:19:35.000-->00:19:41.208 workers and then it’s pulling for elasticsearch in the background and in active 29 00:19:41.208-->00:19:46.208 seconds it’s gonna lets fast forward a little bit. Yeah so then in 29 seconds it managed to 00:19:50.667-->00:19:55.667 find the OTP value, get it out of elasticsearch and complete it. Okay so I used a test server 00:20:07.917-->00:20:14.833 in Google App engine with 200 instances and uh I was able to guess about 500-->000 in 6 the 00:20:14.833-->00:20:19.542 first 60 seconds and then the rest of the requests kind of timeout um or they they take a 00:20:19.542-->00:20:24.708 really long time to process and uh there are some requirements to this attack. Essentially you 00:20:24.708-->00:20:29.417 need to be able to keep guessing the OTP and not have an account lockout and you need to have a 00:20:29.417-->00:20:34.417 server that can handle you know in theory 16 or 17-->000 requests per second so there’s a risk of 00:20:34.417-->00:20:39.500 causing a denial of service and uh you should try and do the attack from uh somewhere that’s 00:20:39.500-->00:20:44.542 geographically close to the target and you need a little bit of luck. Um over here’s the 00:20:44.542-->00:20:49.500 graph of the Google App engine so you can see it’s it’s handling about maybe 8 or 10-->000 00:20:49.500-->00:20:54.500 requests per second. I’m gonna be posting my code and my slide is on uh github and if you look 00:20:57.083-->00:21:03.542 at the uh Visa, uh they visa replaced the re [sighs] visa released a merchant server plug 00:21:03.542-->00:21:10.000 in um guide implementation guide where they say they should expect about a 5 minutes timeout 00:21:10.000-->00:21:14.750 um for handling the OTP in that transaction and I think going further um some banks have 00:21:14.750-->00:21:20.250 introduced a 8 digit OTP but they’ve also increased the time limit to 3 minutes. Um in order 00:21:20.250-->00:21:24.708 to do this I probably needed a more scaleable test server to test this out but I think this 00:21:24.708-->00:21:29.583 is interesting because um there there’s probably further applications of this style of 00:21:29.583-->00:21:34.208 attack maybe on password reset URL’s or count signup and registration where there’s no 00:21:34.208-->00:21:39.208 account lockout but you can brute force it for a a longer period. Okay so I hope you found 00:21:42.958-->00:21:46.667 this talk interesting and if you like this topic I would definitely recommend you check 00:21:46.667-->00:21:53.458 out um the talk Gone in 60 Milliseconds um last year in December by Rick Jones at CCC um 00:21:53.458-->00:21:58.208 there’s also a few talks there was a talk last year at Black hat and there was a few um this 00:21:58.208-->00:22:04.292 year at B sides Black hat and Def Con and uh if you find this interesting uh maybe there’s 00:22:04.292-->00:22:09.000 some some key points that might get you started in doing your own kind of work and in the 00:22:09.000-->00:22:13.833 space of um functions of the service so you can look at uh AWS lambda they they give you an 00:22:13.833-->00:22:20.542 instance with uh 1 point 5 gigs and you can run that for 266 seconds for free every month. 00:22:20.542-->00:22:25.583 There’s also the Alibaba Cloud based out of China but you need a plus AD6 mobile number to 00:22:25.583-->00:22:30.708 register and quite interestingly if you look at IBM Open Whisk you can have a docker image so 00:22:30.708-->00:22:34.042 you get more control over the environment they run and maybe do some more interesting stuff 00:22:34.042-->00:22:39.292 there. If you if you don’t want to use a service provider you can also set up your own. Um you 00:22:39.292-->00:22:43.750 can use this uh docker swarm this function of the service here and you can set up your own 00:22:43.750-->00:22:49.083 kind of similar environment for running functions, scaling it and monitoring what’s going on 00:22:49.083-->00:22:53.458 and that’s the end of my talk uh We’re going to be posting the slides and demo and all that 00:22:53.458-->00:22:58.458 stuff there on my github. Thank you. [Applause]