Lab 14: Web Application Vulnerabilities

This last lab I honestly had fun doing this lab as it was quite funny and I learn more from this lab then any of the other ones. Which this one focused on Web application Vulnerabilities and how these vulnerabilities are just simple things that can show that even little things can be a big problem.

First thing I had to do for this lab is to disable the world wide web publishing services as the website needs to have access to the domain.

We then installed XAMPP control panel which it basically showed three ports were being used which were 80, 443 and 3306 which apache and MySQL used. We then extracted a zip folder and edited a notepad file which was $_DVWA[  ‘db_password’ ] =”;

We then created a new firewall rule which basically was an inbound rule which allowed connections to come through port 80, 443 and 3306 as we need these ports to be open to let us in the server. We then did a run dialog which was http://server/dvwa after that we basically we created a which basically exploited a flaw in the database system.

We then did a ping which the size of the packets was basically like the normal

When we put server | dir it basically shows the above this is because this would be default as it is built to show the vulnerabilities which it basically shows the files and 4 directories

This what is shown when you put 2 in the user id input box which this shows its using an ID system for the users which means if you have an ID number you can get information on a person through this system.

The following image above basically show if you put just a ‘ in the input box and hit enter it will basically error out which basically show that itself is using MySQL or a coding system that is basically really broken.

We then run a script which basically is xss and takes the name in the input box and runs and then goes onto say Hello (Your Name) and then the next image below is another script which shows if it’s empty it will just say Hello world.

Lab 13: HTTP and HTTPS

This lab focuses on HTTP and HTTPS basically this lab to me showed basically the weaknesses of both and how basic authentication is better than no authentication at all

In the picture above I kind of accidentally highlighted the wrong packet it was the one above it I was spouse to highlight but basically the aim of the above packet is to show how TCP starts off with the three way handshake. This also shows the code which is used for the website meaning that someone can easily copy it over.

Which I then created a self signed certificate which I put the friendly name as the server name then the domain name which was stored as a personal certificate.

Which we then bind the site to https through the port number 443 this so it can be secure and be linked to the certificate.

We then went into the SSL settings which we selected ignore and when we tried the old url with just http at the start it wouldn’t allow us through to the site so we had to put https://server.classroom.local instead so it would let us through.

The above shows that the https is working and that the https is checking to see if the line is still secure and that there no http involved what so either when it’s using HTTPS on the website for the server.

Lab 12: Data Leakage Prevention

This lab focuses on the data leakage prevention in a domain and how to prevent information from being leaked.

First off we started by installing the rights management service which basically is installing the roles for the data leakage prevention.

We then started configuring the AD RMS role which we started by creating a policy template. Which we started off by adding a template identification and user rights which basically the user rights is the users that will have rights to this policy by via their email address for the domain. This basically lets these list of users access the content that is protected under this policy.

 

We also the put a time limit to this policy which was set 365 days meaning that after this amount of time the policy will expire and which then the user will have to get a new license to access this content.

The problem that I faced with this is more of a personal feeling towards as it was only installing the role and just configuring it and then you were done which to me I don’t feel like I learn anything as there was no showing or examples on what it actually does if it expires the license and really didn’t show it working in the environment we were playing with.

Lab10 Attacks against dhcp and dns

The above is setting up a dhcp scope for the classroom.local domain which we set it to get ip addresses starting at 10.1.0.128 to 10.1.0.254 which an ip address will be allocated to the client computer when it’s login to. It will renew every hour so it doesn’t have a address over this amount of time.

We then changed something in a downloaded copy of the domain Web page which we can definitely tell if it going to the rogues static ip address instead of the servers.

 

We then set the static ip address to 10.1.0.10 and the same with the preferred dns server to the same as the static ip address.

We then install the dual server feature on the rogues machine which basically let’s there be 2 dhcp and dns servers on at the same time on the same address meaning basically the rogue can say that it’s the primary dns server and not the aactual server.

We then made sure that this feature was running as basically if it’s on it will make it self the main server a day not the actual one.

Lab 9:Telnet and FTP

This lab focuses on telnet and FTP on the server and what wireshark is basically capturing when it is being used.

First off we had to install the telnet server role and the FTP server services as we need these for FTP to work.

We then disable the anonymous authentication as this basically would let anyone in without authenticating that they are user on the domain which makes the server vulnerable to attacks and capturing packets.

We then had to create an FTP site which we went with basic authentication as it will ask for username and password when asked. We also let read and write access to all users which it will let them in and create files on the server.

We then had to let Inbound and Outbound access connections through as Telnet and FTP would not go through if these are set to be blocked meaning it wouldn’t be able to connect and contact the server. But it also makes it more vulnerable to attacks as basically you are opening another potential part which would let attackers through.

We then had to do the same through the client but we installed it as a client role/feature as they won’t be handling FTP themselves. It also because if we didn’t have this we wouldn’t be able to access the FTP and the telnet server. Which when we connected we had to use CTRL + ] to escape the telnet session.

When wireshark capture the telnet packets the 26 packets from the above and below picture all contain the letters to make up the username/login and password that was entered which can be a big risk as it is giving out account information.

When I got to the last packet it basically had no other information to give so basically you have to grab the letters throughout the packets and make it full as you go along looking through the packets.

The packet number for the first non Request: USER = anonymous it was at packet number 117 which the 2 after that are basically the password information which the first packet is requesting the password and then the next being the actual password that has been entered. This is defiantly a threat as username and passwords are visible meaning basically anyone who has wireshark and is capturing packets on the network can see this.

Then we had the FTP DATA packets which form these we can see that no information can be seen.

Lab 8: Configuring a VPN

In this lab we focused on how creating a VPN helps to hide sensitive information and how it can help businesses access information without having to worry about security.

First off we made a document which contained text which if intercepted by wireshark and if it would show it will be in plain text. We didn’t encrypt any of this information as it would be hard to show the information.

We then used a run dialog to run to the server which was successful as the secret$ document showed up in a packet response which was captured by the software this was evidence of a weak server as it didn’t asked for any authentication.

We then used the filter so the read response would only show up which the secret$ document still showed up as confidental.txt

We then installed the VPN role through server manager which after that we had to configure the advance firewall to let it through as it would block if we didn’t disable the rule it was set on.

We then created a VPN and configured it so it would let us in which we I got their successfully as the first try it wouldn’t login most likely because it was a virtual machinhe and not a real one. We then did the same thing we did a run command for the server and tried to intercept the packet for the text document.

The result was that I couldn’t find any packet that showed the document name this was because we login to the server via vpn the information was directed to that one as it was the one handling the information.