WEBVTT 0:00:03.380000 --> 0:00:06.360000 Hello everyone and welcome to this video. 0:00:06.360000 --> 0:00:10.460000 In this video we're going to be building on what we covered in the previous 0:00:10.460000 --> 0:00:16.080000 video where we, you know, gotten an introduction into identifying the 0:00:16.080000 --> 0:00:23.640000 WSDL file and obviously enumerating operations or methods to be used or 0:00:23.640000 --> 0:00:29.220000 that can be used legitimately with the actual SOAP web service. 0:00:29.220000 --> 0:00:32.280000 So we're pretty much just going to be continuing from where we left off 0:00:32.280000 --> 0:00:38.760000 from and as I mentioned the previous video and all consequent or subsequent 0:00:38.760000 --> 0:00:43.100000 videos within this section will all be utilizing the same lab. 0:00:43.100000 --> 0:00:46.380000 So you can resume from your previous session if that's where you're picking 0:00:46.380000 --> 0:00:48.220000 this video up from. 0:00:48.220000 --> 0:00:49.400000 It really doesn't matter. 0:00:49.400000 --> 0:00:53.200000 I'm now going to be walking you through the process of invoking hidden 0:00:53.200000 --> 0:00:59.020000 methods and you know there's quite a bit of interesting stuff that I want 0:00:59.020000 --> 0:01:00.540000 to highlight here. 0:01:00.540000 --> 0:01:04.500000 Firstly of course make sure if you don't have your lab environment started 0:01:04.500000 --> 0:01:10.260000 that you do. This video is tied to that single lab within this section 0:01:10.260000 --> 0:01:14.820000 of the course. The name of the lab is just called web services and I'm 0:01:14.820000 --> 0:01:18.440000 going to go back into my lab environment and we will resume. 0:01:18.440000 --> 0:01:23.740000 So with that being said I will be seeing you within the lab environment. 0:01:23.740000 --> 0:01:30.420000 All right so I am back within the lab environment and as you can see the 0:01:30.420000 --> 0:01:34.520000 target URL is still demo.ini.local. 0:01:34.520000 --> 0:01:38.960000 I've opened up my web browser and again we'll just go to web services, 0:01:38.960000 --> 0:01:50.940000 SOAP and what I wanted to point out in this video is that these are the 0:01:50.940000 --> 0:01:57.520000 authorized operations or methods that the web developer has in this particular 0:01:57.520000 --> 0:02:01.800000 case Mutillity has listed them as listed them out for us. 0:02:01.800000 --> 0:02:08.660000 But these are not everything or these methods here or operations do not 0:02:08.660000 --> 0:02:10.580000 represent everything we can do. 0:02:10.580000 --> 0:02:17.060000 So the point is that while web developers may release even within the 0:02:17.060000 --> 0:02:23.020000 WSTL information about the authorized operations they'll not tell you 0:02:23.020000 --> 0:02:28.780000 everything okay because take for example just took it what this endpoint 0:02:28.780000 --> 0:02:35.200000 does okay. This web service endpoint gets user information it allows you 0:02:35.200000 --> 0:02:39.380000 to create a new user and allows you to update a user. 0:02:39.380000 --> 0:02:46.940000 Now when it comes down to invoking hidden methods or operations the best 0:02:46.940000 --> 0:02:52.340000 way you can do this if nothing is specified within the WSTL file is to 0:02:52.340000 --> 0:02:59.660000 just by taking a look at the authorized methods infer given the naming 0:02:59.660000 --> 0:03:05.460000 schema here or the naming structure what some other methods might be like. 0:03:05.460000 --> 0:03:07.260000 What do I mean by this? 0:03:07.260000 --> 0:03:12.860000 If I was performing a test on this particular SOAP web service endpoint 0:03:12.860000 --> 0:03:20.880000 and I saw get user create user update user I it would be safe to assume 0:03:20.880000 --> 0:03:27.280000 that I can also delete a user but what you might be running into is the 0:03:27.280000 --> 0:03:32.020000 fact that this that particular operation or method might not be defined 0:03:32.020000 --> 0:03:36.160000 or publicly disclosed through even the WSTL. 0:03:36.160000 --> 0:03:40.300000 So the point is that just based on the functionality we had seen in the 0:03:40.300000 --> 0:03:45.240000 WSTL with regards to HTTP communication and the fact that this particular 0:03:45.240000 --> 0:03:50.980000 in the case of get user requires you to utilize a post we can take what 0:03:50.980000 --> 0:03:56.840000 we had in the previous video for and essentially copy the get user example 0:03:56.840000 --> 0:04:03.360000 request of course modify it accordingly and now try and see whether we 0:04:03.360000 --> 0:04:08.960000 can invoke some hidden or some private operations that might not be documented 0:04:08.960000 --> 0:04:16.060000 publicly and again we infer these hidden operations by just taking a look 0:04:16.060000 --> 0:04:25.160000 at the functionality of the to sort of get an understanding as to what 0:04:25.160000 --> 0:04:31.140000 could be some other operation names and based on that I will perform what 0:04:31.140000 --> 0:04:35.780000 I usually try and perform which is the delete user operation. 0:04:35.780000 --> 0:04:40.380000 Now this operation might not exist but that's why it's called web service 0:04:40.380000 --> 0:04:46.460000 security testing because this might this is just the logic of an attacker 0:04:46.460000 --> 0:04:50.140000 they want to try and see you know what else this web service will allow 0:04:50.140000 --> 0:04:54.560000 you to do because trust me even though this is a vulnerable deliberately 0:04:54.560000 --> 0:04:59.420000 vulnerable web service this particular functionality is something that 0:04:59.420000 --> 0:05:03.980000 you will find and what I'm showing you here is an you know is an actual 0:05:03.980000 --> 0:05:09.100000 vulnerability so based on what we covered in the previous video we know 0:05:09.100000 --> 0:05:15.880000 that right over here this particular this particular request on the endpoint 0:05:15.880000 --> 0:05:23.160000 WST web service user account.php requires you to pass in a parameter in 0:05:23.160000 --> 0:05:28.320000 the form of a string the name of the parameter is called username and 0:05:28.320000 --> 0:05:33.780000 we just passed it we just pass it in in text form right away or as a string 0:05:33.780000 --> 0:05:38.060000 which means it's not going to accept use IDs so we can actually do this 0:05:38.060000 --> 0:05:42.940000 as a test we'll try one or zero which would normally be the admin or the 0:05:42.940000 --> 0:05:47.980000 root we'll send this over and let's take a look at it here it tells us 0:05:47.980000 --> 0:05:52.440000 user one does not exist so I'm almost certain that this particular web 0:05:52.440000 --> 0:05:57.260000 service endpoint is interacting with the database and this output is really 0:05:57.260000 --> 0:06:01.940000 bugging me or not bugging me but getting me more excited but that's not 0:06:01.940000 --> 0:06:06.320000 what I wanted to highlight so we know that the user Jeremy exists right 0:06:06.320000 --> 0:06:12.780000 so based on the what was included in the actual sample what I'll do here 0:06:12.780000 --> 0:06:17.680000 is I'll just put in Jeremy again just to see if he exists right because 0:06:17.680000 --> 0:06:23.420000 we need a valid user to test what I'm about to test so let's send and 0:06:23.420000 --> 0:06:28.980000 we can see interesting Jeremy does not exist that's very strange is it 0:06:28.980000 --> 0:06:33.720000 could this be because of the formatting let's see so I'm just going to 0:06:33.720000 --> 0:06:41.880000 undo what I did previously and now I'll just say Jeremy like so and hit 0:06:41.880000 --> 0:06:45.980000 send that could be because of formatting there we are so we know Jeremy 0:06:45.980000 --> 0:06:51.240000 exists now what if we want to try and delete Jeremy well in essence what 0:06:51.240000 --> 0:07:05.960000 I can try and do is just use a then they could possibly be a operation 0:07:05.960000 --> 0:07:11.680000 or method called delete user okay now we still don't know whether it requires 0:07:11.680000 --> 0:07:16.460000 any additional information in order for us to delete a user but we firstly 0:07:16.460000 --> 0:07:20.280000 don't know whether this particular operation even exists the only way 0:07:20.280000 --> 0:07:24.660000 we'll know is by testing so I can say delete user and remember we need 0:07:24.660000 --> 0:07:28.840000 to ensure that this is highlighted here in the element opening and closing 0:07:28.840000 --> 0:07:34.240000 tags so I'll say delete user over here and look for any other instantiations 0:07:34.240000 --> 0:07:42.480000 of get user again not in the actual HTTP request headers because that's 0:07:42.480000 --> 0:07:47.460000 really not going to make a difference here and I'm just going to hit send 0:07:47.460000 --> 0:07:51.340000 so we know the username Jeremy is valid I'm just going to hit send so 0:07:51.340000 --> 0:07:59.740000 first things first when we specify or when we try and utilize an operation 0:07:59.740000 --> 0:08:06.000000 or method that does not exist okay again I'll repeat that that does not 0:08:06.000000 --> 0:08:15.380000 exist the web service will typically respond with a 500 or 401 or an pretty 0:08:15.380000 --> 0:08:23.760000 much a status code that or your request was incorrect now if it does respond 0:08:23.760000 --> 0:08:29.060000 with the 200 it means it most likely means that that operation exists 0:08:29.060000 --> 0:08:34.140000 okay so let's take a look at the response if we take a look at the response 0:08:34.140000 --> 0:08:42.200000 here we can see that we get something very interesting firstly we actually 0:08:42.200000 --> 0:08:48.620000 get official confirmation that the delete user method or operation exists 0:08:48.620000 --> 0:08:55.280000 because there is a namespace here within the body that says delete user 0:08:55.280000 --> 0:09:02.320000 response which means if there is a an operation request format or schema 0:09:02.320000 --> 0:09:08.860000 there must be a response format or schema to handle responses made by 0:09:08.860000 --> 0:09:15.380000 a particular operation or method and in this case there is so it tells 0:09:15.380000 --> 0:09:22.280000 us right over here exception line 267 code 0 file and it points towards 0:09:22.280000 --> 0:09:27.680000 this particular endpoint and the message is parameter required and we 0:09:27.680000 --> 0:09:31.300000 actually get an error telling us let's see whether we can decipher this 0:09:31.300000 --> 0:09:34.780000 yeah so this just tells us that there's an error within the actual web 0:09:34.780000 --> 0:09:40.280000 service and that's because it's missing a parameter okay and this is one 0:09:40.280000 --> 0:09:46.720000 of the one of the issues here when trying to invoke hidden or private 0:09:46.720000 --> 0:09:51.520000 operations or methods is you don't know what additional parameters are 0:09:51.520000 --> 0:09:58.600000 required within the request now needless to say if you had enumerated 0:09:58.600000 --> 0:10:04.120000 or gone through the wsdl file you would have seen that this particular 0:10:04.120000 --> 0:10:11.820000 operation or method delete user does indeed exist or is listed within 0:10:11.820000 --> 0:10:17.340000 the wsdl file okay now why didn't i show you this in the first place well 0:10:17.340000 --> 0:10:22.000000 firstly i wanted to see whether you'd find it yourself and secondly because 0:10:22.000000 --> 0:10:26.880000 this is a vulnerable web service it has listed them all over here typically 0:10:26.880000 --> 0:10:33.400000 speaking web application developers will not expose the methods or the 0:10:33.400000 --> 0:10:38.280000 operations that they would not like the general public to use okay so 0:10:38.280000 --> 0:10:42.720000 it's very important that you keep this in mind so if we go right over 0:10:42.720000 --> 0:10:47.840000 here to the bottom we can see a few other hidden ones and we can see the 0:10:47.840000 --> 0:10:52.860000 operation name is equal to delete you it exists all right so the way it 0:10:52.860000 --> 0:10:58.220000 works is simple if the account exists delete the user account included 0:10:58.220000 --> 0:11:03.580000 as a string which we know how you know we know how this works right and 0:11:03.580000 --> 0:11:07.380000 in this case the really cool thing is that you know based on what the 0:11:07.380000 --> 0:11:11.720000 web application developer exposed just on the end point we saw that they 0:11:11.720000 --> 0:11:16.580000 did not highlight that as a as an operation that you know you should be 0:11:16.580000 --> 0:11:21.100000 playing around with and we can understand why now but what i want to focus 0:11:21.100000 --> 0:11:26.860000 on is the actual parameters required okay so if we take a look at the 0:11:26.860000 --> 0:11:33.960000 parameters required here we can see let's see whether we can see anything 0:11:33.960000 --> 0:11:41.700000 interesting here okay so username we know how to specify that there but 0:11:41.700000 --> 0:11:46.940000 after that it looks like we also need to specify a password with the same 0:11:46.940000 --> 0:11:51.320000 type which in this case has been html encoded you can easily decode this 0:11:51.320000 --> 0:11:55.440000 so again by the way just to show you if you want to decipher this if it's 0:11:55.440000 --> 0:12:00.800000 not being rendered for you i'll just copy this here i'm going to um but 0:12:00.800000 --> 0:12:06.080000 so eat into the decoder and i'll paste this in here and i'll say decode 0:12:06.080000 --> 0:12:13.560000 as uh html so there we are so um that'll get rid of any html encoding 0:12:13.560000 --> 0:12:19.520000 so you can now see what needs to be put in the actual request what we're 0:12:19.520000 --> 0:12:26.120000 interested in is the xml here and uh we can see right over here so yeah 0:12:26.120000 --> 0:12:30.260000 after username after the username parameter we also need to specify the 0:12:30.260000 --> 0:12:35.960000 password parameter and it also provides the options for that so delete 0:12:35.960000 --> 0:12:41.060000 user um actually there we are password so just the password element or 0:12:41.060000 --> 0:12:47.300000 parameter needs to be specified so we and in this case very interesting 0:12:47.300000 --> 0:12:52.720000 it says the password is holy very interesting of course we'll test this 0:12:52.720000 --> 0:12:57.080000 out without the actual password but we'll go into proxy actually into 0:12:57.080000 --> 0:13:02.980000 the repeater and we'll add that right over here so based on what was specified 0:13:02.980000 --> 0:13:10.400000 here what we need to do is create the password parameter or element if 0:13:10.400000 --> 0:13:15.100000 you will that then allows us to pass in a password so password this is 0:13:15.100000 --> 0:13:21.000000 just going to match um the the same format or the type for the username 0:13:21.000000 --> 0:13:29.080000 which is just xsi type and that's going to be equal to xsd string like 0:13:29.080000 --> 0:13:32.980000 so and we'll close the opening tag we then need to close it just like 0:13:32.980000 --> 0:13:37.760000 html when we'll just say password right over here so you can see that 0:13:37.760000 --> 0:13:42.140000 this is not that complicated to understand and in here we would then provide 0:13:42.140000 --> 0:13:47.380000 the password now this brings up a potential problem we don't know the 0:13:47.380000 --> 0:13:51.660000 password for the user geremy and when we try and get the information only 0:13:51.660000 --> 0:13:55.760000 their signature is displayed we don't get their password which is good 0:13:55.760000 --> 0:14:01.180000 it means there is some form of security in place here um and based on 0:14:01.180000 --> 0:14:07.100000 what is exposed publicly this is actually the basis for a very simple 0:14:07.100000 --> 0:14:14.100000 uh user account management functionality where you can utilize this particular 0:14:14.100000 --> 0:14:18.560000 operation to get user information so if you were to incorporate it into 0:14:18.560000 --> 0:14:22.860000 a web application when someone clicked on this it could essentially make 0:14:22.860000 --> 0:14:29.200000 this uh particular post request to get the username that may be predefined 0:14:29.200000 --> 0:14:34.540000 or picked from a session id or any form of identification maybe a session 0:14:34.540000 --> 0:14:39.000000 identifier and would then you know display that user's information or 0:14:39.000000 --> 0:14:43.880000 their user profile that would contain their signature uh then create user 0:14:43.880000 --> 0:14:48.260000 would be a registration form uh if you were to implement it in a web application 0:14:48.260000 --> 0:14:52.540000 and then utilize the web service for the actual facilitation or processing 0:14:52.540000 --> 0:14:58.920000 of the um of the actual post request here so I know that this is not the 0:14:58.920000 --> 0:15:02.740000 correct implementation of a web service but you could use it this way 0:15:02.740000 --> 0:15:09.200000 and as I was saying this sets up the basis for um you know pretty much 0:15:09.200000 --> 0:15:14.460000 the base of a user management or profile management or content management 0:15:14.460000 --> 0:15:17.500000 system for that matter pretty much any web application that allows you 0:15:17.500000 --> 0:15:22.060000 to create an account update your password and you know maybe display your 0:15:22.060000 --> 0:15:28.640000 profile page so as I was saying this uh poses a problem we don't know 0:15:28.640000 --> 0:15:33.460000 what the password is but we still need to test and see whether now we 0:15:33.460000 --> 0:15:38.040000 uh do not get a parameter is required message so I'm going to send this 0:15:38.040000 --> 0:15:43.200000 over and you can see we still get a response a 200 okay response that 0:15:43.200000 --> 0:15:48.680000 says right over here fantastic this is exactly what I live for so under 0:15:48.680000 --> 0:15:56.880000 the parameter or element called accounts it says message could not authenticate 0:15:56.880000 --> 0:16:02.500000 account Jeremy password incorrect now I don't know whether you're seeing 0:16:02.500000 --> 0:16:08.420000 what I'm seeing it's taking the username value or the value of the username 0:16:08.420000 --> 0:16:14.380000 parameter and it's using it in output okay and the way it's being displayed 0:16:14.380000 --> 0:16:19.460000 here looks very interesting because we can see that uh this is being treated 0:16:19.460000 --> 0:16:25.300000 as a string and uh the possibility that we can break this is very very 0:16:25.300000 --> 0:16:28.900000 easy at this point so for example if I used a string delimiter like a 0:16:28.900000 --> 0:16:35.080000 single quote after Jeremy let's see what happens when we do this so there 0:16:35.080000 --> 0:16:41.220000 we are we get a MySQL handler error and that confirms what I'd pointed 0:16:41.220000 --> 0:16:46.640000 out earlier that this web service or that endpoint is interacting with 0:16:46.640000 --> 0:16:52.660000 the MySQL database and based on what we've gotten here this is error based 0:16:52.660000 --> 0:16:56.600000 SQL injection because it's telling us it's confirming that you know MySQL 0:16:56.600000 --> 0:17:02.220000 is running and actually gives us the query that was used now I'm getting 0:17:02.220000 --> 0:17:05.640000 ahead of myself we're going to cover that in the next video but you know 0:17:05.640000 --> 0:17:11.840000 just taking a look at how even data is parsed in the response will tell 0:17:11.840000 --> 0:17:16.400000 you a lot about you know a particular web service and in particular in 0:17:16.400000 --> 0:17:22.000000 this case a uh an operation or a method and you know how it works and 0:17:22.000000 --> 0:17:28.480000 how the response is parsed so the bottom line is we need uh the password 0:17:28.480000 --> 0:17:32.000000 in order for this to work and uh you know this is posing us a significant 0:17:32.000000 --> 0:17:37.500000 problem here of course and what we're going to do now is let's take a 0:17:37.500000 --> 0:17:43.780000 look at maybe one more uh one more hidden method or operation to see if 0:17:43.780000 --> 0:17:49.160000 that works and I know we saw quite a bit or quite a few in the WSDL file 0:17:49.160000 --> 0:17:55.480000 here so we know uh if we go to the operations we have create user update 0:17:55.480000 --> 0:18:01.680000 user and we have a very interesting one here called um uh let's see if 0:18:01.680000 --> 0:18:08.240000 I can find it uh get admin info there we are so this uh this particular 0:18:08.240000 --> 0:18:12.940000 operation works as follows if the account for admin exists returns in 0:18:12.940000 --> 0:18:17.140000 non-sensitive account details okay so yeah that's a little bit of a bummer 0:18:17.140000 --> 0:18:23.040000 but you know there might be some more here let's see um okay yeah so this 0:18:23.040000 --> 0:18:29.940000 is where we have the actual uh um we have the actual bindings here so 0:18:29.940000 --> 0:18:36.020000 that's fine um what we're looking for is the actual operations and uh 0:18:36.020000 --> 0:18:39.800000 why not let's try and see whether this will work um and whether you know 0:18:39.800000 --> 0:18:43.220000 there might be some protection behind this so obviously this particular 0:18:43.220000 --> 0:18:47.860000 operation should not have been exposed within the WSDL which is a tip 0:18:47.860000 --> 0:18:53.240000 for you API developers out there um and uh oh it's very interesting it 0:18:53.240000 --> 0:18:58.820000 says try harder here what's this about this is update user okay so yeah 0:18:58.820000 --> 0:19:03.940000 you know we can um we will need a valid password in order to update a 0:19:03.940000 --> 0:19:09.540000 user so we can try that out yet but if we try the get admin info operation 0:19:09.540000 --> 0:19:14.720000 let's see how this works in terms of we so we can see you know it's a 0:19:14.720000 --> 0:19:20.720000 needs to be a post and in terms of the other information we we actually 0:19:20.720000 --> 0:19:26.420000 get the the format that needs to be specified here so you know um we pretty 0:19:26.420000 --> 0:19:31.640000 much just copy the sample request and put it into the burp suite repeater 0:19:31.640000 --> 0:19:37.520000 so uh in order for us to do this we can uh go into burp suite here and 0:19:37.520000 --> 0:19:43.220000 um we need to go into the decoder and i'm just going to delete that one 0:19:43.220000 --> 0:19:48.420000 there and we're then going to decode this as the html so we don't want 0:19:48.420000 --> 0:19:53.600000 any html and coding actually hold on that's uh that's not deco oh yeah 0:19:53.600000 --> 0:19:57.060000 sorry there we are i'm getting confused here so i'm going to copy this 0:19:57.060000 --> 0:20:00.900000 and i'm just going to put it into a text editor to see whether it's formatted 0:20:00.900000 --> 0:20:05.760000 correctly and indeed it's not so we would then need to from this point 0:20:05.760000 --> 0:20:12.700000 um you know get rid of tags like br or break and then um you know just 0:20:12.700000 --> 0:20:17.160000 structure it put the correct headers in in reality the only thing we need 0:20:17.160000 --> 0:20:22.600000 is the actual xml code right over here so soap environment uh there we 0:20:22.600000 --> 0:20:27.700000 are so from this point that's all we need and in this particular case 0:20:27.700000 --> 0:20:34.460000 formatting this is fairly simple um you know we can just put in um this 0:20:34.460000 --> 0:20:41.720000 right over here and uh you know we can follow the same format so and um 0:20:41.720000 --> 0:20:49.020000 right over here uh let's see where does that tag begin so the soap environment 0:20:49.020000 --> 0:20:54.160000 and then we can leave that as is get rid of the break tag right over here 0:20:54.160000 --> 0:20:57.720000 and i'm just showing you how you can do this manually because that info 0:20:57.720000 --> 0:21:03.140000 is already contained um soap environment body so fairly simple in terms 0:21:03.140000 --> 0:21:08.280000 of the you know the br tag in html and also xml is used to break the line 0:21:08.280000 --> 0:21:13.660000 uh to move to a next line so let's see how we can utilize just as a final 0:21:13.660000 --> 0:21:19.660000 example how we can utilize that get admin info operation or method so 0:21:19.660000 --> 0:21:25.220000 based on what was listed um the end point is still the same we'll utilize 0:21:25.220000 --> 0:21:29.580000 the original request here and uh we pretty much just need to get of uh 0:21:29.580000 --> 0:21:34.580000 get rid of everything in the body so specifically the delete use operation 0:21:34.580000 --> 0:21:41.580000 and uh we'll get rid of it like so and then um within the body we can 0:21:41.580000 --> 0:21:47.700000 then include uh what we had copied specific line here and that is get 0:21:47.700000 --> 0:21:53.880000 admin info so the actual operation here so get admin info um and then 0:21:53.880000 --> 0:21:58.980000 that would contain the actual schema and uh we just need the uh in fact 0:21:58.980000 --> 0:22:03.280000 i'll just copy it and we'll modify it in there within um the repeater 0:22:03.280000 --> 0:22:07.500000 so i'll just paste it in here and fantastic burp so it does it for us 0:22:07.500000 --> 0:22:14.260000 excellent but yeah this needs to go this needs to go the break uh the 0:22:14.260000 --> 0:22:17.940000 br tags need to go because they're not really relevant in this particular 0:22:17.940000 --> 0:22:25.000000 case so there we are um let's see we have two envelopes here and two tags 0:22:25.000000 --> 0:22:29.780000 so these need to go as well because i copied them by mistake and uh yeah 0:22:29.780000 --> 0:22:33.960000 this is uh pretty much uh all that we need to do here so we'll get rid 0:22:33.960000 --> 0:22:38.420000 of all spaces because we don't know how this works so we've now you know 0:22:38.420000 --> 0:22:44.940000 added uh or we're trying to utilize that hidden method and um the only 0:22:44.940000 --> 0:22:50.520000 way uh to know uh the success here is just going to be to send this so 0:22:50.520000 --> 0:22:55.620000 when we send this there we are so we get a 500 internal error now this 0:22:55.620000 --> 0:23:01.000000 does not necessarily mean that this operation does not exist it may mean 0:23:01.000000 --> 0:23:06.400000 that the specification of the operation within the actual element was 0:23:06.400000 --> 0:23:11.800000 incorrect what does this mean let's take a look at uh the error so it 0:23:11.800000 --> 0:23:17.440000 says over here only admin user can invoke this method so what this tells 0:23:17.440000 --> 0:23:29.540000 me is that we have some form of the successor to XML RPC as i highlighted 0:23:29.540000 --> 0:23:36.980000 in the earlier section in a within this course soap has a few um security 0:23:36.980000 --> 0:23:45.000000 features like body restrictions that can be implemented through uh through 0:23:45.000000 --> 0:23:52.120000 uh HTTP headers okay so basically in this particular case the best way 0:23:52.120000 --> 0:23:57.060000 to highlight this is to bring up some documentation on one particular 0:23:57.060000 --> 0:24:01.400000 header that i want you to uh you to be familiar with and that's going 0:24:01.400000 --> 0:24:07.240000 to be the soap action header all right so the the bottom line is that 0:24:07.240000 --> 0:24:10.720000 they it looks like there's a restriction here because of the 500 error 0:24:10.720000 --> 0:24:15.420000 it's not pointing towards an improper implementation of the actual operation 0:24:15.420000 --> 0:24:22.200000 it's possibly a restriction of the get admin info operation or method 0:24:22.200000 --> 0:24:29.260000 okay so in essence the soap action header is a you know transport protocol 0:24:29.260000 --> 0:24:34.780000 header either in HTTP um and is transmitted with soap messages and provides 0:24:34.780000 --> 0:24:39.240000 information about the intention of the web service request to the actual 0:24:39.240000 --> 0:24:44.860000 service and the WSDL interface for a web service defines the soap action 0:24:44.860000 --> 0:24:51.300000 header value used for each operation um in some cases some web service 0:24:51.300000 --> 0:24:57.840000 implementations utilize soap action header to determine behavior and that's 0:24:57.840000 --> 0:25:02.080000 really the most important thing that you need to be aware of right so 0:25:02.080000 --> 0:25:09.140000 the bottom line is if we go in this should have been highlighted in the 0:25:09.140000 --> 0:25:16.880000 WSDL file if we go in here remember under the actual operation specifically 0:25:16.880000 --> 0:25:23.220000 under if we go right over here um let's see if i can just scroll to it 0:25:23.220000 --> 0:25:29.860000 it's scrolling too fast um so yeah this is the input the output here we 0:25:29.860000 --> 0:25:36.580000 can see is uh you know is just get admin info response which is what we 0:25:36.580000 --> 0:25:42.060000 got but we want the output so if we go to the binding here and we take 0:25:42.060000 --> 0:25:46.660000 a look at the outputs sorry the input and output and we take a look at 0:25:46.660000 --> 0:25:50.980000 that particular operation which should be actually highlighted here so 0:25:50.980000 --> 0:25:56.420000 get admin info there we are we can see soap operation soap action okay 0:25:56.420000 --> 0:26:02.800000 so in this case the soap action header controls how this works so in this 0:26:02.800000 --> 0:26:06.900000 case for that particular operation we can see the soap operation soap 0:26:06.900000 --> 0:26:16.280000 action is equal to urn uh web service user account get admin info okay 0:26:16.280000 --> 0:26:23.880000 so pretty much what's going on here if i um to expand this here what's 0:26:23.880000 --> 0:26:29.360000 going on here is we need to specify the soap action header because it's 0:26:29.360000 --> 0:26:35.460000 required to perform the soap operation and the way to include this is 0:26:35.460000 --> 0:26:42.260000 as an HTTP header and we then need to specify uh this specification here 0:26:42.260000 --> 0:26:47.900000 so the attribute soap action header is specified and then in here um the 0:26:47.900000 --> 0:26:52.800000 value of the attribute is going to be just urn uh this is what we need 0:26:52.800000 --> 0:26:59.120000 to copy right over here okay and um because it's a header we actually 0:26:59.120000 --> 0:27:12.360000 don't need soap action and we will then paste in what we copied right 0:27:12.360000 --> 0:27:19.280000 over here and now based on how this web service works uh we can actually 0:27:19.280000 --> 0:27:36.060000 i'll actually cover what exactly is going on after we see what we need 0:27:36.060000 --> 0:27:42.620000 to include this information here within the the actual um within the actual 0:27:42.620000 --> 0:27:47.600000 body of the request but let's see what happens now okay so i'll send this 0:27:47.600000 --> 0:27:53.740000 we still get a 500 internal error and in this case that's because uh we 0:27:53.740000 --> 0:27:59.900000 are specifying in um in this particular case all of this additional info 0:27:59.900000 --> 0:28:05.600000 so what we want to do is uh pretty much just get rid of everything inside 0:28:05.600000 --> 0:28:12.180000 the envelope um so that includes uh this right over here so the head and 0:28:12.180000 --> 0:28:19.940000 and the body and i'll then hit send if we hit send we get a 200 okay and 0:28:19.940000 --> 0:28:26.600000 now we get the username and uh we get the username for the admin user 0:28:26.600000 --> 0:28:32.740000 which is just admin the signature is got root and we also have a flag 0:28:32.740000 --> 0:28:36.740000 value here so we've gotten the second flag i'm assuming we'll get the 0:28:36.740000 --> 0:28:41.220000 first flag in the next video but uh that laughs something to do with input 0:28:41.220000 --> 0:28:46.840000 validation vulnerability so yeah that's how we would get the um in essence 0:28:46.840000 --> 0:28:50.680000 this is how we would get the um the admin info or how we would invoke 0:28:50.680000 --> 0:28:57.440000 this hidden method um or method without proper documentation so if we 0:28:57.440000 --> 0:29:03.100000 actually go back in here and uh i'll explain what soap action does but 0:29:03.100000 --> 0:29:09.440000 if we go to the actual documentation for get admin let's see if i can 0:29:09.440000 --> 0:29:22.800000 find it so return an insensitive um account details okay now there is 0:29:22.800000 --> 0:29:29.040000 no it appears to be no error handling but if we go to the actual uh to 0:29:29.040000 --> 0:29:34.460000 the actual bindings um and i hope you remember what bindings are i'll 0:29:34.460000 --> 0:29:37.600000 give you a couple of seconds to recall because i know you must have forgotten 0:29:37.600000 --> 0:29:41.900000 that already not again not that there's anything wrong with that it's 0:29:41.900000 --> 0:29:48.120000 always good to reiterate or to reanalyze this stuff uh but the the binding 0:29:48.120000 --> 0:29:52.520000 just is just used to specify the protocol and the data format for each 0:29:52.520000 --> 0:29:58.620000 particular port type so that's really all that uh it is um it is referring 0:29:58.620000 --> 0:30:05.120000 to so just keep that in mind it's very very important that you do uh going 0:30:05.120000 --> 0:30:10.720000 back to the soap action header what i was talking about is why it is why 0:30:10.720000 --> 0:30:14.100000 and how it's implemented and you know primarily for what reason right 0:30:14.100000 --> 0:30:21.720000 so if we take a look at the bindings and we go to um let's see uh soap 0:30:21.720000 --> 0:30:28.020000 action so let's get user create user update user get admin info uh the 0:30:28.020000 --> 0:30:34.820000 soap action uh right over here points towards so we have the name of the 0:30:34.820000 --> 0:30:39.560000 operation the soap operation equals soap action and that's going to be 0:30:39.560000 --> 0:30:48.080000 uRN um web service user account uh get admin info um let's see what exactly 0:30:48.080000 --> 0:30:54.320000 is going on here so the actual use case of the soap action header will 0:30:54.320000 --> 0:30:59.080000 tell us a lot about what's going on here so in essence uh when you make 0:30:59.080000 --> 0:31:03.400000 a web service in vocation specifically operation in vocation the soap 0:31:03.400000 --> 0:31:10.660000 action header is set um in the outgoing soap um message during the actual 0:31:10.660000 --> 0:31:16.080000 request right now if it's not set manually or automatically then there's 0:31:16.080000 --> 0:31:19.880000 going to be an issue but going back to its definition the soap action 0:31:19.880000 --> 0:31:24.240000 header is uh you know a transport protocol header and is transmitted with 0:31:24.240000 --> 0:31:28.260000 soap messages and pretty much provides information about the intention 0:31:28.260000 --> 0:31:35.680000 of the web service request to the wstl interface for the web service defines 0:31:35.680000 --> 0:31:43.240000 the soap action header value used for each operation and um as i pointed 0:31:43.240000 --> 0:31:48.780000 out earlier some web service implementations utilize the soap action header 0:31:48.780000 --> 0:32:02.380000 to determine behavior okay so that's the behavior we're interested in 0:32:02.380000 --> 0:32:09.340000 is required if it includes uh the soap action uh and a parameter value 0:32:09.340000 --> 0:32:17.440000 in the actual um in the actual binding specification so the point is that 0:32:17.440000 --> 0:32:22.780000 in this particular case there was a check as part of this uh as part of 0:32:22.780000 --> 0:32:32.820000 motelides um challenge there was a check to see whether you the point 0:32:32.820000 --> 0:32:39.020000 is the the learning here is around the bindings okay and specifically 0:32:39.020000 --> 0:32:45.020000 around soap action or soap headers that need to be specified in order 0:32:45.020000 --> 0:32:48.760000 for anything in this case restricted to be displayed that was the lesson 0:32:48.760000 --> 0:32:55.080000 so the ultimate lesson from my end is always go through the wstl file 0:32:55.080000 --> 0:33:00.720000 if available as uh comprehensively as you can and try and understand what 0:33:00.720000 --> 0:33:09.120000 exactly is going on what um what uh what binding uh what bindings are 0:33:09.120000 --> 0:33:16.060000 are specified or are set or defined for operations so on and so forth 0:33:16.060000 --> 0:33:23.320000 okay so if we take a look at the input here for this but for this particular 0:33:23.320000 --> 0:33:29.800000 operation you can see that soap body utilize encoded namespace is web 0:33:29.800000 --> 0:33:35.680000 service user account encoding style etc and then the output is just display 0:33:35.680000 --> 0:33:41.280000 the user inform actually no that's yeah it displays the user information 0:33:41.280000 --> 0:33:47.360000 plus a little bit more but ultimately the key thing here is pay attention 0:33:47.360000 --> 0:33:54.100000 to the to the actual bindings here for each operation in terms of additional 0:33:54.100000 --> 0:34:00.220000 uh additional headers that need to be specified uh ultimately if this 0:34:00.220000 --> 0:34:06.640000 exists here if soap action is specified within the uh binding for the 0:34:06.640000 --> 0:34:12.160000 actual operation ensure that you add the parameter value here or the parameter 0:34:12.160000 --> 0:34:18.360000 specified as a header in order to avoid future issues so in this case 0:34:18.360000 --> 0:34:22.240000 is not really a vulnerability within the web service itself and its functionality 0:34:22.240000 --> 0:34:27.020000 or the operation it's more so uh it was testing to see whether you're 0:34:27.020000 --> 0:34:33.000000 able to to essentially infer that from the wstl so we've covered quite 0:34:33.000000 --> 0:34:37.100000 a lot and we were able to discover a potential vulnerability that we will 0:34:37.100000 --> 0:34:41.600000 then be exploring in the next video so that is going to conclude the practical 0:34:41.600000 --> 0:34:48.940000 demonstration side of this video all right so that was quite a lot of 0:34:48.940000 --> 0:34:55.240000 uh practice or practical activity empirical activity i think i call it 0:34:55.240000 --> 0:35:07.080000 myself and hopefully you're able to learn a little bit more about the 0:35:07.080000 --> 0:35:11.460000 or issue it's time to start testing for those vulnerabilities to see whether 0:35:11.460000 --> 0:35:16.080000 we can get some results and with that being said that's going to be it