Prompt

Conduct a security audit on the egov login panel.

Scope: This challenge is limited to HTTPS in scope, please do not attack any other ports on this server.

Tutorial Video

Walk-Through

Web security involves understanding the interaction between website servers and clients (often, your web browser such as Google Chrome, Firefox, Safari, etc.). We will do a brief overview on the basics of how website communication works before diving deeper into web security. Keep in mind that this will just cover some basics and will simplify the details substantially. There is a lot of additional important information to learn and we encourage you to do additional research to learn more.

HTTP Background

URLS

When you visit a website, such as Cyber Skyline, you will type “cyberskyline.com” into the address bar in your browser. Your browser then converts your input into a URL or Universal Resource Locator. In this example, it is likely your browser might convert your input to https://cyberskyline.com/. Your browser is doing this because web requests must be made using the URL format. There are multiple components to a URL. You can reference the example below to see the different components.

The protocol is typically HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Transfer Protocol Secure). This is the protocol that is being used by both the server and the client. A protocol is the specific rules and guidelines necessary for two devices to communicate. The server and client need to use the same protocol to communicate, otherwise they will not be able to understand the communication from the other.

The host describes which website that the request is for. A lookup will be conducted with the Domain Name System (DNS) to get an IP address that the browser can visit. This is similar to how you can enter in the name of a building (eg. the name of your school) into a map or gps application and the application will do a lookup to find the address of that building. Your browser requires the IP address to actually facilitate the communication with the server.

The path is a reference to the specific page you are trying to obtain.

The query is a way of providing additional specific information in your request. For example, if you run a search on Google. They have a single search page, but the query can be changed to run searches on different search terms. If you look at the URL after running a Google search, you will see your search term in the query portion of the URL.

HTTP Requests/Responses

When your browser is ready to visit a website, it will send an HTTP request to the server. HTTP is a text-based protocol, so you can actually see what the request looks like:

On the first line of this request you can see GET, which is the HTTP method. There are multiple methods for HTTP with GET and POST being the most common. GET requests are typically made to request data (eg. viewing an image) whereas POST requests typically send or upload data to the server (eg. uploading an image). You can also see /contact, which is the page being requested and HTTP/1.1 which specify what version of HTTP is being used.

On the second and third lines are HTTP headers. These are automatically added by the browser to specify additional options with the request. In this case, it is specifying that it wants the response to be HTML (Hypertext Markup Language), which is the code that browsers can execute to display a webpage. It also specifies that the request is for www.cyberskyline.com, which is provided in case the web server is processing requests for multiple different websites.

The server will send a response in a similar fashion.

In the server response, you can see the first line again confirms the protocol. It also provides a number, 200, which is the HTTP status code for OK. If an error occurred, there would be a different status code.

After the first line, additional headers are provided by the server which provide extra information. This is then followed by the body, which is the actual HTML code that the browser can run. If this was a request for something different, such as an image, then the body would contain the data for the image.

Cookies

HTTP is a stateless protocol. This means that there is nothing inherent in the protocol that would allow the server to recognize that two separate requests came from the same browser/person. This poses a challenge because it is often useful for the server to know that requests are coming from the same person. For example, if a website has a login page, your browser will send an HTTP request to log in. In subsequent requests to the web server, you would want the server to remember that you are logged into your account.

HTTP cookies were developed to help overcome this problem. Cookies are small pieces of information that are stored in the browser. These cookies can store information about your login session (or other information for different purposes).

A typical implementation of session cookies involves generating a unique id (a series of characters/numbers) that uniquely references a login session with the website. When a user logs in, this session id is generated and the server will tell (via HTTP headers) the browser to save the session id as a cookie. Then, when the browser makes future requests, it will include that cookie in the HTTP headers. When the server reads the request headers, it will conduct a lookup in a database to identify what user that session is for. When a user logs out (or if the session expires), the session is deleted and the user will get a new session id when you log back in. This is a typical implementation, but developers can program their websites to work however they want.

If a website is using HTTP cookies, there are some security implications to consider. It is possible for an attacker to modify their cookies. This means that if an attacker somehow gets a copy of someone’s session id, it is possible for the attacker to use the session id of a victim to impersonate the victim. Additionally, attackers could manipulate a cookie to do things that the website developers may not have considered. This challenge involves one such example of that.

Challenge

The website in this challenge utilizes cookies to check the permission level of the user.

It is suggested that this and all web-based challenges are opened in a separate window to easily view the developer tools and to reduce confusion between resources on the Cyber Skyline website and the actual challenge website. Developer tools are included in most modern browsers and provide access to data about the web page which is not easily accessible otherwise. They also allow for the tampering of data stored by the website and manipulation of the code running in the browser. By default, you should be able to access the developer tools by using the F12 button in the browser or by right-clicking somewhere on the page and selecting the “Inspect” or “Inspect Element” option. This guide will show examples using the Google Chrome developer tools. It may also be useful to view the source code (the code that the web server provides the browser to execute and display the page). This can be done by right-clicking somewhere on the page and selecting the “View Page Source” option.

The first step in analyzing a web application is conducting reconnaissance. During the reconnaissance process, try to identify web pages which might contain a security mechanism that you can break or web pages that serve data that you could potentially trick into leaking sensitive information (login pages, admin panels, search pages). More sophisticated reconnaissance may also include looking for specific pages that are often (accidentally) made publicly available when they shouldn’t be and reviewing the code in the different JavaScript files that are being used by the website.

In this challenge, the website only has a single page that is navigable from the user interface - a login form.

From here, it is important to get a better understanding of how the page is working by analyzing any data being saved by the website in the browser (cookies, localstorage) as well as viewing any source code, particularly JavaScript. Websites utilize multiple different languages for different purposes: Hypertext Markup Language (HTML) for building the structure of the page, Cascading Style Sheets (CSS) for styling the page, and JavaScript (JS) for handling logic such as what to do on a button click. Many website vulnerabilities will involve a misconfiguration (eg. a page that should be password protected but is not) or insecure code (eg. trusting that user-supplied data is always valid). Be mindful that there are many different paths to attack web servers and you should explore more about them by searching and learning from multiple different sources online. A good starting point is the OWASP Top 10.

In this challenge, there is a cookie called “admin” which indicates if the user is an admin or not. View the cookie in the “Application” tab of the developer tools. By default, this cookie is set to “false”.

Set the cookie to “true” using the “Console” tab and verify the value. After setting the “admin” cookie to true, try refreshing the page. When the page is refreshed, there will not be a noticeable change, which indicates that there must be something else that needs to be done.

At this point, analyzing the code for additional clues may be useful. This can be done directly in the developer console by going to the “Sources” tab. Alternatively, using “View Source” on the page can help identify what external scripts are being loaded on the page.

It can be seen from login.js source that users are redirected to /admin after a successful login.

The naming of the /admin page indicates that this may be a sensitive page that warrants further investigation. As it happens, after the cookie has been properly set, a user can visit /admin where the flag can be seen. This can be confirmed by code used on the login page. It appears that after a successful login, the user is redirected to the /admin page. Presumably, when the user provides correct admin login credentials, the server instructs the browser to set the admin cookie to “true”. Since cookies are stored in the client’s browser, it is possible for an attacker to change the admin cookie to “true” without needing to know the login credentials.

Questions

What is the flag obtained from logging in?

Open the egov webpage in a separate tab, then open the developer tools in your browser, run document.cookie = 'admin=true' to set the admin value to true in your cookies, and then attempt to log in to the admin panel using any username and password.

⚠️

The flag is randomly generated so the correct flag for you will be different.