Welcome back to the walkthrough for the OverTheWire Bandit wargame. This post marks part 4 of the walkthrough, in which we’ll take on levels 15 through 19. As you’ll remember, the last level we completed involved sending data to a service over TCP. We’ll start this post by building on this, using SSL to encrypt data we send over TCP securely.
Let’s dive straight into level 15!
Level 15 - Level 16
In this level, the password for the next level can be retrieved by submitting the password of the current level to port 30001 on localhost using SSL encryption. This task is similar to the previous level in the last post but requires using SSL (Secure Sockets Layer) instead of plain TCP.
First, some background context on SSL. SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that provide secure communication over a computer network. TLS is the successor to SSL and provides improved security and performance. Although all versions of SSL are now deprecated due to security vulnerabilities, the term “SSL” is still commonly used to refer to these types of encrypted connections, even when we’re actually using TLS. Throughout these blog posts, I’ll use the terms SSL and TLS interchangeably to refer to secure communications using these protocols.
As you’ll remember, in the last level, we submitted the password via plain TCP using netcat. However, netcat doesn’t support communicating over TLS. To help us with this, we’ll be using openssl, a robust toolkit for the SSL and TLS protocols. openssl includes various cryptographic functions and utilities, including the ability to connect to SSL/TLS services, which we will be using for this level.
To connect to a specific port using openssl, the basic syntax is:
$ openssl s_client -connect <hostname>:<port>
In our case, localhost is the hostname, and 30001 is the port.
We’ll use cat with the “bandit_pass” directory again, like in the last level, to provide the password as input to openssl via a pipe. We also need to handle the connection properly by using -ign_eof to ignore the end-of-file (EOF) indicator, as suggested in the level’s note in the description.
$ cat /etc/bandit_pass/bandit15 | openssl s_client -connect localhost:30001 -ign_eof
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 CN = SnakeOil
verify error:num=18:self-signed certificate
verify return:1
depth=0 CN = SnakeOil
verify return:1
---
Certificate chain
0 s:CN = SnakeOil
i:CN = SnakeOil
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Jun 10 03:59:50 2024 GMT; NotAfter: Jun 8 03:59:50 2034 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFBzCCAu+gAwIBAgIUBLz7DBxA0IfojaL/WaJzE6Sbz7cwDQYJKoZIhvcNAQEL
BQAwEzERMA8GA1UEAwwIU25ha2VPaWwwHhcNMjQwNjEwMDM1OTUwWhcNMzQwNjA4
MDM1OTUwWjATMREwDwYDVQQDDAhTbmFrZU9pbDCCAiIwDQYJKoZIhvcNAQEBBQAD
ggIPADCCAgoCggIBANI+P5QXm9Bj21FIPsQqbqZRb5XmSZZJYaam7EIJ16Fxedf+
jXAv4d/FVqiEM4BuSNsNMeBMx2Gq0lAfN33h+RMTjRoMb8yBsZsC063MLfXCk4p+
09gtGP7BS6Iy5XdmfY/fPHvA3JDEScdlDDmd6Lsbdwhv93Q8M6POVO9sv4HuS4t/
jEjr+NhE+Bjr/wDbyg7GL71BP1WPZpQnRE4OzoSrt5+bZVLvODWUFwinB0fLaGRk
GmI0r5EUOUd7HpYyoIQbiNlePGfPpHRKnmdXTTEZEoxeWWAaM1VhPGqfrB/Pnca+
vAJX7iBOb3kHinmfVOScsG/YAUR94wSELeY+UlEWJaELVUntrJ5HeRDiTChiVQ++
wnnjNbepaW6shopybUF3XXfhIb4NvwLWpvoKFXVtcVjlOujF0snVvpE+MRT0wacy
tHtjZs7Ao7GYxDz6H8AdBLKJW67uQon37a4MI260ADFMS+2vEAbNSFP+f6ii5mrB
18cY64ZaF6oU8bjGK7BArDx56bRc3WFyuBIGWAFHEuB948BcshXY7baf5jjzPmgz
mq1zdRthQB31MOM2ii6vuTkheAvKfFf+llH4M9SnES4NSF2hj9NnHga9V08wfhYc
x0W6qu+S8HUdVF+V23yTvUNgz4Q+UoGs4sHSDEsIBFqNvInnpUmtNgcR2L5PAgMB
AAGjUzBRMB0GA1UdDgQWBBTPo8kfze4P9EgxNuyk7+xDGFtAYzAfBgNVHSMEGDAW
gBTPo8kfze4P9EgxNuyk7+xDGFtAYzAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3
DQEBCwUAA4ICAQAKHomtmcGqyiLnhziLe97Mq2+Sul5QgYVwfx/KYOXxv2T8ZmcR
Ae9XFhZT4jsAOUDK1OXx9aZgDGJHJLNEVTe9zWv1ONFfNxEBxQgP7hhmDBWdtj6d
taqEW/Jp06X+08BtnYK9NZsvDg2YRcvOHConeMjwvEL7tQK0m+GVyQfLYg6jnrhx
egH+abucTKxabFcWSE+Vk0uJYMqcbXvB4WNKz9vj4V5Hn7/DN4xIjFko+nREw6Oa
/AUFjNnO/FPjap+d68H1LdzMH3PSs+yjGid+6Zx9FCnt9qZydW13Miqg3nDnODXw
+Z682mQFjVlGPCA5ZOQbyMKY4tNazG2n8qy2famQT3+jF8Lb6a4NGbnpeWnLMkIu
jWLWIkA9MlbdNXuajiPNVyYIK9gdoBzbfaKwoOfSsLxEqlf8rio1GGcEV5Hlz5S2
txwI0xdW9MWeGWoiLbZSbRJH4TIBFFtoBG0LoEJi0C+UPwS8CDngJB4TyrZqEld3
rH87W+Et1t/Nepoc/Eoaux9PFp5VPXP+qwQGmhir/hv7OsgBhrkYuhkjxZ8+1uk7
tUWC/XM0mpLoxsq6vVl3AJaJe1ivdA9xLytsuG4iv02Juc593HXYR8yOpow0Eq2T
U5EyeuFg5RXYwAPi7ykw1PW7zAPL4MlonEVz+QXOSx6eyhimp1VZC11SCg==
-----END CERTIFICATE-----
subject=CN = SnakeOil
issuer=CN = SnakeOil
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2103 bytes and written 373 bytes
Verification error: self-signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self-signed certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 015641EEDF7D847A928900B9CC3CCE3C4A540A942D4F69C0331167491B3E5581
Session-ID-ctx:
Resumption PSK: 0B7686A9FACB6469E7B69BC289AF6C728F3255CD51A632F11B8E5E08DBBF3AA952B8ED4686CAF13EEDC179BA2D069FAD
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 60 61 e6 2e a8 2b fb 0f-0a aa 39 05 88 21 10 3e `a...+....9..!.>
0010 - 65 21 ee 25 a2 cf 16 e1-1d 60 2b 59 9e 48 56 63 e!.%.....`+Y.HVc
0020 - 7e 02 87 01 9a 37 02 59-64 1a 50 ab 4e fd a2 ed ~....7.Yd.P.N...
0030 - 4f dd 9b ab 4f 75 b4 ca-a0 82 82 a9 ae 45 85 d7 O...Ou.......E..
0040 - 2d e4 5a 1a b0 1c 58 fc-12 a3 2f fc e3 09 cb b5 -.Z...X.../.....
0050 - cc 72 a7 45 e5 43 18 06-d8 ec ef 2d 62 61 a1 e2 .r.E.C.....-ba..
0060 - 41 5f 61 13 95 58 04 2c-b4 f8 ca 44 e9 e2 8d 1b A_a..X.,...D....
0070 - 2e 9c c0 02 48 d2 1a 10-bd c2 63 1b 48 90 f8 36 ....H.....c.H..6
0080 - 71 2d 75 d1 9d a1 22 cd-5c 36 9c b8 ee 1a 22 52 q-u...".\6...."R
0090 - 40 ba 5e 32 d8 5b 55 11-29 c3 1f 7c 87 b8 c8 0a @.^2.[U.)..|....
00a0 - 9d 96 c7 ba 1f 89 1f 99-3f 7f 81 f8 33 36 31 fa ........?...361.
00b0 - c7 34 4e 87 98 56 e0 be-1a 1a af 95 65 24 23 2c .4N..V......e$#,
00c0 - 1c 23 63 a5 b5 f7 96 5c-84 77 c3 b9 8a 65 00 48 .#c....\.w...e.H
00d0 - e8 de 1c c3 e6 1b a1 95-a9 74 7a 3b 93 0f 22 18 .........tz;..".
Start Time: 1719432231
Timeout : 7200 (sec)
Verify return code: 18 (self-signed certificate)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 1B6F23FF7351DC7287203907BD5463F271313DDEF4D291000AB3317DDD1DAE80
Session-ID-ctx:
Resumption PSK: 717C160E068429A783F2F1474BD91B717088A52BDDB6AA4895D93094CF14D0732082176345560E2EFE2BD6B9E1575227
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 60 61 e6 2e a8 2b fb 0f-0a aa 39 05 88 21 10 3e `a...+....9..!.>
0010 - ba d1 e1 56 19 41 11 e0-5c 15 2f 04 3f 90 ab cc ...V.A..\./.?...
0020 - a8 b1 29 8b fe 8c 6d 9f-cd cc 5e 67 1d 1b c7 10 ..)...m...^g....
0030 - d2 86 28 48 bc 10 0e f9-7e be 3b 25 24 81 7f 05 ..(H....~.;%$...
0040 - 36 e3 11 e0 c1 55 22 d1-04 21 c9 f2 30 28 51 89 6....U"..!..0(Q.
0050 - 3c a1 9e 9c 8e 23 d4 06-f1 2c b4 13 70 93 f0 e2 <....#...,..p...
0060 - eb 7d 54 80 72 9e c3 29-c3 91 29 0c 07 22 4c 76 .}T.r..)..).."Lv
0070 - 28 7a fd 4c ab 99 3a 32-5c 81 63 8e 20 83 25 e1 (z.L..:2\.c. .%.
0080 - cb c5 a7 e8 4e 29 c4 22-02 f8 a5 ee 4f 22 de 6c ....N)."....O".l
0090 - 94 b7 cc a7 23 5d f7 2b-4e 76 b6 f3 76 2b ab 7e ....#].+Nv..v+.~
00a0 - 97 95 1e f4 bc ac fd b1-45 63 dc 4e 06 19 2e 4a ........Ec.N...J
00b0 - 2f 86 9f f9 0a 70 11 df-24 00 4a f6 72 83 16 c7 /....p..$.J.r...
00c0 - 97 ae ac d0 4b c1 51 47-a5 90 27 99 fa 0d d0 54 ....K.QG..'....T
00d0 - ac 8c 7f 0b 50 74 46 c4-6e 51 65 42 95 f6 de 58 ....PtF.nQeB...X
Start Time: 1719432231
Timeout : 7200 (sec)
Verify return code: 18 (self-signed certificate)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
Correct!
<password>
closed
In this output, you’ll see the certificate used by the service. You may also notice that we have an error 18, indicating the service uses a self-signed certificate. This simply means the certificate was created manually rather than issued by a trusted certificate authority. This is expected in test environments and wargames like this. You’ll also be able to see the details about the SSL handshake, including the protocol (TLS 1.3) and cipher suite (TLS_AES_256_GCM_SHA384) used. Finally, near the bottom, you’ll see the success message and password.
Level 16 - Level 17
Like last time, the credentials for the next level can be retrieved by submitting the password of the current level to a port on localhost. However, in this level, we don’t know the specific port - we only know that the port is in the range of 31000 to 32000. First, we’ll need to find out which of these ports have a service listening on them, then identify which of those speak SSL. This is the service to which we need to send the password.
Let’s begin by identifying which ports have a service listening on them. For this, we will use the nmap command. nmap, short for network mapper, is a powerful network scanning tool used to discover hosts and services on a computer network by sending packets and analysing the responses. We’ll tell nmap to scan localhost with the -p option to give it a port range to scan. We’ll also add the -sV option to tell nmap to attempt to detect what service is running on each port, which will help us identify the correct one to send the password to:
$ nmap -sV -p 31000-32000 localhost
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-06-27 10:15 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000098s latency).
Not shown: 996 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
31046/tcp open echo
31518/tcp open ssl/echo
31691/tcp open echo
31790/tcp open ssl/unknown
31960/tcp open echo
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 147.68 seconds
From the table produced by nmap, we can see that there are five open ports in the specified range: 31046, 31518, 31691, 31790, and 31960. Four of the five services are “echo”, meaning they will send back any data they receive, which aligns with what we were told in the level description. Only two of the services use SSL, with only one not running “echo” - port 31790, which nmap could not detect, therefore marking it as “unknown”.
Let’s send the current password to this port using the same method we used in the last level. We can also add the -quiet option to reduce unnecessary output from openssl:
$ cat /etc/bandit_pass/bandit16 | openssl s_client -quiet -connect localhost:31790 -ign_eof
Can't use SSL_get_servername
depth=0 CN = SnakeOil
verify error:num=18:self-signed certificate
verify return:1
depth=0 CN = SnakeOil
verify return:1
Correct!
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAvmOkuifmMg6HL2YPIOjon6iWfbp7c3jx34YkYWqUH57SUdyJ
imZzeyGC0gtZPGujUSxiJSWI/oTqexh+cAMTSMlOJf7+BrJObArnxd9Y7YT2bRPQ
Ja6Lzb558YW3FZl87ORiO+rW4LCDCNd2lUvLE/GL2GWyuKN0K5iCd5TbtJzEkQTu
DSt2mcNn4rhAL+JFr56o4T6z8WWAW18BR6yGrMq7Q/kALHYW3OekePQAzL0VUYbW
JGTi65CxbCnzc/w4+mqQyvmzpWtMAzJTzAzQxNbkR2MBGySxDLrjg0LWN6sK7wNX
x0YVztz/zbIkPjfkU1jHS+9EbVNj+D1XFOJuaQIDAQABAoIBABagpxpM1aoLWfvD
KHcj10nqcoBc4oE11aFYQwik7xfW+24pRNuDE6SFthOar69jp5RlLwD1NhPx3iBl
J9nOM8OJ0VToum43UOS8YxF8WwhXriYGnc1sskbwpXOUDc9uX4+UESzH22P29ovd
d8WErY0gPxun8pbJLmxkAtWNhpMvfe0050vk9TL5wqbu9AlbssgTcCXkMQnPw9nC
YNN6DDP2lbcBrvgT9YCNL6C+ZKufD52yOQ9qOkwFTEQpjtF4uNtJom+asvlpmS8A
vLY9r60wYSvmZhNqBUrj7lyCtXMIu1kkd4w7F77k+DjHoAXyxcUp1DGL51sOmama
+TOWWgECgYEA8JtPxP0GRJ+IQkX262jM3dEIkza8ky5moIwUqYdsx0NxHgRRhORT
8c8hAuRBb2G82so8vUHk/fur85OEfc9TncnCY2crpoqsghifKLxrLgtT+qDpfZnx
SatLdt8GfQ85yA7hnWWJ2MxF3NaeSDm75Lsm+tBbAiyc9P2jGRNtMSkCgYEAypHd
HCctNi/FwjulhttFx/rHYKhLidZDFYeiE/v45bN4yFm8x7R/b0iE7KaszX+Exdvt
SghaTdcG0Knyw1bpJVyusavPzpaJMjdJ6tcFhVAbAjm7enCIvGCSx+X3l5SiWg0A
R57hJglezIiVjv3aGwHwvlZvtszK6zV6oXFAu0ECgYAbjo46T4hyP5tJi93V5HDi
Ttiek7xRVxUl+iU7rWkGAXFpMLFteQEsRr7PJ/lemmEY5eTDAFMLy9FL2m9oQWCg
R8VdwSk8r9FGLS+9aKcV5PI/WEKlwgXinB3OhYimtiG2Cg5JCqIZFHxD6MjEGOiu
L8ktHMPvodBwNsSBULpG0QKBgBAplTfC1HOnWiMGOU3KPwYWt0O6CdTkmJOmL8Ni
blh9elyZ9FsGxsgtRBXRsqXuz7wtsQAgLHxbdLq/ZJQ7YfzOKU4ZxEnabvXnvWkU
YOdjHdSOoKvDQNWu6ucyLRAWFuISeXw9a/9p7ftpxm0TSgyvmfLF2MIAEwyzRqaM
77pBAoGAMmjmIJdjp+Ez8duyn3ieo36yrttF5NSsJLAbxFpdlc1gvtGCWW+9Cq0b
dxviW8+TFVEBl1O4f7HVm6EpTscdDxU+bCXWkfjuRb7Dy9GOtt9JPsX8MBTakzh3
vBgsyi/sN3RqRBcGU40fOoZyfAMT8s1m/uYv52O6IgeuZ/ujbjY=
-----END RSA PRIVATE KEY-----
Here, we can see that, instead of a password, we have received an RSA private key, which we can use to log into bandit17. You’ll remember that we covered authenticating to an SSH server via a private key in the last post. We’ll discuss how to use it again in the next level. For now, copy the private key, including the lines beginning with “—–” and save it to a file on your local machine (not the SSH session).
Level 17 - Level 18
In this level, there are two files in the home directory: passwords.old and passwords.new. The password for the next level is in passwords.new and is the only line that has been changed between passwords.old and passwords.new.
Let’s begin by logging in using the RSA private key we found in the previous level. Before using the private key, we need to ensure that it has the correct permissions. ssh will refuse to use a key file if it is readable by others. You may have noticed file permissions in the left column of the ls -l output when we’ve used it before. Permissions are represented in two ways: as a string of characters (for example, rwx) and as three octal numbers (for example, 644).
The characters “rwx” stand for:
- r: read permission
- w: write permission
- x: execute permission
These permissions are displayed for the owner, group, and others in that order. For example, “-rw-r—–” means the owner has read and write permissions, the group has read permission, and others have no permissions.
Octal numbers represent these permissions using bits:
- r (read) is 4
- w (write) is 2
- x (execute) is 1
These values are added together to form the octal representation, for example:
- rwx is 4 + 2 + 1 = 7
- rw- is 4 + 2 = 6
- r– is 4
- — is 0
Therefore, the string “-rw-r—–” would be represented as 640 in octal.
We can change the permissions using the chmod command to 600 so that only the owner can read and write the file. I’ll assume you have named the private key file “sshkey.private":
$ chmod 600 sshkey.private
Now that the permissions are set, we can log in to the bandit17 account using the SSH key:
$ ssh -i sshkey.private [email protected] -p 2220
Note that if you’d like the actual password for this level rather than just the private key, you can retrieve it by using the “bandit_pass” directory that we used in level 13 - 14:
$ cat /etc/bandit_pass/bandit17
<password>
Now that we’re logged in, let’s start on the level. There should be two files in the home directory: passwords.old and passwords.new. First, let’s list the files in the home directory to confirm their presence:
$ ls -l
total 8
-rw-r----- 1 bandit18 bandit17 3300 Jun 20 04:06 passwords.new
-rw-r----- 1 bandit18 bandit17 3300 Jun 20 04:06 passwords.old
Our goal is to find the line that has been changed between these two files. To do this, we will use the diff command. diff is a command-line utility that compares files line by line and outputs the differences between them; hence its name. diff is used by passing it the names of the files you’d like to compare:
$ diff passwords.old passwords.new
42c42
< FtePUTiLiwPzjIFw2T7o57oBS4zUvPpg
---
> <password>
The top line of the output, “42c42”, means that line 42 in passwords.old has been changed to line 42 in passwords.new. Lines beginning with “<” indicate lines from passwords.old, and lines beginning with “>” indicate lines from passwords.new. “—” is simply a separator between the two files. Using this output, we can see that line 42 of passwords.old has been changed, and the equivalent line in passwords.new is our password to log into bandit18.
Level 18 - Level 19
In this level, the password for the next level is stored in a file named “readme” in the home directory. However, the .bashrc file has been edited to log you out immediately when you log in.
We can try logging in to see what happens. We get the usual welcome message, but we also see:
Byebye !
Connection to bandit.labs.overthewire.org closed.
There are a couple of methods we can use to bypass the problematic .bashrc file. Let’s explore both methods.
The first method is using a non-interactive session to prevent the file from being loaded. You can pass a command directly to ssh to be executed after logging in. No shell is being instantiated here, so no .bashrc file is loaded, bypassing the issue. We can use the cat command to read the contents of the readme file immediately upon login:
$ ssh [email protected] -p 2220 "cat readme"
<password>
The second method is to specify a different shell to use when logging in. A shell is a command-line interpreter that provides a user interface for access to an operating system’s services. Common shells include bash, sh, and zsh, although there are many more. When you log in via SSH, the server typically runs the default shell specified in the user’s configuration. The .bashrc file is a script that runs whenever the bash shell is started interactively; hence, we can determine that bandit18’s default shell is bash. The .bashrc file can contain commands, aliases, and environment variable definitions that configure the shell session to the user’s preference.
As we know that the shell being executed is bash, by telling ssh to start a different shell when logging in, we can avoid executing the .bashrc file that is specific to bash.
The -t option to ssh is used to force pseudo-terminal allocation (in other words, specifying the shell to use). We can ask ssh to use the sh shell as it is a rudimentary shell installed by default on most machines. We use the full path to sh, which is /bin/sh. The directory /bin/ is used to store most executable files.
$ ssh [email protected] -p 2220 -t /bin/sh
$ cat readme
<password>
Level 19 - Level 20
In this level, we need to gain access to the next level by using a setuid binary located in the home directory. The password for the next level is stored in the usual place (/etc/bandit_pass), and we’ll need to use the setuid binary to retrieve it.
First, let’s list the contents of the home directory to see the setuid binary:
$ ls -l
total 16
-rwsr-x--- 1 bandit20 bandit19 14880 Jun 20 04:07 bandit20-do
The output shows a file named bandit20-do with the setuid bit set. The setuid bit is represented by an “s” in the user execute permission position. The setuid (set user ID upon execution) permission allows a file to be executed with the privileges of the file owner rather than the user running the file. In this case, bandit20-do is owned by bandit20, so when you run it, it executes with the permissions of bandit20.
To find out how to use the setuid binary, execute it without any arguments, as suggested by the level description:
$ ./bandit20-do
Run a command as another user.
Example: ./bandit20-do id
You might wonder why we run bandit20-do as ./bandit20-do whereas we can run, for example, cat simply as cat. This difference is due to the PATH environment variable. The PATH is a list of directories the shell searches through to find executable files when you type a command. Common system commands like cat, ls, and grep are located in directories included in the PATH, such as /bin and /usr/bin, as we discussed before with sh. When you type cat, the shell looks through the PATH directories and finds the cat executable. However, the current directory is not included in the PATH by default for security reasons. Therefore, to run an executable in the current directory, explicitly specify the path by using ./ (where . represents the current directory). This ensures that you are executing the intended file from the current directory and not another command with the same name from a different directory in the PATH.
Using the information provided, we can use bandit20-do to read the password for the next level from /etc/bandit_pass/bandit20:
$ ./bandit20-do cat /etc/bandit_pass/bandit20
<password>
Thank you for taking the time to read this post, covering a step-by-step walkthrough on solving levels 15 - 19 of OverTheWire’s Bandit wargame. By getting this far, you’re over halfway through the game - congratulations! I hope you have found this post useful and are enjoying learning along with me. I’d love to hear your feedback; please feel free to email me directly and let me know how you’re finding the challenges and the walkthrough.
In the next post, we’ll be covering levels 20 through 24, which will see us learning about cron jobs as well as (spoiler) creating your first shell script. See you there!