Instructor: Analyzing Web Applications. 2 2
In this lesson, we're going to go through 3 3
a couple of different ways to look at web applications. 4 4
We're going to use Nikto, which is a vulnerability scanner. 5 5
We're going to use Burp Suite, which is an interception proxy, 6 6
and we're even going to go through and look 7 7
at some SQL injections and some hands-on injections. 8 8
So let's go ahead and get started. 9 9
What I'm going to do first is jump into my lab environment 10 10
and we're going to start with Nikto. 11 11
As I said, Nikto is a web application vulnerability scanner. 12 12
If you think about Nessus and Qualys and things like that, 13 13
those are used against your infrastructure servers, 14 14
routers, switches, and hosts. 15 15
But if you want to look at a web application in-depth, 16 16
you really want to use something like Nikto. 17 17
So you're going to go into your terminal 18 18
and you're going to run the command nikto -host 19 19
and the IP of the host you're trying to scan. 20 20
In my case, it's 10.1.0.10. 21 21
Now, once you do that, 22 22
you're going to see some of the issues that were found. 23 23
For instance, you can see on this first line 24 24
that the server is an Apache 2.4.6 server 25 25
being run on CentOS. 26 26
Now as you go through, you can see there are 27 27
some anti-clickjacking options that are not present. 28 28
You can see some cross-site 29 29
scripting protection headers are not defined. 30 30
You can see some X-Content-Type-Options is not set, 31 31
and as you go down, 32 32
you're going to see all the different vulnerabilities. 33 33
As you get even further down, 34 34
you're going to see things that say OSVDB, 35 35
which are some vulnerability database files 36 36
that are going to tell you exactly what was tested. 37 37
So you could see that under 877, 38 38
there is an HTTP TRACE method that is activated, 39 39
and this suggests that the host is vulnerable to an attack. 40 40
And so as you go through, 41 41
you can identify each of these different things, 42 42
and then you can look them up, research them, 43 43
and figure out how to solve those issues. 44 44
Now the next thing we want to do is test our website 45 45
and look at it from a probing perspective 46 46
for directories and files. 47 47
We can do this using a different plugin inside of Nikto. 48 48
So I'm going to use nikto -host 10.1.0.10 -plugins, 49 49
and then the plugin I want to use, 50 50
in my case, it's going to be a dictionary 51 51
under dictionary:/usr/share/wordlists/dirb/common.txt. 52 52
When I do that, I'm going to be able to run a scan 53 53
for common file and directory names on that server. 54 54
Next, let's run a command to find any files 55 55
that require authorization to view. 56 56
I can do this by using nikto -host 10.1.0.10 -display 57 57
and the number 4. 58 58
Note, this will show me 59 59
all of the files that are now identified 60 60
that would've required authorization to view. 61 61
The next thing I want to do is try to perform 62 62
a credentialed scan against that web application 63 63
and I want to save that output as an HTML report. 64 64
Nikto can do this as well. 65 65
We're going to type in nikto -host http://10.1.0.10/dvwa, 66 66
which is the web application that I want to go after, 67 67
then -ID and the credentials, 68 68
in my case admin with a password of password. 69 69
And then I want to output that by using -o 70 70
and then/root/downloads/dvwa.htm 71 71
and then -format and put it into HTML format, 72 72
so I'll type in htm. 73 73
Once I do that, I'm going to now have that file 74 74
inside that root directory underneath the downloads folder. 75 75
If I want to see that, because it's an HTML file, 76 76
I need to open it using Firefox. 77 77
So I'll type in firefox /root/Downloads/dvwa.html 78 78
and this will show me all of the information in that report. 79 79
Now as I go through that report, 80 80
I can see all of the different issues that were found. 81 81
For instance, there's directory indexing not found, 82 82
there's configuration information 83 83
that could be remotely available, 84 84
and there's other things like that as we go through it, 85 85
for instance, this PHP reveal that's being shown 86 86
where sensitive information is being displayed 87 87
to the client as they go into that application. 88 88
So these are all just a quick summary 89 89
of some of the issues we found 90 90
with this vulnerable web application. 91 91
Now, the next thing I want to test, 92 92
is I want to move beyond Nikto 93 93
So we've done Nikto, 94 94
and we have some good baseline knowledge of how this works. 95 95
Now, let's move into Burp Suite. 96 96
Burp Suite is an interception proxy, 97 97
and so the first thing I need to do is configure it. 98 98
To be able to configure an interception proxy, 99 99
I have to set up my proxy on my web browser. 100 100
So I'm going to go into my web browser 101 101
and I'm going to type in about:preferences #advanced 102 102
and then press Enter. 103 103
When I do this, it's going to bring up a page 104 104
and I need to scroll all the way to the end of the page 105 105
and click Settings. 106 106
Once I click on Settings, I now need to select 107 107
the manual proxy configuration radio button, 108 108
and then type in the web proxies address, 109 109
in my case, 127.0.0.1, that's my local host, 110 110
that's the machine where I'm going to be running Burp Suite. 111 111
Then under the port, I'm going to type in 8080 112 112
which is the common HTTP proxy port, 113 113
And then I'm going to check Use this proxy server 114 114
for all protocols. 115 115
So anything running on this machine that uses the network 116 116
will use this local host as my proxy. 117 117
And then I'm going to click Okay. 118 118
And next I need to open up Burp Suite, 119 119
and I need to accept the default configurations. 120 120
Now we're ready to start inspecting sessions 121 121
and header data. 122 122
To do this, we are going to use Burp Suite 123 123
to monitor and record those web sessions. 124 124
This will allow us to inspect it, 125 125
and, if we want, modify the data 126 126
that's going between the browser and the server. 127 127
This can include things like your headers, your cookies, 128 128
and your form field submissions. 129 129
Now, the first thing I want to do is click on the Proxy tab 130 130
and then click the Intercept is on button 131 131
to toggle that intercept off. 132 132
Now, I want to arrange my Firefox and my Burp Suite windows 133 133
so I can see both of them as I'm going through this process. 134 134
So you'll see I have them on the left and the right. 135 135
In Firefox, I'm going to go to the website 136 136
that I want to look at, 137 137
in my case, www.515support.com/dvwa. 138 138
And then I'm going to log into that web application 139 139
using my credentials. 140 140
Now, as a regular user, I have user names and passwords. 141 141
In this case, I have admin as the username 142 142
and password as the password. 143 143
Now in Burp Suite, I can click on the HTTP History tab 144 144
and this is going to list all the different requests 145 145
that have been proxied while Burp Suite was on. 146 146
Now, if I select the GET row, 147 147
I can see the request here for dvwa. 148 148
Note the servers response here, 149 149
they're issuing a redirect to the login page. 150 150
Now, if I select the GET row, 151 151
requesting that dvwa/login.php form, 152 152
this is going to show me exactly what happened here. 153 153
I can go ahead 154 154
and check the output of the various tabs here, 155 155
things like Raw, Headers, HTML, and Render, 156 156
and as I look at those, I can see the browser's request 157 157
and the server's response. 158 158
Now you can see here that the application 159 159
has set two different cookies. 160 160
One is to identify the security level 161 161
that we're going to be issued, 162 162
and the other is to set up a session ID. 163 163
Now remember HTTP is a stateless protocol, 164 164
so if I want to be able to tell who is talking to my server, 165 165
I have to use cookies 166 166
or some other session management technique. 167 167
All right, now if I select the POST row, 168 168
I can see the information 169 169
that was submitted from my browser. 170 170
In here, you can actually view the clear text credentials 171 171
inside of Burp suite. 172 172
So I can see that the username was admin 173 173
and the password was password, 174 174
and that they used this user token 175 175
of this random long string. 176 176
Now why could I see this credential information? 177 177
Well, because we use HTTP instead of HTTPS. 178 178
And so you can see why it's so important 179 179
that you use secure connections 180 180
when you're transiting information back and forth. 181 181
The next thing I want to start working on 182 182
is testing command injection. 183 183
And so to do this, I'm going to go into the browser 184 184
and select the Command Injection tab 185 185
in the DVWA web application. 186 186
Now, obviously in a real world experience 187 187
the attack would have to spend a lot of time 188 188
mapping out pages and forms 189 189
and finding things through their reconnaissance, 190 190
but DVWA is built for us as cybersecurity analysts 191 191
to be able to use this with known sets of bad issues 192 192
so we can test things against it 193 193
and see what they look like in the field. 194 194
Now when we do this, we see that there is a box here 195 195
that's going to allow us to put a command in. 196 196
Now, it's supposed to be used for the ping command, 197 197
but if somebody didn't program this right, 198 198
that means you might be able to run any command you want. 199 199
So let's go ahead and try it. 200 200
All right, so I'm going to enter 10.1.0.1 in the box 201 201
and click Submit. 202 202
This is going to allow me to ping that device, that web server. 203 203
Now that works great, 204 204
but what if this person didn't do their coding right? 205 205
And instead of just issuing the ping command, 206 206
I could issue other commands, maybe. 207 207
Well, let's try a couple of Linux commands 208 208
and see if we can do a command injection. 209 209
Let's try inserting LS and typing Submit. 210 210
What do we see? 211 211
Nothing, it didn't work for us. 212 212
All right, let's try something else. 213 213
Let's try typing in 10.1.0.1 like we did before, 214 214
and then put && ls. 215 215
What happens this time? 216 216
Well, there you go. 217 217
We got the ping that we are expecting, 218 218
but we also got the directory listing, 219 219
so we were able to do a command injection here. 220 220
Let's go ahead and try another one. 221 221
Let's try 1 && ps -e. 222 222
This will tell us if it's going to accept anything 223 223
with a number first and then going from there. 224 224
Well, that one didn't do anything. 225 225
Hmm, let's try something else. 226 226
Let's try putting in 10.1.0.1 && ps -e and click Submit. 227 227
Yes, that one worked. 228 228
It does the ping and then it shows me the processes 229 229
that are being executed here. 230 230
So it is allowing me to do command chaining, 231 231
as long as I start with an IP address. 232 232
Let's try some more. 233 233
How about 10.1.0.1 && netstat -tlnp 234 234
and then click Submit. 235 235
Is this going to work? 236 236
Yes, it is. 237 237
We're going to get that ping 238 238
and then the executing of that command, 239 239
because we're chaining these commands together 240 240
inside this box. 241 241
It appears to me that all this box is doing 242 242
is checking "Did you put in an IP address?" 243 243
And it's going to execute that by a ping. 244 244
And then if you use the &&, 245 245
you could put any command you want afterwards. 246 246
So, I might be able to access files. 247 247
For instance, what if I could go in there and use 10.1.0.1, 248 248
&& cat/etc/password and click Submit. 249 249
Look at that. 250 250
We were able to get the ping, 251 251
and then we got the password file. 252 252
Well, if we get the password file, 253 253
let's go ahead and grab the shadow file. 254 254
Let's try 10.1.0.1 && cat/etc/shadow 255 255
and click Submit. 256 256
Now, unfortunately reading the shadow file didn't work. 257 257
Why is that? 258 258
Well, because the shadow file 259 259
has specific permissions on it 260 260
to protect it from things like this happening. 261 261
Now, the command cat/etc/shadow did work, 262 262
but it couldn't display the shadow file 263 263
because that shadow file is protected. 264 264
Now, to confirm this, 265 265
let's go ahead and check a couple more commands. 266 266
Let's try 10.1.0.1 && whoami. 267 267
This will tell us who we are actually operating as. 268 268
And in this case you could see we're operating 269 269
as the user known as Apache 270 270
because we're running it through the web server. 271 271
Let's go ahead and see if we can get some more information. 272 272
What if we did 10.1.0.1 && getent passwd 0. 273 273
What is this going to do? 274 274
Well, this is going to get us the root user, 275 275
which is user ID zero. 276 276
It's going to get their information from the password file 277 277
and display it to the screen. 278 278
Now, if we do this 279 279
and we want to see what the group is for that, 280 280
we could try that by doing 10.1 0.01 && getent group 281 281
and then root. 282 282
And when we do that, you're going to see 283 283
that we have the root user is a member with group X 284 284
and is the user ID of zero. 285 285
Next, let's go ahead and try doing some fuzzed input 286 286
and see if that's going to do anything for us. 287 287
So, what we're going to do here is 288 288
instead of just inventing different commands 289 289
to throw at this misbehaving inbox, 290 290
we can start doing a more structured approach 291 291
by sending in fuzz data. 292 292
This is a fuzzer 293 293
and essentially we can use Burp Suite as that fuzzer. 294 294
This will help us to automate a lot of this testing 295 295
instead of me sitting here 296 296
and typing in all these commands by myself. 297 297
So let's go ahead and click on the SQL Injections tab 298 298
and here we're going to type a 1 in the box and click Submit. 299 299
When we do that, we see what the function is supposed to do. 300 300
When you give it a user ID, 301 301
it's going to give you their first name and their last name, 302 302
in this case Admin and Admin. 303 303
Now in Burp Suite, if I go to the HTTP history tab, 304 304
I can Right Click on that last request 305 305
and click Send to Intruder. 306 306
Now, once I go to the Intruder tab 307 307
within the intruder module, 308 308
I can select the Positions tab 309 309
and then click the clear button. 310 310
Here, I'm going to select the character 1 following the ID= 311 311
in the first line, and then I'm going to click Add. 312 312
Next, I'm going to click on the Payloads tab 313 313
and from here I'm going to click the Load button 314 314
and then browse to 315 315
/user/share/wordless/wfuzz/injections/sql.txt. 316 316
And then I'll click Start attack. 317 317
Now what is this doing? 318 318
Well, what I just did was I selected the variable 319 319
that I want to change, that ID=1, 320 320
and I want to start putting ID= 321 321
whatever the lines are of this SQL file. 322 322
And so this is going to automate my attack for me. 323 323
So as I go through, it's going to go through 324 324
and put each and every one in there. 325 325
And as that attack progresses, 326 326
you're going to observe the length column. 327 327
The unmodified input is going to return a page 328 328
that is 4868 bytes in length. 329 329
Now if you look at the response with a length of 4809, 330 330
you're going to see they're basically blank, 331 331
while anything smaller 332 332
has returned an unformatted error message. 333 333
Now, if we want to sort the output by length, 334 334
we can click on the length column 335 335
and then we can look for any response 336 336
that's larger than 4868. 337 337
For instance, I have one that is 5176. 338 338
This is a apostrophe or 1=1 or quote=apostrophe. 339 339
Now what does that look like to you? 340 340
To me, it looks like an SQL injection, right? 341 341
And if you look through this, 342 342
all of these different things being shown here 343 343
that are above that threshold of 4868 344 344
are different forms of SQL injections. 345 345
Now, I want you to look at the response 346 346
for anything with that single quote payload 347 347
because again this is a simple SQL statement. 348 348
And basically if this form that we have on the DVWA 349 349
isn't doing input validation, 350 350
it's going to allow me to do these SQL injections. 351 351
All right, enough of that for now, let's go ahead 352 352
and close the Intruder window to stop our attack. 353 353
All right, so now that we know 354 354
that this thing is vulnerable to SQL injection, 355 355
let's take a look at the code itself, 356 356
and do a manual analysis of it 357 357
so we can review that vulnerable code. 358 358
If I switch back to my browser 359 359
and I click on the SQL injection page, 360 360
I can click it and then look at View Source. 361 361
When I do this, the source code is going to pop up. 362 362
When we look at that, we're going to compare all levels 363 363
by clicking on that button. 364 364
Now, as we compare each iteration of the code, 365 365
we can see that the higher security code 366 366
has some input validation, while the lower ones don't. 367 367
For example, you can see the is numeric function here 368 368
within this first if block. 369 369
Now, basically what this does is any input that comes in 370 370
is checked using if it's numeric. 371 371
And if it is numeric, it's going to process it. 372 372
If it is not numeric, it's going to delete it 373 373
and just ignore that. 374 374
This essentially is a basic form of input validation. 375 375
Now, this only is going to check this number, 376 376
this input, if it is a number 377 377
because we're expecting ID to equal some number, 378 378
and so we want to prevent anything else from being there. 379 379
So if I put apostrophe, that would prevent this, right? 380 380
Because it's not numeric. 381 381
Now you'll notice at the bottom, 382 382
under the commented code here, 383 383
we also have this little validation statement 384 384
that's going to make sure only one result is returned. 385 385
So if I put in a number one, 386 386
I should only get the first entry, the Admin/Admin. 387 387
If I put in two, I should get that for the second user, 388 388
and not the third, fourth, and fifth user. 389 389
This should only give us one row at a time 390 390
from the database. 391 391
And so you can see here, 392 392
that the data inside the row count has to be equal to one. 393 393
If it is, get the values. 394 394
If not, we're going to ignore it. 395 395
So that's the way 396 396
that we can do some basic input validation. 397 397
So this is a good input validation method 398 398
to prevent an SQL injection.