1 00:00:00,120 --> 00:00:03,600 so next up we have Liv matang uh this is 2 00:00:03,600 --> 00:00:05,359 Liv's first Defcon how about a round of 3 00:00:05,359 --> 00:00:07,360 applause 4 00:00:07,360 --> 00:00:10,120 there 5 00:00:10,120 --> 00:00:13,759 ex how many other people's first time 6 00:00:13,759 --> 00:00:17,160 here look at that that's great 7 00:00:17,160 --> 00:00:20,359 too all right so Liv is a cloud security 8 00:00:20,359 --> 00:00:22,359 researcher at her medic uh where he 9 00:00:22,359 --> 00:00:24,000 specializes an application in web 10 00:00:24,000 --> 00:00:25,920 security uh he previously served in the 11 00:00:25,920 --> 00:00:28,160 8200 intelligence Corps as a software 12 00:00:28,160 --> 00:00:30,759 developer uh and as a bug Hunter Liv has 13 00:00:30,759 --> 00:00:32,040 found several vulnerabilities and 14 00:00:32,040 --> 00:00:34,879 popular software platforms such as Azure 15 00:00:34,879 --> 00:00:37,320 Facebook and gitlab in this talk Liv is 16 00:00:37,320 --> 00:00:38,760 going to show what it's really like 17 00:00:38,760 --> 00:00:40,320 behind the scenes of cloud vulnerability 18 00:00:40,320 --> 00:00:42,239 research and we'll discuss the Lessons 19 00:00:42,239 --> 00:00:43,719 Learned while dealing with the barriers 20 00:00:43,719 --> 00:00:46,000 and challenges that arise when searching 21 00:00:46,000 --> 00:00:48,039 for and Reporting new vulnerabilities to 22 00:00:48,039 --> 00:00:50,079 the biggest cloud lenders so let's give 23 00:00:50,079 --> 00:00:52,480 another warm 24 00:00:52,480 --> 00:00:54,239 welcome thank 25 00:00:54,239 --> 00:00:55,760 you 26 00:00:55,760 --> 00:00:59,600 okay can you hear me good we got it okay 27 00:00:59,600 --> 00:01:02,000 so so this is my talk the rocky Bal guy 28 00:01:02,000 --> 00:01:03,960 to Cloud security 29 00:01:03,960 --> 00:01:06,240 research I'm live Matan a security 30 00:01:06,240 --> 00:01:09,720 researcher attic research team uh I was 31 00:01:09,720 --> 00:01:11,880 also recognized recently as Microsoft 32 00:01:11,880 --> 00:01:14,640 MVR for the past year I'm a bu bounty 33 00:01:14,640 --> 00:01:17,200 hunter in the major Cloud providers and 34 00:01:17,200 --> 00:01:19,280 I also found some cool vulnerabilities 35 00:01:19,280 --> 00:01:21,200 on Facebook and gitlab so make sure to 36 00:01:21,200 --> 00:01:23,000 visit my blog if you're interested in 37 00:01:23,000 --> 00:01:25,159 seeing those and I'm a Former 38 00:01:25,159 --> 00:01:27,200 Intelligence unit software 39 00:01:27,200 --> 00:01:29,560 developer and I was also break dancing 40 00:01:29,560 --> 00:01:31,680 when I was about 16 years old so if you 41 00:01:31,680 --> 00:01:34,000 see me in the dance Flor in Vegas feel 42 00:01:34,000 --> 00:01:37,759 free to eat me up and uh we will 43 00:01:37,759 --> 00:01:41,680 dance okay so our agenda for today I 44 00:01:41,680 --> 00:01:44,159 will give you some unique approaches you 45 00:01:44,159 --> 00:01:47,200 can take for your own experience uh from 46 00:01:47,200 --> 00:01:49,000 my personal experience my honest 47 00:01:49,000 --> 00:01:51,680 experience and when I'm uh saying honest 48 00:01:51,680 --> 00:01:53,640 I mean that I'm going to talk about the 49 00:01:53,640 --> 00:01:56,320 failures and the successes I'm going to 50 00:01:56,320 --> 00:01:58,880 show you some case studies and I hope 51 00:01:58,880 --> 00:02:00,119 you will also learn some some 52 00:02:00,119 --> 00:02:01,920 application security from those case 53 00:02:01,920 --> 00:02:03,799 studies because they are focusing 54 00:02:03,799 --> 00:02:05,759 focusing on application security and 55 00:02:05,759 --> 00:02:08,318 Cloud security um in 56 00:02:08,318 --> 00:02:10,440 correlation I'm also going to give you 57 00:02:10,440 --> 00:02:12,599 some lessons we can learn from our 58 00:02:12,599 --> 00:02:15,200 research uh by showing you the case 59 00:02:15,200 --> 00:02:17,160 studies and I'm going to wrap up by 60 00:02:17,160 --> 00:02:18,720 talking about the experience working 61 00:02:18,720 --> 00:02:20,920 with different csps from my experience 62 00:02:20,920 --> 00:02:24,599 and some takeaways uh you can take home 63 00:02:24,599 --> 00:02:27,200 okay so cloud services we are Cloud 64 00:02:27,200 --> 00:02:30,000 people we all know that right now the 65 00:02:30,000 --> 00:02:32,120 major Cloud providers are offering 66 00:02:32,120 --> 00:02:34,560 hundreds of cloud services and when we 67 00:02:34,560 --> 00:02:36,680 are talking about security research in 68 00:02:36,680 --> 00:02:39,519 the cloud it can be very confusing for 69 00:02:39,519 --> 00:02:43,280 us when we are stumbl upon all of those 70 00:02:43,280 --> 00:02:46,959 services so how would I not get into the 71 00:02:46,959 --> 00:02:49,000 rabbit all of deep diving too much into 72 00:02:49,000 --> 00:02:51,519 my research or how would I even find a 73 00:02:51,519 --> 00:02:53,840 lead a lead to start researching a 74 00:02:53,840 --> 00:02:55,720 service or feature or whatever I want to 75 00:02:55,720 --> 00:02:59,400 research right for this I constructed 76 00:02:59,400 --> 00:03:02,400 those following approaches don't take 77 00:03:02,400 --> 00:03:04,360 those approaches guaranteed they work 78 00:03:04,360 --> 00:03:06,640 for me and we will follow those 79 00:03:06,640 --> 00:03:08,560 approaches with the case studies I will 80 00:03:08,560 --> 00:03:11,040 show you in the next Slide the first one 81 00:03:11,040 --> 00:03:13,159 is find Common Ground between Services 82 00:03:13,159 --> 00:03:14,920 the second one is the opportunistic 83 00:03:14,920 --> 00:03:16,720 approach and the third one is the laser 84 00:03:16,720 --> 00:03:19,120 focus on a service keep in mind that 85 00:03:19,120 --> 00:03:21,080 those approaches can also lead you and 86 00:03:21,080 --> 00:03:23,560 take you to other approaches so feel 87 00:03:23,560 --> 00:03:24,519 free to 88 00:03:24,519 --> 00:03:27,480 Freestyle so the first one includes 89 00:03:27,480 --> 00:03:30,080 interservice communication when looking 90 00:03:30,080 --> 00:03:32,319 at those I found out that those usually 91 00:03:32,319 --> 00:03:33,840 are more prone to 92 00:03:33,840 --> 00:03:36,120 vulnerabilities also looking at some 93 00:03:36,120 --> 00:03:38,319 management panels management panels 94 00:03:38,319 --> 00:03:41,599 usually includes a lot of services 95 00:03:41,599 --> 00:03:43,760 rather than one service we will show you 96 00:03:43,760 --> 00:03:46,959 a a case study on this particular use 97 00:03:46,959 --> 00:03:51,599 case also it usually um lets you get 98 00:03:51,599 --> 00:03:53,360 some vulnerabilities with an higher 99 00:03:53,360 --> 00:03:55,480 impact and a larger blast ruce due to 100 00:03:55,480 --> 00:03:57,920 its nature of the common ground of the a 101 00:03:57,920 --> 00:03:59,840 lot of services that are correlated in 102 00:03:59,840 --> 00:04:02,239 the process the second approach is the 103 00:04:02,239 --> 00:04:03,799 opportunistic one we are taking 104 00:04:03,799 --> 00:04:06,239 advantage of the hundreds of services 105 00:04:06,239 --> 00:04:08,439 that are offered by the cloud providers 106 00:04:08,439 --> 00:04:10,319 we will make a huge recognizance of the 107 00:04:10,319 --> 00:04:12,720 services hop between Services until 108 00:04:12,720 --> 00:04:15,000 something catches our eye and then we 109 00:04:15,000 --> 00:04:17,000 will uh get into the service and try 110 00:04:17,000 --> 00:04:19,680 researching it fter also we can try to 111 00:04:19,680 --> 00:04:21,440 look for some low ending fruits with 112 00:04:21,440 --> 00:04:23,639 this approach the thir approach is the 113 00:04:23,639 --> 00:04:26,000 laser focus on a service and it includes 114 00:04:26,000 --> 00:04:28,000 reading the the documentation of the 115 00:04:28,000 --> 00:04:30,800 service and deep deep diving into the 116 00:04:30,800 --> 00:04:33,160 documentation uh keep in mind that 117 00:04:33,160 --> 00:04:34,479 obviously you will read the 118 00:04:34,479 --> 00:04:36,240 documentation of the service and learn 119 00:04:36,240 --> 00:04:39,400 it in the other approaches also but this 120 00:04:39,400 --> 00:04:42,160 one uh you should focus on it more read 121 00:04:42,160 --> 00:04:44,960 all the features give it a for review of 122 00:04:44,960 --> 00:04:46,560 the features that the service is 123 00:04:46,560 --> 00:04:49,680 offering to um maximize your attack 124 00:04:49,680 --> 00:04:52,360 surface so our first case case study for 125 00:04:52,360 --> 00:04:54,800 today a really exciting one uh from my 126 00:04:54,800 --> 00:04:57,039 personal experience is Emoji deploy 127 00:04:57,039 --> 00:04:59,560 Emoji deploy is a vulnerability I found 128 00:04:59,560 --> 00:05:02,039 found in Azure web services including 129 00:05:02,039 --> 00:05:04,400 function apps app services and logic app 130 00:05:04,400 --> 00:05:06,520 it was an RC that was resulted from a 131 00:05:06,520 --> 00:05:08,759 csrf attack to those of you who are not 132 00:05:08,759 --> 00:05:10,800 familiar with csrf I will give a brief 133 00:05:10,800 --> 00:05:14,479 explanation on it in the next slide so 134 00:05:14,479 --> 00:05:16,560 let's start by observing Azure web 135 00:05:16,560 --> 00:05:18,759 services those can be categorized as 136 00:05:18,759 --> 00:05:21,440 logic apps app service and function apps 137 00:05:21,440 --> 00:05:23,199 I'm sure you all know those Services 138 00:05:23,199 --> 00:05:25,759 those are very popular this is why I 139 00:05:25,759 --> 00:05:27,479 focused on them because I wanted the 140 00:05:27,479 --> 00:05:30,840 impact to be um sufficient and 141 00:05:30,840 --> 00:05:33,080 maximized each one of those Services 142 00:05:33,080 --> 00:05:36,880 deploys the SCM panel this SCM panel is 143 00:05:36,880 --> 00:05:38,919 a management panel that deploys by 144 00:05:38,919 --> 00:05:41,919 default in each of the is deployed by 145 00:05:41,919 --> 00:05:44,240 default in each of those services and it 146 00:05:44,240 --> 00:05:47,000 also deploys the Kudo service this is 147 00:05:47,000 --> 00:05:49,400 the panel this is how it looks 148 00:05:49,400 --> 00:05:51,440 like not very 149 00:05:51,440 --> 00:05:54,160 beautiful so I started by looking I 150 00:05:54,160 --> 00:05:57,520 started by uh looking at the uh panel 151 00:05:57,520 --> 00:06:00,160 see the features features of it it and I 152 00:06:00,160 --> 00:06:02,960 saw uh you can look at some processes 153 00:06:02,960 --> 00:06:05,080 environment variables you can debug the 154 00:06:05,080 --> 00:06:07,919 application and it seems like a good 155 00:06:07,919 --> 00:06:10,560 victim and a good Target to try and 156 00:06:10,560 --> 00:06:12,560 exploit and this is the common ground I 157 00:06:12,560 --> 00:06:15,199 found because this panel is actually 158 00:06:15,199 --> 00:06:17,280 managing all of the services 159 00:06:17,280 --> 00:06:20,440 applications that I just showed you 160 00:06:20,440 --> 00:06:23,479 earlier so I'm starting to look at the 161 00:06:23,479 --> 00:06:27,240 SCM panel I saw something that caught my 162 00:06:27,240 --> 00:06:29,520 eye and this was the same site attribute 163 00:06:29,520 --> 00:06:31,960 of the SCM pel uh the same site 164 00:06:31,960 --> 00:06:34,240 attribute is a browser security feature 165 00:06:34,240 --> 00:06:36,919 that his intention is to protect against 166 00:06:36,919 --> 00:06:39,800 cross origin attacks some of those is a 167 00:06:39,800 --> 00:06:43,000 csrf attack and in this case in the SCM 168 00:06:43,000 --> 00:06:45,039 the same side attribute of the cookies 169 00:06:45,039 --> 00:06:47,360 will all set to none it means that this 170 00:06:47,360 --> 00:06:50,960 protection just wasn't there so a brief 171 00:06:50,960 --> 00:06:53,800 on csrf let's say my lovely grandma 172 00:06:53,800 --> 00:06:56,039 wants to transfer money to me a lovely 173 00:06:56,039 --> 00:06:59,720 grandson so she visits the bank website 174 00:06:59,720 --> 00:07:02,800 uh logs in clicks on a couple of buttons 175 00:07:02,800 --> 00:07:05,000 gets her session cookies then behind the 176 00:07:05,000 --> 00:07:07,080 scenes a post request to the bank's 177 00:07:07,080 --> 00:07:09,360 website will be sent and she will 178 00:07:09,360 --> 00:07:10,960 transfer the money to me and I will be 179 00:07:10,960 --> 00:07:14,120 happy after a couple of days she visits 180 00:07:14,120 --> 00:07:16,319 the attacker's website and the 181 00:07:16,319 --> 00:07:19,520 attacker's websites behind the scene is 182 00:07:19,520 --> 00:07:22,000 sending a post request from the client 183 00:07:22,000 --> 00:07:25,560 side that will send the money from the 184 00:07:25,560 --> 00:07:28,720 Grandma's account to the attacker's 185 00:07:28,720 --> 00:07:31,479 website on herbl because the browser 186 00:07:31,479 --> 00:07:34,280 context was from my Grandma's browser 187 00:07:34,280 --> 00:07:36,360 context the request will be sent on 188 00:07:36,360 --> 00:07:38,960 herbl with her session cookies and also 189 00:07:38,960 --> 00:07:41,120 keep in mind that the origin of the 190 00:07:41,120 --> 00:07:43,400 request the origin HTTP header will be 191 00:07:43,400 --> 00:07:45,639 set automatically by the browser so 192 00:07:45,639 --> 00:07:48,199 servers can potentially look at the 193 00:07:48,199 --> 00:07:51,360 origin and block this csrf 194 00:07:51,360 --> 00:07:53,879 attack okay so our mission for today is 195 00:07:53,879 --> 00:07:56,720 RC and let's get started by defining 196 00:07:56,720 --> 00:08:00,199 origin origin consists of a scheme us 197 00:08:00,199 --> 00:08:02,120 name and Port simple as that just 198 00:08:02,120 --> 00:08:05,919 remember that okay so as said usually 199 00:08:05,919 --> 00:08:08,360 servers can block cross origin attacks 200 00:08:08,360 --> 00:08:12,000 or a csrf attack by checking malformed 201 00:08:12,000 --> 00:08:15,520 Origins and this time I looked at the Cs 202 00:08:15,520 --> 00:08:19,080 the SCM U panel I showed you earlier and 203 00:08:19,080 --> 00:08:21,240 try to see if there is an origin check 204 00:08:21,240 --> 00:08:23,319 because I aim for a cross origin attack 205 00:08:23,319 --> 00:08:26,680 csrf attack and I try to send the normal 206 00:08:26,680 --> 00:08:29,280 origin that will obviously be accepted 207 00:08:29,280 --> 00:08:31,560 then I try to send attacker.com at the 208 00:08:31,560 --> 00:08:33,919 end at the start and try to play with 209 00:08:33,919 --> 00:08:36,839 the protocol just to get a feel of the 210 00:08:36,839 --> 00:08:40,159 server origin check and they all got 211 00:08:40,159 --> 00:08:42,799 unauthorized so it means that there was 212 00:08:42,799 --> 00:08:45,360 a check that there was an origin check 213 00:08:45,360 --> 00:08:47,279 in the SCM side in the server side 214 00:08:47,279 --> 00:08:49,680 trying to block me from accessing 215 00:08:49,680 --> 00:08:52,160 it what about spatial 216 00:08:52,160 --> 00:08:54,959 characters with a blackbox research I 217 00:08:54,959 --> 00:08:57,200 can assume that there was a rits behind 218 00:08:57,200 --> 00:08:59,640 trying to block me from sending 219 00:08:59,640 --> 00:09:01,560 malformed Origins and I I know that 220 00:09:01,560 --> 00:09:04,560 spatial characters can break reg exess 221 00:09:04,560 --> 00:09:07,839 so I sent the following I sent the 222 00:09:07,839 --> 00:09:09,680 accepted origin then the spatial 223 00:09:09,680 --> 00:09:11,560 character for example a dollar and it 224 00:09:11,560 --> 00:09:14,320 got accepted but then I sent the same 225 00:09:14,320 --> 00:09:17,120 with an hyphen and underscore and both 226 00:09:17,120 --> 00:09:19,240 got unauthorized and I didn't know why 227 00:09:19,240 --> 00:09:21,200 because it was a blackbox research but 228 00:09:21,200 --> 00:09:23,200 keep that in mind that the SCM just 229 00:09:23,200 --> 00:09:25,519 doesn't accept those two particular 230 00:09:25,519 --> 00:09:26,760 characters because they are very 231 00:09:26,760 --> 00:09:30,399 important for me in the F so 232 00:09:30,399 --> 00:09:33,200 we tried to check the origin and sending 233 00:09:33,200 --> 00:09:37,079 Mal Origins with a proxy but if we send 234 00:09:37,079 --> 00:09:39,040 it with a browser and domain names do 235 00:09:39,040 --> 00:09:40,720 not allow spatial characters how will 236 00:09:40,720 --> 00:09:42,800 they even register a domain with spatial 237 00:09:42,800 --> 00:09:45,279 characters inside because it should not 238 00:09:45,279 --> 00:09:47,120 be allowed right dollars are not allowed 239 00:09:47,120 --> 00:09:49,560 in domain names so then I went on 240 00:09:49,560 --> 00:09:51,839 researching browsers compatability with 241 00:09:51,839 --> 00:09:54,560 spatial characters and I found out that 242 00:09:54,560 --> 00:09:57,519 actually browsers don't care about 243 00:09:57,519 --> 00:09:59,920 hyphen and underscore in the origin ER 244 00:09:59,920 --> 00:10:01,760 and then just send the request and pass 245 00:10:01,760 --> 00:10:04,839 the origin in the request so I can maybe 246 00:10:04,839 --> 00:10:08,399 try to make a browser send a malform a 247 00:10:08,399 --> 00:10:10,240 request with a malformed origin 248 00:10:10,240 --> 00:10:12,040 containing those special characters that 249 00:10:12,040 --> 00:10:14,760 will allow me to bypass the origin check 250 00:10:14,760 --> 00:10:16,640 but we have a bit of a problem here 251 00:10:16,640 --> 00:10:18,079 because if you're 252 00:10:18,079 --> 00:10:20,399 following right now I have a scenario 253 00:10:20,399 --> 00:10:22,680 that browsers accept the hyphen and 254 00:10:22,680 --> 00:10:25,720 underscore but the SC regex doesn't like 255 00:10:25,720 --> 00:10:29,120 them and the opposite browsers do not 256 00:10:29,120 --> 00:10:30,640 accept any other special characters and 257 00:10:30,640 --> 00:10:32,800 the STM regx accept 258 00:10:32,800 --> 00:10:35,160 those so I went on and tried the 259 00:10:35,160 --> 00:10:37,839 following I tried inputting underscore 260 00:10:37,839 --> 00:10:40,639 as a subdomain and both got accepted and 261 00:10:40,639 --> 00:10:42,519 I could bypass it the browsers and the 262 00:10:42,519 --> 00:10:44,639 SCM server both accept underscore as a 263 00:10:44,639 --> 00:10:47,600 subdomain and the SCM server was pwned 264 00:10:47,600 --> 00:10:50,160 by an emoji this is the name of the 265 00:10:50,160 --> 00:10:52,560 vulnerability Emoji deploy this is the 266 00:10:52,560 --> 00:10:56,519 cross origin bypass I had and now we 267 00:10:56,519 --> 00:10:59,639 will get into the deploy part 268 00:10:59,639 --> 00:11:02,839 so thank 269 00:11:03,920 --> 00:11:06,880 you so at this point we can now Force 270 00:11:06,880 --> 00:11:09,120 authenticated victims to do something in 271 00:11:09,120 --> 00:11:12,600 their SCM panel from our origin our 272 00:11:12,600 --> 00:11:15,519 attacker origin so let's try and find 273 00:11:15,519 --> 00:11:17,279 the vulnerable endpoint we need impact 274 00:11:17,279 --> 00:11:19,600 we need something to exploit right so 275 00:11:19,600 --> 00:11:22,279 the server is using the Kudo service the 276 00:11:22,279 --> 00:11:25,240 Kudo service is open source as I just 277 00:11:25,240 --> 00:11:27,200 searched the internet and looked and it 278 00:11:27,200 --> 00:11:29,880 was open source and open source is kind 279 00:11:29,880 --> 00:11:31,560 of fun for attackers because I can read 280 00:11:31,560 --> 00:11:34,000 a code and I can try to look for 281 00:11:34,000 --> 00:11:35,320 vulnerable 282 00:11:35,320 --> 00:11:38,160 endpoints so a candidate for the day 283 00:11:38,160 --> 00:11:39,760 where denial of service but we will 284 00:11:39,760 --> 00:11:42,480 focus on also the remote code execution 285 00:11:42,480 --> 00:11:44,639 that will maximize our impact the remote 286 00:11:44,639 --> 00:11:47,800 code execution had an API zip deploy uh 287 00:11:47,800 --> 00:11:50,519 endpoint the zip deploy is an endpoint 288 00:11:50,519 --> 00:11:53,040 that Microsoft has implemented for um 289 00:11:53,040 --> 00:11:56,160 devops and it usage to deploy Zips to uh 290 00:11:56,160 --> 00:11:58,639 applications through the SCM panel so 291 00:11:58,639 --> 00:12:00,079 through the the SCM panel you make a 292 00:12:00,079 --> 00:12:01,720 request and the zip will be deployed to 293 00:12:01,720 --> 00:12:04,079 the application and the interesting part 294 00:12:04,079 --> 00:12:07,320 here that the zip package will unpack at 295 00:12:07,320 --> 00:12:09,720 the Dome site dub dub dub route of the 296 00:12:09,720 --> 00:12:12,079 application so let's for example we have 297 00:12:12,079 --> 00:12:14,639 app service that is a website in uh 298 00:12:14,639 --> 00:12:17,920 Azure the zip package from the SCM will 299 00:12:17,920 --> 00:12:21,600 unpack in the uh app Service 300 00:12:21,600 --> 00:12:24,560 website so maybe I can try to abuse it 301 00:12:24,560 --> 00:12:26,399 and upload a 302 00:12:26,399 --> 00:12:29,399 webshell so mission complete 303 00:12:29,399 --> 00:12:31,519 this is our recap victim visits a 304 00:12:31,519 --> 00:12:34,120 malicious website the attacker uploads 305 00:12:34,120 --> 00:12:36,199 malicious zip file through the file 306 00:12:36,199 --> 00:12:38,480 through the victim's browser the 307 00:12:38,480 --> 00:12:40,399 malicious zip file will unpack with the 308 00:12:40,399 --> 00:12:42,399 malicious code happens to be a webshell 309 00:12:42,399 --> 00:12:44,160 so webshell to those of you who don't 310 00:12:44,160 --> 00:12:45,800 know I can just control the website and 311 00:12:45,800 --> 00:12:50,760 run code on it and we got a one click RC 312 00:12:50,760 --> 00:12:53,360 on all of those Services through the 313 00:12:53,360 --> 00:12:56,480 Common Ground I showed you I also have a 314 00:12:56,480 --> 00:12:59,279 cool pre-recorded demo for you so have 315 00:12:59,279 --> 00:13:01,839 fun watching 316 00:13:07,120 --> 00:13:11,279 it so the victim's empty web rout you 317 00:13:11,279 --> 00:13:14,000 can see there was no webshell nothing 318 00:13:14,000 --> 00:13:17,920 there there will be 319 00:13:17,920 --> 00:13:22,319 spoiler this is the API Z deploy 320 00:13:23,440 --> 00:13:25,440 endpoint that I 321 00:13:25,440 --> 00:13:28,279 abused this is the function uh of the 322 00:13:28,279 --> 00:13:30,800 JavaScript code that I set on my website 323 00:13:30,800 --> 00:13:33,639 in order to upload the zip to the 324 00:13:33,639 --> 00:13:36,040 victim's uh application from my website 325 00:13:36,040 --> 00:13:38,480 it's a cross orig attack this is the 326 00:13:38,480 --> 00:13:43,399 webshell I uploaded ASX web shell. net 327 00:13:45,000 --> 00:13:47,639 application and this is my website that 328 00:13:47,639 --> 00:13:50,079 contains the uh the malformed origin 329 00:13:50,079 --> 00:13:52,480 that will bypass the origin check the 330 00:13:52,480 --> 00:13:54,279 cookies will be transferred the cookies 331 00:13:54,279 --> 00:13:55,839 of the victim because the same site 332 00:13:55,839 --> 00:13:59,360 attribute were all set to none 333 00:13:59,360 --> 00:14:01,759 the content type uh it's another thing 334 00:14:01,759 --> 00:14:03,800 that I didn't have time to explain here 335 00:14:03,800 --> 00:14:05,839 but feel free to visit my blog for the 336 00:14:05,839 --> 00:14:09,320 full technical details and the 337 00:14:09,320 --> 00:14:12,440 bypasses and the victim has visited our 338 00:14:12,440 --> 00:14:15,040 website the webshell has been uploaded 339 00:14:15,040 --> 00:14:16,880 and now the attacker can go and run 340 00:14:16,880 --> 00:14:19,519 commands on the victim's website or 341 00:14:19,519 --> 00:14:21,839 application the interesting part here 342 00:14:21,839 --> 00:14:23,959 that the attacker can also extract the 343 00:14:23,959 --> 00:14:27,800 victim's managed identity token and this 344 00:14:27,800 --> 00:14:31,120 managed identity Tok token is used in 345 00:14:31,120 --> 00:14:34,519 sorry is used in those services in order 346 00:14:34,519 --> 00:14:37,040 to interact to let the services interact 347 00:14:37,040 --> 00:14:38,959 with other services in the cloud and 348 00:14:38,959 --> 00:14:41,040 usually websit say we all know interact 349 00:14:41,040 --> 00:14:43,880 let's for example databases so the 350 00:14:43,880 --> 00:14:45,959 attacker can potentially also laterally 351 00:14:45,959 --> 00:14:48,399 move to other services like databases by 352 00:14:48,399 --> 00:14:50,759 extracting the manage identity token and 353 00:14:50,759 --> 00:14:54,519 use it so our next case study is the 354 00:14:54,519 --> 00:14:56,959 opportunistic approach we said we have a 355 00:14:56,959 --> 00:14:58,360 lot of approaches one of those is the 356 00:14:58,360 --> 00:15:02,040 opport istic one um showing you and 357 00:15:02,040 --> 00:15:04,120 showing you a Cas three case studies on 358 00:15:04,120 --> 00:15:07,600 AWS Cloud shell one of those was uh 359 00:15:07,600 --> 00:15:09,160 resulting from a public caching 360 00:15:09,160 --> 00:15:12,720 opportunity that led me for uh two xss 361 00:15:12,720 --> 00:15:15,160 on AWS console and the cloud shell 362 00:15:15,160 --> 00:15:17,800 subdomain and also a case study on one 363 00:15:17,800 --> 00:15:20,320 click Cloud shell o of token leak and 364 00:15:20,320 --> 00:15:22,920 the exchange of the token failed and I 365 00:15:22,920 --> 00:15:25,279 uh told you that I will also share the 366 00:15:25,279 --> 00:15:28,800 failures and uh we will see what what 367 00:15:28,800 --> 00:15:31,440 can we learn from them okay so sorry I 368 00:15:31,440 --> 00:15:33,759 have to 369 00:15:39,800 --> 00:15:43,759 drink okay so AWS Cloud shell caching 370 00:15:43,759 --> 00:15:47,079 mechanism so I started by looking at AWS 371 00:15:47,079 --> 00:15:49,519 Cloud shell and I saw that it had a 372 00:15:49,519 --> 00:15:52,800 public cache and in my attack R I 373 00:15:52,800 --> 00:15:55,959 thought to myself maybe I can abuse this 374 00:15:55,959 --> 00:15:59,120 public cash with a cash poisoning 375 00:15:59,120 --> 00:16:01,360 cash poisoning means that I can abuse 376 00:16:01,360 --> 00:16:04,319 the shared public cash between users by 377 00:16:04,319 --> 00:16:07,240 forcing the server to return me a 378 00:16:07,240 --> 00:16:10,040 malicious uh response and this response 379 00:16:10,040 --> 00:16:12,399 will be publicly cached and returned to 380 00:16:12,399 --> 00:16:14,600 other users but then I saw the very 381 00:16:14,600 --> 00:16:16,360 cookie header that means that the 382 00:16:16,360 --> 00:16:18,120 response will be cached only in 383 00:16:18,120 --> 00:16:22,040 correlation with the cookie so my cash 384 00:16:22,040 --> 00:16:23,720 my cash response will not be the same as 385 00:16:23,720 --> 00:16:25,560 the victim's cash response so it was 386 00:16:25,560 --> 00:16:29,480 fail but it led me to uh finding two xss 387 00:16:29,480 --> 00:16:31,920 on AWS so it wasn't that 388 00:16:31,920 --> 00:16:34,720 bad so we start by looking at the post 389 00:16:34,720 --> 00:16:36,360 message communication and you don't need 390 00:16:36,360 --> 00:16:38,199 to know much about it but the only thing 391 00:16:38,199 --> 00:16:40,600 that you need to know is that the window 392 00:16:40,600 --> 00:16:43,519 of cloudshell and the window of AWS 393 00:16:43,519 --> 00:16:46,440 console are the windows are 394 00:16:46,440 --> 00:16:48,839 communicating um with a post message 395 00:16:48,839 --> 00:16:51,480 communication and this post Mage message 396 00:16:51,480 --> 00:16:53,480 communication allows you to communicate 397 00:16:53,480 --> 00:16:56,399 between Windows and those domains are 398 00:16:56,399 --> 00:16:58,600 using get parameters to indicate to 399 00:16:58,600 --> 00:17:02,279 which domain to send the post message 400 00:17:02,279 --> 00:17:06,640 to so when looking at this feature 401 00:17:06,640 --> 00:17:08,559 something really caught my eye after 402 00:17:08,559 --> 00:17:10,199 looking at the public cach I tried to 403 00:17:10,199 --> 00:17:12,559 find a malicious uh input from the 404 00:17:12,559 --> 00:17:14,919 response to be reflected to other users 405 00:17:14,919 --> 00:17:18,559 and be cached and I found this parameter 406 00:17:18,559 --> 00:17:20,760 the parent origin this is the parameter 407 00:17:20,760 --> 00:17:23,000 that indicating to uh which domain to 408 00:17:23,000 --> 00:17:25,839 send the post message uh post message 409 00:17:25,839 --> 00:17:28,160 request as I said earlier and I saw that 410 00:17:28,160 --> 00:17:30,000 there is a reflection from my user input 411 00:17:30,000 --> 00:17:33,559 to the D of the web page and with that I 412 00:17:33,559 --> 00:17:36,559 tried to inject quotation marks and the 413 00:17:36,559 --> 00:17:39,160 wall hey just to test the reflection and 414 00:17:39,160 --> 00:17:41,840 I saw that I could actually break out 415 00:17:41,840 --> 00:17:43,799 out of the attribute the content 416 00:17:43,799 --> 00:17:46,200 attribute of the metatag and inject some 417 00:17:46,200 --> 00:17:49,840 weird stuff but I had some obstacles 418 00:17:49,840 --> 00:17:51,799 those were the parent origin injectable 419 00:17:51,799 --> 00:17:53,919 parameter was a URL so it was quite 420 00:17:53,919 --> 00:17:57,799 strict because um AWS was expecting a 421 00:17:57,799 --> 00:17:59,760 URL and URL cannot have spatial 422 00:17:59,760 --> 00:18:02,640 characters and stuff um also no spaces 423 00:18:02,640 --> 00:18:05,400 were allowed and no slashes were allowed 424 00:18:05,400 --> 00:18:08,159 so my ideas were use slashes instead 425 00:18:08,159 --> 00:18:10,520 instead of space bar but no slashes were 426 00:18:10,520 --> 00:18:13,880 allowed another idea was use uh 427 00:18:13,880 --> 00:18:16,720 percentage zc a URL encoded forfeit 428 00:18:16,720 --> 00:18:19,640 character that the browser will treat as 429 00:18:19,640 --> 00:18:23,000 a space bar and this was a success I 430 00:18:23,000 --> 00:18:26,120 injected the following and I got a 431 00:18:26,120 --> 00:18:28,799 pretty cool xss a simple one uh image 432 00:18:28,799 --> 00:18:31,280 source equals X and on error will pop an 433 00:18:31,280 --> 00:18:35,480 alert just for a PC but it wasn't wasn't 434 00:18:35,480 --> 00:18:37,559 that easy 435 00:18:37,559 --> 00:18:42,159 because AWS Cloud shell had a CSP and 436 00:18:42,159 --> 00:18:45,200 you might you might think CSP AWS Cloud 437 00:18:45,200 --> 00:18:47,919 shell as a cloud service provider no it 438 00:18:47,919 --> 00:18:50,320 has a Content security policy content 439 00:18:50,320 --> 00:18:52,760 secur security policy is a browser 440 00:18:52,760 --> 00:18:55,720 mechanisms mechanism that allows users 441 00:18:55,720 --> 00:18:58,880 to restrict their JavaScript environment 442 00:18:58,880 --> 00:19:02,080 in the browser and also maybe block xss 443 00:19:02,080 --> 00:19:06,480 attacks so at this time they had a CSP 444 00:19:06,480 --> 00:19:08,919 the CSP can be returned as response 445 00:19:08,919 --> 00:19:12,159 heads in the server or just as a meta 446 00:19:12,159 --> 00:19:14,280 tag in the D this time it was in the 447 00:19:14,280 --> 00:19:16,840 response head us so I looked at the CSP 448 00:19:16,840 --> 00:19:21,039 and saw that there is a frame ancestors 449 00:19:21,039 --> 00:19:24,320 directive that was set to none and as I 450 00:19:24,320 --> 00:19:27,080 know that the feature is implemented by 451 00:19:27,080 --> 00:19:30,159 post messages from the window of the 452 00:19:30,159 --> 00:19:32,840 cloud shell main domain to the subdomain 453 00:19:32,840 --> 00:19:36,360 of cloud shell and when they are 454 00:19:36,360 --> 00:19:39,440 communicating the it happens by if 455 00:19:39,440 --> 00:19:42,000 framing by the main domain iframing the 456 00:19:42,000 --> 00:19:44,640 subdomain of cloud shell so I was 457 00:19:44,640 --> 00:19:47,400 expecting to see the subdomain of cloud 458 00:19:47,400 --> 00:19:49,679 shell or the main 459 00:19:49,679 --> 00:19:52,640 origin then I had a bypass 460 00:19:52,640 --> 00:19:57,120 idea maybe try to inject the following I 461 00:19:57,120 --> 00:20:01,080 can maybe try to input some malicious 462 00:20:01,080 --> 00:20:03,760 special CSP directives that will allow 463 00:20:03,760 --> 00:20:08,320 me to bypass the CSP so my bypass idea 464 00:20:08,320 --> 00:20:11,520 was this I injected the following two 465 00:20:11,520 --> 00:20:14,520 spatial CSP directives that GTI uh as 466 00:20:14,520 --> 00:20:16,480 discovered that can override other CSP 467 00:20:16,480 --> 00:20:19,720 directives and the xss together and I 468 00:20:19,720 --> 00:20:22,799 got blocked again it was failed uh it 469 00:20:22,799 --> 00:20:24,720 was failed because the browser was 470 00:20:24,720 --> 00:20:27,039 telling me that spatial characters are 471 00:20:27,039 --> 00:20:29,840 not allowed in a c p and the server 472 00:20:29,840 --> 00:20:31,880 there was parsing the forfeit character 473 00:20:31,880 --> 00:20:33,840 I injected earlier in the response 474 00:20:33,840 --> 00:20:36,480 headers different that than he was 475 00:20:36,480 --> 00:20:39,559 parsing it in the body of the response 476 00:20:39,559 --> 00:20:43,039 this is why the the Brer was just seeing 477 00:20:43,039 --> 00:20:44,880 the F fit character as a literal form 478 00:20:44,880 --> 00:20:47,120 feed character and not as a decoded for 479 00:20:47,120 --> 00:20:48,840 feed character that the browser will 480 00:20:48,840 --> 00:20:51,679 treat as a space bar so a recap on the 481 00:20:51,679 --> 00:20:54,679 xss ex on cloud shell subdomain and CSP 482 00:20:54,679 --> 00:20:56,520 bypass attempt 483 00:20:56,520 --> 00:21:00,240 fail and another main domain accss on 484 00:21:00,240 --> 00:21:02,240 the main domain a different CSP script 485 00:21:02,240 --> 00:21:04,679 or shahash we don't have enough on 486 00:21:04,679 --> 00:21:07,919 enough time so I will just um make a 487 00:21:07,919 --> 00:21:11,120 blitz on it so this is me fighting 488 00:21:11,120 --> 00:21:16,000 awps script s hash gas the script Source 489 00:21:16,000 --> 00:21:19,360 hash uh is basically matching a script 490 00:21:19,360 --> 00:21:22,120 content to a hash if there is no match 491 00:21:22,120 --> 00:21:23,880 then the script just won't run this is a 492 00:21:23,880 --> 00:21:26,559 CSP feature AWS use the dynamic hash 493 00:21:26,559 --> 00:21:29,039 generation the hash is generated also 494 00:21:29,039 --> 00:21:31,640 from my injected script so there will be 495 00:21:31,640 --> 00:21:34,480 a match and the xss will be executed so 496 00:21:34,480 --> 00:21:37,279 another xss after another uh a lot of 497 00:21:37,279 --> 00:21:39,120 bypass attempts I came up with this 498 00:21:39,120 --> 00:21:41,880 payload of arithmetic operations uh but 499 00:21:41,880 --> 00:21:44,640 when talking about impact this CSP also 500 00:21:44,640 --> 00:21:47,799 had a Sandbox and this sandbox wasn't 501 00:21:47,799 --> 00:21:52,080 allowing me a lot of impact so 502 00:21:52,080 --> 00:21:55,039 unfortunate another case study of AWS 503 00:21:55,039 --> 00:21:57,320 Cloud shell of token leak continuing to 504 00:21:57,320 --> 00:22:00,520 research aw Cloud shell and the cloud 505 00:22:00,520 --> 00:22:03,039 shell authentication works as follows 506 00:22:03,039 --> 00:22:05,039 the STS can be omitted the only 507 00:22:05,039 --> 00:22:07,000 authentication that works here is 508 00:22:07,000 --> 00:22:10,039 session cookies of the user so the user 509 00:22:10,039 --> 00:22:12,799 is visiting Cloud subdomain then in 510 00:22:12,799 --> 00:22:16,080 return he gets uh the script embedding 511 00:22:16,080 --> 00:22:19,480 to the off subdomain and it gets uh in 512 00:22:19,480 --> 00:22:22,279 return a dynamic callback JavaScript 513 00:22:22,279 --> 00:22:24,520 that contains the sensitive of token of 514 00:22:24,520 --> 00:22:27,279 the user the the session token this is 515 00:22:27,279 --> 00:22:30,080 the script this is how it looks like and 516 00:22:30,080 --> 00:22:31,720 the red flag here is that scripts are 517 00:22:31,720 --> 00:22:34,080 allowed cross origin origin a can embed 518 00:22:34,080 --> 00:22:36,880 script from other Origins how much time 519 00:22:36,880 --> 00:22:39,440 do I have 520 00:22:40,000 --> 00:22:43,400 sorry about 10 521 00:22:43,400 --> 00:22:45,679 okay 522 00:22:45,679 --> 00:22:48,840 so the attacker's opportunity here is to 523 00:22:48,840 --> 00:22:52,240 lure victims into his website Force the 524 00:22:52,240 --> 00:22:54,240 cloud shell authentication through the 525 00:22:54,240 --> 00:22:57,360 script embedding then gets in return the 526 00:22:57,360 --> 00:23:00,480 call back JS script in return to the 527 00:23:00,480 --> 00:23:02,640 cookies of the victim out cross origin 528 00:23:02,640 --> 00:23:05,279 attack but how would I 529 00:23:05,279 --> 00:23:08,960 read the session token of the victim 530 00:23:08,960 --> 00:23:10,679 with JavaScript because the function 531 00:23:10,679 --> 00:23:13,080 here doesn't have a name so I had to try 532 00:23:13,080 --> 00:23:16,240 and abuse it with some logic bypasses 533 00:23:16,240 --> 00:23:18,240 and I came up with a prototype pollution 534 00:23:18,240 --> 00:23:20,720 bypass this is the Breakthrough because 535 00:23:20,720 --> 00:23:24,320 I can um because I control the website 536 00:23:24,320 --> 00:23:25,960 and it a cross origin attack I can 537 00:23:25,960 --> 00:23:28,640 prototype poll pollute uh the nsy 538 00:23:28,640 --> 00:23:30,840 function and bypass the origin check 539 00:23:30,840 --> 00:23:33,039 that was on the JavaScript and also hook 540 00:23:33,039 --> 00:23:35,000 the post post message function to fetch 541 00:23:35,000 --> 00:23:37,360 the code to me another pre-recorded demo 542 00:23:37,360 --> 00:23:40,919 but we don't have time so uh there was 543 00:23:40,919 --> 00:23:43,400 another disappointment here because AWS 544 00:23:43,400 --> 00:23:46,400 actually had an i layer that restricted 545 00:23:46,400 --> 00:23:49,159 me from exchanging the stolen token and 546 00:23:49,159 --> 00:23:51,760 this is an internal guardwell I layer 547 00:23:51,760 --> 00:23:54,279 that I found out that AWS had on cloud 548 00:23:54,279 --> 00:23:58,200 shell AWS also didn't fix this uh um 549 00:23:58,200 --> 00:24:00,360 bypass because they said it's not a 550 00:24:00,360 --> 00:24:03,120 security concern and it requires user 551 00:24:03,120 --> 00:24:06,360 interaction one click so this is a recap 552 00:24:06,360 --> 00:24:08,640 for the leak so lessons we learned about 553 00:24:08,640 --> 00:24:10,640 Cloud shell internals we learned that 554 00:24:10,640 --> 00:24:12,960 one layer of security is Never Enough 555 00:24:12,960 --> 00:24:15,240 xss CSP and prototype pollution 556 00:24:15,240 --> 00:24:17,279 technicalities and internals we learned 557 00:24:17,279 --> 00:24:20,400 a lot about them and the thing about one 558 00:24:20,400 --> 00:24:22,320 layer of security is Never Enough is a 559 00:24:22,320 --> 00:24:24,640 really cool lesson because if the IM 560 00:24:24,640 --> 00:24:26,840 layer just wasn't there I could override 561 00:24:26,840 --> 00:24:29,440 victims cloud sessions with just one 562 00:24:29,440 --> 00:24:32,640 click so time 563 00:24:32,640 --> 00:24:36,240 sorry seconds okay so our next case 564 00:24:36,240 --> 00:24:38,240 study and the last one is laser focus on 565 00:24:38,240 --> 00:24:40,760 a service uncovering free Azure API 566 00:24:40,760 --> 00:24:43,240 management vulnerabilities we'll focus 567 00:24:43,240 --> 00:24:45,559 on just one vulnerability and this is an 568 00:24:45,559 --> 00:24:49,360 ssrf one an interesting backstory here 569 00:24:49,360 --> 00:24:51,919 that teached me a lot about reporting 570 00:24:51,919 --> 00:24:54,520 vulnerabilities in bug bounties is that 571 00:24:54,520 --> 00:24:56,480 this vulnerability was first reported to 572 00:24:56,480 --> 00:24:59,200 Microsoft by another Cloud security uh 573 00:24:59,200 --> 00:25:01,520 company after a couple of days it was 574 00:25:01,520 --> 00:25:05,080 fixed by Microsoft after a month we 575 00:25:05,080 --> 00:25:07,679 reported our findings and after another 576 00:25:07,679 --> 00:25:10,960 month we saw that the blog post of the 577 00:25:10,960 --> 00:25:12,440 cloud of the other Cloud security 578 00:25:12,440 --> 00:25:15,840 company was posted and we saw that they 579 00:25:15,840 --> 00:25:18,399 posted the vulnerability we reported but 580 00:25:18,399 --> 00:25:20,320 then I tried to reproduce my 581 00:25:20,320 --> 00:25:23,760 vulnerability and it was still there so 582 00:25:23,760 --> 00:25:25,320 it was actually a bypass to the 583 00:25:25,320 --> 00:25:27,000 vulnerability the other Cloud security 584 00:25:27,000 --> 00:25:28,240 company 585 00:25:28,240 --> 00:25:29,960 um 586 00:25:29,960 --> 00:25:31,960 reported so the thing that got my 587 00:25:31,960 --> 00:25:34,039 attention is this feature of azure that 588 00:25:34,039 --> 00:25:36,120 lets users retrieve schemas from 589 00:25:36,120 --> 00:25:38,559 external resources and this is how it 590 00:25:38,559 --> 00:25:40,840 looks like behind the scenes it it uh 591 00:25:40,840 --> 00:25:43,399 was sent through an HTTP Eder and I 592 00:25:43,399 --> 00:25:46,080 tried to send Local Host to try to force 593 00:25:46,080 --> 00:25:48,000 the server into sending a request to 594 00:25:48,000 --> 00:25:49,760 Local Host and returning me the response 595 00:25:49,760 --> 00:25:53,360 an ssrf and I got forbidden then I tried 596 00:25:53,360 --> 00:25:56,080 to send local test. me it's a domain 597 00:25:56,080 --> 00:25:59,159 with a dnsa record to the local IP 598 00:25:59,159 --> 00:26:01,320 address and I got not found means I 599 00:26:01,320 --> 00:26:04,640 bypassed the protection that was 600 00:26:04,640 --> 00:26:06,840 there then I tried to access some 601 00:26:06,840 --> 00:26:10,120 internal services in some ports for 602 00:26:10,120 --> 00:26:15,320 example 30 300 3,000 Etc and it all got 603 00:26:15,320 --> 00:26:17,520 forbidden so I found out that there was 604 00:26:17,520 --> 00:26:19,840 a regx as another defense layer on the 605 00:26:19,840 --> 00:26:23,440 server and this regx was specially and 606 00:26:23,440 --> 00:26:25,760 specifically for those ports so means 607 00:26:25,760 --> 00:26:28,240 that they might contain some internal 608 00:26:28,240 --> 00:26:30,640 services that Microsoft just don't want 609 00:26:30,640 --> 00:26:34,039 me to see so the main bypass was from 610 00:26:34,039 --> 00:26:37,120 the Azure portal we input our redirect 611 00:26:37,120 --> 00:26:39,480 server our external redirect server will 612 00:26:39,480 --> 00:26:41,360 obviously want blocked because it's 613 00:26:41,360 --> 00:26:43,399 redirect server that Microsoft just 614 00:26:43,399 --> 00:26:45,880 don't care about our redirect server 615 00:26:45,880 --> 00:26:48,240 will forward U the request from the 616 00:26:48,240 --> 00:26:49,840 course proxy that is sending a request 617 00:26:49,840 --> 00:26:52,080 behind the scenes to the internal 618 00:26:52,080 --> 00:26:55,679 services and we got a bypass we could 619 00:26:55,679 --> 00:26:57,919 access internal Services all also we 620 00:26:57,919 --> 00:26:59,720 could access the API and management Kudo 621 00:26:59,720 --> 00:27:02,159 server that now you know the Kudo server 622 00:27:02,159 --> 00:27:04,000 and what is capable 623 00:27:04,000 --> 00:27:07,120 of uh after the Emoji deplo example but 624 00:27:07,120 --> 00:27:08,760 the interesting thing here that I tried 625 00:27:08,760 --> 00:27:11,360 to access imds 626 00:27:11,360 --> 00:27:14,039 and I got blocked because of the X4 that 627 00:27:14,039 --> 00:27:16,080 for header that is preventing me from 628 00:27:16,080 --> 00:27:18,600 accessing it but it led me to a research 629 00:27:18,600 --> 00:27:20,799 on MDS security that I presented at the 630 00:27:20,799 --> 00:27:24,799 latest for cloudsec um conference and 631 00:27:24,799 --> 00:27:26,320 there are more blogs to come so we 632 00:27:26,320 --> 00:27:29,640 learned something from it and also we 633 00:27:29,640 --> 00:27:31,279 learned a lot about the API management 634 00:27:31,279 --> 00:27:34,760 reach features because I um followed the 635 00:27:34,760 --> 00:27:36,919 approach of reading all the features and 636 00:27:36,919 --> 00:27:39,039 trying to learn about the service and 637 00:27:39,039 --> 00:27:41,519 also I learned that the CSP MDS x44 638 00:27:41,519 --> 00:27:43,840 header protection is influential and it 639 00:27:43,840 --> 00:27:46,480 blocked me from accessing the 640 00:27:46,480 --> 00:27:49,000 imds we'll wrap up by speaking about the 641 00:27:49,000 --> 00:27:50,519 experience working with different Cloud 642 00:27:50,519 --> 00:27:53,480 providers about fixing vulnerabilities 643 00:27:53,480 --> 00:27:55,960 as we saw some Cloud providers prefer to 644 00:27:55,960 --> 00:28:00,080 fix uh vulnerabilities and bypasses that 645 00:28:00,080 --> 00:28:05,240 might not um wreck a lot of impact but 646 00:28:05,240 --> 00:28:07,159 they will in the future because an 647 00:28:07,159 --> 00:28:09,240 attacker could possibly bypass the other 648 00:28:09,240 --> 00:28:12,760 layers and some just prefer to fix those 649 00:28:12,760 --> 00:28:14,919 about bounties Cloud providers have a 650 00:28:14,919 --> 00:28:18,039 lot of B bu Bounty programs and uh we as 651 00:28:18,039 --> 00:28:20,120 a community encourage those bu Bounty 652 00:28:20,120 --> 00:28:22,679 programs and they encourage Us in 653 00:28:22,679 --> 00:28:24,799 return about the openness with the 654 00:28:24,799 --> 00:28:26,640 community I found out that some Cloud 655 00:28:26,640 --> 00:28:28,600 providers actually to avoid publications 656 00:28:28,600 --> 00:28:30,919 of vulnerabilities and some Cloud 657 00:28:30,919 --> 00:28:33,519 providers are very open and I really 658 00:28:33,519 --> 00:28:35,880 encourage it because it can prevent 659 00:28:35,880 --> 00:28:38,640 breaches in the long term about the time 660 00:28:38,640 --> 00:28:41,240 to answer all the cloud providers were 661 00:28:41,240 --> 00:28:44,200 really fast with uh in regards to 662 00:28:44,200 --> 00:28:46,720 answering reports and it also in Works 663 00:28:46,720 --> 00:28:48,399 in correlation with the security team 664 00:28:48,399 --> 00:28:51,960 size so takeaways non impactful research 665 00:28:51,960 --> 00:28:53,600 can lead you to many interesting places 666 00:28:53,600 --> 00:28:55,720 Embrace losses don't be afraid to try 667 00:28:55,720 --> 00:28:58,200 silly ideas and the cloud ility research 668 00:28:58,200 --> 00:29:02,640 all is different so take care thank you 669 00:29:07,480 --> 00:29:10,480 guys I didn't have 670 00:29:10,480 --> 00:29:12,559 time thank you if anyone has any 671 00:29:12,559 --> 00:29:14,799 questions you want to meet outside yeah 672 00:29:14,799 --> 00:29:16,279 you can meet me outside if you have 673 00:29:16,279 --> 00:29:17,960 question question thanks so much for 674 00:29:17,960 --> 00:29:20,679 coming folks