47 posts tagged with "overthewire"

HTTP header​

okay let me go through it straight forward

GET /home.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/testpage.html
Connection: keep-alive
Upgrade-Insecure-Requests: 1
If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT
If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"
Cache-Control: max-age=0

you might have seen this type of thing in burp suite, if not no problem.
all these things such as User-Agent, Host, Accept etc are called as HTTP header

lame language definition:
they are key-value pair that gives you additional information about the request or the response

now formal definition:
HTTP headers let the client and the server pass additional information with a message in a request or response. [source: mdn]

Request header​

it is a header that can used in HTTP request to provide information about the request context, so that server can tailor the response. for example Accept header tells us which is preferred or allowed format of the response

CORS​

short for cross-origin resource sharing is a system consisting of transferring http header which tells whether the browser blocks frontend javascript code from accessing responses from cross origin requests

some CORS headers are Access-Control-Allow-Origin, Access-Control-Allow-Credentials, etc

Cookies​

these are small pieces of data that web server stores on your browser to remember information between requests .. so question arises why cookies exists? http is stateless .. every request is independent ... server doesnt remember you ... cookies fix that by storing small data on your device so that server can recognize you whenever you revisit
cookies are stored in browsers in small text files and server sends them as Set-Cookie http header.
`

Natas 2​

so in this level you will see there is nothing in the html, css and js when you inspect the element ... so we got the hint from there, that there a folder named files by looking at the line <img src="files/pixel.png>

so now we will navigate to the files by adding /files in the end
there you will see users.txt
in that you will find password for natas 3

`

Natas 3​

Theory​

Today’s internet is indexed by search-engine crawlers, such that Google and Co know what content exists on websites to improve search engine results. The robots.txt file exists on servers to tell these crawlers and other web bots, which part of the website can be visited. It allows defining a user-agent aka for what specific bot the rules should be, and which page of the website the user-agent is not allowed to visit.

User-agent: Googlebot
Disallow: /nogooglebot/

User-agent: *
Allow: /

Sitemap: https://www.example.com/sitemap.xml

Here, for all crawlers/bots the whole website can be visited, except Google’s crawler, which cannot visit the ’nogooglebot’ directory. Also noticeable is the sitemap link. A sitemap is another file to give web crawlers information about the website. It is important to be aware that the ‘robots.txt’ file does NOT serve a security purpose. The disallowed pages can still be visited and might still show up in search engines. Read more about this file in the (Google Developer Docs)[https://developers.google.com/search/docs/crawling-indexing/robots/create-robots-txt].

Solution​

Opening the website and looking at the source code, we can find a comment, which gives us a hint: .

This sound like the robots.txt file, I explained in the theory section. Navigating to the site: http://natas3.natas.labs.overthewire.org/robots.txt reveals that the file exists and it shows a disallowed path. Navigating to this path, again leads to a public directory with a ‘user.txt’ file, which contains the password to the next level.

`

Natas 4​

Theory​

The communication between the client (our machine) and the server (that hosts the website) is done by a request-response. We sent a request for a certain page and the server sends the response with the content. Generally, they will follow different protocols and structures, which depend on the service. In this case, it is HTTP (Hypertext Transfer Protocol). The request generally includes the request method (GET, POST,…), the requested URL and the protocol version. However, it can also include additional, potentially needed information, through so-called request headers. There are many such fields, some more common than others. Relevant ones for this challenge are ‘Authorization’, which would include the credentials for the website and ‘Referer’, which is the URL/webpage from which the request is sent. Generally, all this is handled by our browser and we do not have to worry about it. It is however possible to manipulate requests.

Solution​

1. open the burpsuite
2. turn the intercept on
3. then click on the "refresh page" button

4. send the request to the repeater
5. open the repeater tab and edit the "Referer: http://natas4.natas.labs.overthewire.org/" to "Referer: http://natas5.natas.labs.overthewire.org/"
6. then send the request again ...
7. you will see that you have been authorised and you will get the password of natas 5
   `

Natas 5​

Theory​

http is a stateless protocol: each request is independent and the server does not keep session state by default. to provide a continuous experience (for example, a logged-in session) servers send small pieces of data called http cookies to the client. the browser stores these cookies and sends them back with subsequent requests so the server can associate requests with a session or particular user.
a cookie is just a key=value pair (plus optional attributes like domain, path, expires, http-only, secure). because cookies live on the client side, a user (or an attacker) can inspect and modify them unless the server uses additional protections. depending on how the server interprets the cookie value, simple changes on the client side can change the server’s behavior — for example toggling an authentication flag.
in this level the application decides whether you are “logged in” based on a cookie value. by examining and altering that cookie you can change the perceived session state and gain access if the server relies solely on client-supplied cookie data.

Solution​

1. open the burp suite
2. navigate to proxy tab
3. turn on the intercept and open http://natas5.natas.labs.overthewire.org/
4. right click and send it to repeater
5. in the inspector section you will find request headers section
6. in that cookie value will be loggedin=0
7. change that to zero and apply changes then send the request ... in the response section you will see the password for natas 6

`

Natas 6​

Solution​

when you will click "view sourcecode" ... source code will showup there you will see <? ?> this is php
PHP in HTML is enclosed in the following tags: <? ?> or <?php ?>. Variables start with a $ sign and the content of forms sent with a POST request can be accessed with the special $_POST variable.
Another important part for this level is that it is possible to include code from other files into a file, by using include or require.

since we can see one thing named includes/secret.inc
so visit http://natas6.natas.labs.overthewire.org/includes/secret.inc

you will see a blank page ... because since it does not show us an error, something is happening, PHP code is running, which does not include any visual output

so inspect and you will find the secret key like this:

?
$secret = "****************";
?

now you got the secret and then paste it in the box ... you will get password to natas 7 ... and there you go! `

Natas 7​

Solution​

if we click on about, the web server will append /index.php?page=about to the end of the url
if we view the page source ../ we see a comment in both pages:
hint: password for webuser natas8 is in /etc/natas_webpass/natas8

if we try to visit /etc/natas_webpass/natas8 directly ... we will encounter Not Found error.

but if we try to visit it while we are in home ... that is: http://natas7.natas.labs.overthewire.org/index.php?page=home/etc/natas_webpass/natas8

we will get a warning which goes like

Warning: include(home/etc/natas_webpass/natas8): failed to open stream: No such file or directory in /var/www/natas/natas7/index.php on line 21

Warning: include(): Failed opening 'home/etc/natas_webpass/natas8' for inclusion (include_path='.:/usr/share/php') in /var/www/natas/natas7/index.php on line 21

error messages are frequently useful for getting a working exploit ... you can see that the web server tried and failed to open filename "home", and also told us the file path.
from here ... we can either use an absolute file path (ex: /etc/passwd) or a relative file path (../../../../etc/passwd).

lets use the absolute file path option, and navigate to http://natas7.natas.labs.overthewire.org/index.php?page=/etc/natas_webpass/natas8. This will include the flag file and display it to us.

`

Again inspect element
since right click is disabled use shortcut to inspect element

and you did it!!
you will see the password there

`

Login: ssh bandit12@bandit.labs.overthewire.org -p 2220
Password: 7x16WNeHIi5YkIhWsfFIqoognUTyj9Q4

task​

The password for the next level is stored in the file data.txt, which is a hexdump of a file that has been repeatedly compressed. For this level, it is helpful to create a directory under /tmp in which you can work.

theory lil bit​

1. xxd: A tool that creates a hexdump of a given file or standard input. It can also do the reverse, which is what we need here using the -r flag to turn a hexdump back into a binary file.
2. file: This command is your best friend here. It determines the file type by looking at the "magic bytes" (header) of the file, telling you if it's a Gzip, Bzip2, or Tar archive.
3. Decompression Commands:
   • gzip/gunzip: Handles .gz files.
   • bzip2/bunzip2: Handles .bz2 files.
   • tar: Handles .tar files using -xf (extract file).
4. Workflow: The process is iterative: check the file type with file, rename it to have the correct extension, decompress it, and repeat until you get ASCII text.

solution​

# Create a working directory
bandit12@bandit:~$ mktemp -d
/tmp/tmp.50qnmYRfkb
bandit12@bandit:~$ cd /tmp/tmp.50qnmYRfkb
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ cp ~/data.txt .

# Reverse the hexdump
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ xxd -r data.txt > binary

# Repeated decompression based on 'file' command output
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file binary
binary: gzip compressed data...
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ mv binary b.gz && gunzip b.gz

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file b
b: bzip2 compressed data...
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ mv b file.bz2 && bunzip2 file.bz2

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file file
file: gzip compressed data...
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ mv file file.gz && gunzip file.gz

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file file
file: POSIX tar archive (GNU)
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ tar -xf file

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file data5.bin
data5.bin: POSIX tar archive (GNU)
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ tar -xf data5.bin

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file data6.bin
data6.bin: bzip2 compressed data...
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ mv data6.bin data.bz2 && bunzip2 data.bz2

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file data
data: POSIX tar archive (GNU)
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ tar -xf data

bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file data8.bin
data8.bin: gzip compressed data...
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ mv data8.bin hello.gz && gunzip hello.gz

# Final Result
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ file hello
hello: ASCII text
bandit12@bandit:/tmp/tmp.50qnmYRfkb$ cat hello
The password is FO5dwFsc0cbaIiH0h8J2eUks2vdTDwAn

`

Login: ssh bandit13@bandit.labs.overthewire.org -p 2220
(you already logged in as bandit13 and found sshkey.private in the home directory)

Task

You are given a private SSH key file (sshkey.private) in the bandit13 home directory. Use that key locally to connect to the bandit14 account. After you successfully ssh to bandit14, read the file /etc/bandit_pass/bandit14 to get the next level password.

Quick solution (commands)​

# copy the private key from the remote host to your local machine
scp -P 2220 bandit13@bandit.labs.overthewire.org:sshkey.private .

# secure the key locally (OpenSSH requires strict permissions)
chmod 600 sshkey.private

# use the key to login as bandit14
ssh -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org

# once logged in as bandit14, read the password for the next level
cat /etc/bandit_pass/bandit14

Theory (a bit more — why this works)​

1. Public-key SSH authentication

   • Instead of a password, SSH can use an asymmetric key-pair: a private key (which you keep secret) and a public key (stored on the server).
   • If the server has the corresponding public key in the authorized_keys of an account, SSH proves you own the private key and logs you in as that account.
   • In this level you were given the private key for bandit14. Possessing that key is equivalent to having the password for bandit14 (for authentication purposes).

2. scp

   • scp copies files over SSH. The -P 2220 option tells scp to use port 2220 (Bandit uses that port).
   • Example: scp -P 2220 bandit13@...:sshkey.private . copies sshkey.private from the remote bandit13 home to your current local directory.

3. File permissions matter

   • OpenSSH refuses to use private key files that are readable by group or others. If a private key file is group/world-readable SSH prints a warning like:

     Permissions 0640 for 'sshkey.private' are too open.
     

   • The correct permission for private keys is `` (-rw-------) so that only the file owner can read/write it. 700 (-rwx------) also works but is non-standard (private keys usually don't need execute bit).
   • Use chmod 600 sshkey.private to fix permissions.

4. Windows line endings

   • If the key was moved through Windows or edited with a Windows editor, it may contain CRLF ( ) line endings. SSH expects Unix LF ( ). Convert with dos2unix or a tr command if needed.

5. Troubleshooting

   • If SSH refuses to authenticate, add verbose output to see why:

     ssh -vvv -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org
     

     Look for messages about Offering public key and Authentication succeeded or Permission denied.
   • If you still get Permission denied (publickey), confirm:
     • The key file content is intact (no accidental edits).
     • File permissions are 600 and ownership is your user.
     • You used the correct user (bandit14) and port (2220).

6. ssh-agent alternative

   • Instead of passing -i every time, add the key to your agent (keeps it in memory):

     ssh-add sshkey.private
     ssh -p 2220 bandit14@bandit.labs.overthewire.org
     

Full explained session (step-by-step)​

1. On the remote server (bandit13) — you discovered the key:

bandit13@bandit:~$ ls
sshkey.private

2. From your local machine — copy the key here for use:

scp -P 2220 bandit13@bandit.labs.overthewire.org:sshkey.private .
# you will be prompted for the bandit13 password

3. Secure the key file

# make it readable only by you
chmod 600 sshkey.private
# verify
ls -l sshkey.private
# output should look like: -rw------- 1 youruser yourgroup 1675 Sep 19 12:34 sshkey.private

4. Attempt SSH using the key

ssh -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org

• On first connect you'll likely be asked to accept the host fingerprint — answer yes.
• If the key works you'll be dropped into a shell as bandit14.

5. Read the next-level password

cat /etc/bandit_pass/bandit14
# this prints the password you need for the next level

Example (what you might see)​

$ scp -P 2220 bandit13@bandit.labs.overthewire.org:sshkey.private .
bandit13@bandit.labs.overthewire.org's password:
sshkey.private                          100% 1675   1.6KB/s   00:00

$ chmod 600 sshkey.private
$ ssh -i sshkey.private -p 2220 bandit14@bandit.labs.overthewire.org
The authenticity of host '[bandit.labs.overthewire.org]:2220 ([IP]:2220)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
Welcome to bandit...
$ cat /etc/bandit_pass/bandit14
<the-password-for-bandit15>

Cleanup & security reminder​

• This is a game environment, but in real life never share private keys publicly (e.g., push them to GitHub). Remove keys from your local machine when you no longer need them:

shred -u sshkey.private   # securely delete
# or simply: rm sshkey.private

• If you ever suspect a private key has been exposed, revoke it on the server (remove the corresponding public key from ~/.ssh/authorized_keys) and generate a new key pair.

If you want, I can:

• shorten this into a one-page README.md suitable for GitHub, or
• create a small diagram explaining public/private key flow, or
• add the exact ssh -vvv debugging output to the doc (if you paste your session output).

Tell me which you prefer and I will update the file.

`