# ADT Security Assessment
This documentation examines my home ADT security system from an attacker's perspective. The goal is to identify security weaknesses, enumerate potential entry points, and develop a comprehensive attack methodology that could lead to unauthorized access to the central security hub.
## Identifying The Target
I started out by opening up my Kali Linux VM and identifying my host IP address and subnet mask, to determine my range of IP addresses to scan.
```
$ ifconfig | grep inet
inet 192.168.1.137 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fd00:7437:5f90:df74:a00:27ff:feaa:836d prefixlen 64 scopeid 0x0<global>
inet6 fd00:7437:5f90:df74:bde9:848b:94f:1a3f prefixlen 64 scopeid 0x0<global>
inet6 2603:6080:90f0:ef70::197b prefixlen 128 scopeid 0x0<global>
inet6 2603:6080:90f0:ef70:35b6:fb73:168:456 prefixlen 64 scopeid 0x0<global>
inet6 fe80::a00:27ff:feaa:836d prefixlen 64 scopeid 0x20<link>
inet6 2603:6080:90f0:ef70:a00:27ff:feaa:836d prefixlen 64 scopeid 0x0<global>
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
```
After this I ran a service scan on my network to identify the IP address of my target through service enumeration. I wanted to look for services and keywords that could be indicitave of an ADT security system.
```
nmap -sV 192.168.1.0/24
Starting Nmap 7.95 ( https://nmap.org ) at 2025-08-17 11:08 EDT
Nmap scan report for SAX1V1R.lan (192.168.1.1)
Host is up (0.0039s latency).
Not shown: 997 closed tcp ports (reset)
PORT STATE SERVICE VERSION
53/tcp open domain Cloudflare public DNS
80/tcp open http lighttpd 1.4.59
443/tcp open ssl/http lighttpd 1.4.59
MAC Address: 74:37:5F:90:DF:74 (Sercomm Philippines)
Nmap scan report for hon-grip-generic.lan (192.168.1.20)
Host is up (0.010s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
80/tcp open http lighttpd 1.4.54
443/tcp open ssl/http lighttpd 1.4.54
MAC Address: 48:A2:E6:C3:D8:3F (Resideo)
Nmap scan report for lwip0.lan (192.168.1.21)
Host is up (0.0081s latency).
Not shown: 999 closed tcp ports (reset)
PORT STATE SERVICE VERSION
6668/tcp open irc?
MAC Address: C4:82:E1:08:7F:15 (Tuya Smart)
```
After further enumeration of the service scan information, I identified the MAC vendor Resideo. Resideo manufactures Honeywell/Resideo smart home and IoT devices, including alarm systems. This finding suggests the .20 address is likely the ADT system, particularly given that it's running HTTP/HTTPS services, which are common for IoT web interfaces.
**Next Steps**
After Identifying the target IP as 192.168.1.20, and understanding it is running a web interface, I wanted to find out more about that. I ran the tool whatweb as a way to fingerprint the website and found this information.
```
whatweb 192.168.1.20
http://192.168.1.20 [401 Unauthorized] Country[RESERVED][ZZ], HTTPServer[lighttpd/1.4.54], IP[192.168.1.20], Title[401 Unauthorized], WWW-Authenticate[Password Protected][Digest], lighttpd[1.4.54]
```
The output provided valuable information. Access to the web interface requires authentication, as indicated by the 401 Unauthorized response. The service is running lighttpd 1.4.54, which is significantly outdated compared to the current version of lighttpd 1.4.80.
> My first thought is to find a way to brute force this digest authentication, we will try that after some further enumeration.
**Fingerprinting**
Next, I wanted to take the OS fingerprinting route. An outdated operating system or kernel can lead to several critical vulnerabilities that are exploitable; making this a value area to check out.
> I ran an aggresive scan with nmap to get further information.
```
$ nmap -A -sV 192.168.1.20
Starting Nmap 7.95 ( https://nmap.org ) at 2025-08-18 17:05 EDT
Nmap scan report for hon-grip-generic.lan (192.168.1.20)
Host is up (0.0097s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
80/tcp open http lighttpd 1.4.54
| http-auth:
| HTTP/1.1 401 Unauthorized\x0D
|_ Digest qop=auth realm=Password Protected nonce=68a35d52:28abc712872042b66669daf96f837fe4 algorithm=MD5 charset=UTF-8
|_http-server-header: lighttpd/1.4.54
|_http-title: 401 Unauthorized
443/tcp open ssl/http lighttpd 1.4.54
|_http-server-header: lighttpd/1.4.54
|_ssl-date: TLS randomness does not represent time
| tls-alpn:
| http/1.0
|_ http/1.1
| ssl-cert: Subject: commonName=172.25.50.1/organizationName=Internet Widgits Pty Ltd/stateOrProvinceName=Some-State/countryName=AU
| Not valid before: 2018-06-05T18:03:33
|_Not valid after: 2043-05-30T18:03:33
| http-auth:
| HTTP/1.1 401 Unauthorized\x0D
|_ Digest qop=auth realm=Password Protected nonce=68a35d54:1e37ad5358b5183b2709648c9882c9dc algorithm=MD5 charset=UTF-8
|_http-title: 401 Unauthorized
MAC Address: 48:A2:E6:C3:D8:3F (Resideo)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 3.10 - 4.11 (93%), Linux 3.2 - 4.14 (93%), Linux 3.18 (90%), Android 4.1.1 (87%), Linux 4.4 (87%), OpenWrt 19.07 (Linux 4.14) (87%), OpenWrt 18 (Linux 4.14) (87%), Linux 2.6.32 (87%), Linux 2.6.32 - 3.13 (87%), Linux 4.15 - 5.19 (87%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
TRACEROUTE
HOP RTT ADDRESS
1 9.71 ms hon-grip-generic.lan (192.168.1.20)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 45.74 seconds
```
This scan provided valuable information that kinda took me down a rabbit hole. From these results I determined the system is probably running Linux 3.x – 4.x, due to the multiple kernels listed. These versions have multiple CVE's associated with them, and if its the 2.6.32 than it has even more. Either way this isnt looking good for ADT security.
> Now I have my sights on identifying exactly what kernel is being used.
I used this nmap script in attempt to leak some OS information but it wasnt too successful.
```
$ nmap -p80,443 --script http-server-header,http-headers,http-title 192.168.1.20
Starting Nmap 7.95 ( https://nmap.org ) at 2025-08-18 17:17 EDT
Nmap scan report for hon-grip-generic.lan (192.168.1.20)
Host is up (0.0055s latency).
PORT STATE SERVICE
80/tcp open http
|_http-title: 401 Unauthorized
| http-headers:
| WWW-Authenticate: Digest realm="Password Protected", charset="UTF-8", algorithm="MD5", nonce="68a36025:0c9e70c6732b7a32963d6de5a89d4300", qop="auth"
| Content-Type: text/html
| Content-Length: 347
| Connection: close
| Date: Mon, 18 Aug 2025 17:17:25 GMT
| Server: lighttpd/1.4.54
|
|_ (Request type: GET)
|_http-server-header: lighttpd/1.4.54
443/tcp open https
|_http-server-header: lighttpd/1.4.54
| http-headers:
| WWW-Authenticate: Digest realm="Password Protected", charset="UTF-8", algorithm="MD5", nonce="68a3601d:78a6308392b8e9ece90be85ccd4835ef", qop="auth"
| Content-Type: text/html
| Content-Length: 347
| Connection: close
| Date: Mon, 18 Aug 2025 17:17:17 GMT
| Server: lighttpd/1.4.54
|
|_ (Request type: GET)
|_http-title: 401 Unauthorized
MAC Address: 48:A2:E6:C3:D8:3F (Resideo)
Nmap done: 1 IP address (1 host up) scanned in 14.43 seconds
```
> After a couple other attempts, still no luck.. but thats when I decided to pivot and think;
The hub and camera are interconnected on the same network. The hub acts as the central controller, while the camera registers with it and streams video over RTSP.
The hub manages authentication, configuration, and relays video to the cloud or user app, while the camera trusts the hub for commands and updates. This creates a trust relationship where compromising one device could provide a path to pivot into the hub!
> I ran this aggressive scan on the prospective camera. I believe its the camera since its running Real Time Streaming Protocol (RTSP), which is common for IP cameras.
```
$ nmap -A 192.168.1.125
Starting Nmap 7.95 ( https://nmap.org ) at 2025-08-18 17:39 EDT
Nmap scan report for SC156D47.lan (192.168.1.125)
Host is up (0.012s latency).
Not shown: 997 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
53/tcp closed domain
554/tcp open rtsp
|_rtsp-methods: OPTIONS,DESCRIBE,GET_PARAMETER,SETUP,SET_PARAMETER,PLAY,PING,PAUSE,TEARDOWN
| fingerprint-strings:
| FourOhFourRequest, GetRequest:
| RTSP/1.0 404 Not Found
| Cseq: 0
| HTTPOptions, RTSPRequest:
| RTSP/1.0 200 OK
| Cseq: 0
| Public: OPTIONS,DESCRIBE,GET_PARAMETER,SETUP,SET_PARAMETER,PLAY,PING,PAUSE,TEARDOWN
| SIPOptions:
| RTSP/1.0 200 OK
| Cseq: 42
|_ Public: OPTIONS,DESCRIBE,GET_PARAMETER,SETUP,SET_PARAMETER,PLAY,PING,PAUSE,TEARDOWN
843/tcp open unknown
| fingerprint-strings:
| DNSStatusRequestTCP, GenericLines, GetRequest, HTTPOptions, Help, LANDesk-RC, LDAPBindReq, LPDString, NCP, RTSPRequest, TerminalServer, X11Probe:
|_ <cross-domain-policy><site-control permitted-cross-domain-policies="*"/><allow-access-from domain="*" to-ports="*" /></cross-domain-policy>
2 services unrecognized despite returning data. If you know the service/version, please submit the following fingerprints at https://nmap.org/cgi-bin/submit.cgi?new-service :
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
SF-Port554-TCP:V=7.95%I=7%D=8/18%Time=68A39DC4%P=x86_64-pc-linux-gnu%r(Get
SF:Request,23,"RTSP/1\.0\x20404\x20Not\x20Found\r\nCseq:\x200\r\n\r\n")%r(
SF:RTSPRequest,71,"RTSP/1\.0\x20200\x20OK\r\nCseq:\x200\r\nPublic:\x20OPTI
SF:ONS,DESCRIBE,GET_PARAMETER,SETUP,SET_PARAMETER,PLAY,PING,PAUSE,TEARDOWN
SF:\r\n\r\n")%r(HTTPOptions,71,"RTSP/1\.0\x20200\x20OK\r\nCseq:\x200\r\nPu
SF:blic:\x20OPTIONS,DESCRIBE,GET_PARAMETER,SETUP,SET_PARAMETER,PLAY,PING,P
SF:AUSE,TEARDOWN\r\n\r\n")%r(FourOhFourRequest,23,"RTSP/1\.0\x20404\x20Not
SF:\x20Found\r\nCseq:\x200\r\n\r\n")%r(SIPOptions,72,"RTSP/1\.0\x20200\x20
SF:OK\r\nCseq:\x2042\r\nPublic:\x20OPTIONS,DESCRIBE,GET_PARAMETER,SETUP,SE
SF:T_PARAMETER,PLAY,PING,PAUSE,TEARDOWN\r\n\r\n");
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
SF-Port843-TCP:V=7.95%I=7%D=8/18%Time=68A39DBF%P=x86_64-pc-linux-gnu%r(Gen
SF:ericLines,8B,"<cross-domain-policy><site-control\x20permitted-cross-dom
SF:ain-policies=\"\*\"/><allow-access-from\x20domain=\"\*\"\x20to-ports=\"
SF:\*\"\x20/></cross-domain-policy>")%r(GetRequest,8B,"<cross-domain-polic
SF:y><site-control\x20permitted-cross-domain-policies=\"\*\"/><allow-acces
SF:s-from\x20domain=\"\*\"\x20to-ports=\"\*\"\x20/></cross-domain-policy>"
SF:)%r(HTTPOptions,8B,"<cross-domain-policy><site-control\x20permitted-cro
SF:ss-domain-policies=\"\*\"/><allow-access-from\x20domain=\"\*\"\x20to-po
SF:rts=\"\*\"\x20/></cross-domain-policy>")%r(RTSPRequest,8B,"<cross-domai
SF:n-policy><site-control\x20permitted-cross-domain-policies=\"\*\"/><allo
SF:w-access-from\x20domain=\"\*\"\x20to-ports=\"\*\"\x20/></cross-domain-p
SF:olicy>")%r(DNSStatusRequestTCP,8B,"<cross-domain-policy><site-control\x
SF:20permitted-cross-domain-policies=\"\*\"/><allow-access-from\x20domain=
SF:\"\*\"\x20to-ports=\"\*\"\x20/></cross-domain-policy>")%r(Help,8B,"<cro
SF:ss-domain-policy><site-control\x20permitted-cross-domain-policies=\"\*\
SF:"/><allow-access-from\x20domain=\"\*\"\x20to-ports=\"\*\"\x20/></cross-
SF:domain-policy>")%r(X11Probe,8B,"<cross-domain-policy><site-control\x20p
SF:ermitted-cross-domain-policies=\"\*\"/><allow-access-from\x20domain=\"\
SF:*\"\x20to-ports=\"\*\"\x20/></cross-domain-policy>")%r(LPDString,8B,"<c
SF:ross-domain-policy><site-control\x20permitted-cross-domain-policies=\"\
SF:*\"/><allow-access-from\x20domain=\"\*\"\x20to-ports=\"\*\"\x20/></cros
SF:s-domain-policy>")%r(LDAPBindReq,8B,"<cross-domain-policy><site-control
SF:\x20permitted-cross-domain-policies=\"\*\"/><allow-access-from\x20domai
SF:n=\"\*\"\x20to-ports=\"\*\"\x20/></cross-domain-policy>")%r(LANDesk-RC,
SF:8B,"<cross-domain-policy><site-control\x20permitted-cross-domain-polici
SF:es=\"\*\"/><allow-access-from\x20domain=\"\*\"\x20to-ports=\"\*\"\x20/>
SF:</cross-domain-policy>")%r(TerminalServer,8B,"<cross-domain-policy><sit
SF:e-control\x20permitted-cross-domain-policies=\"\*\"/><allow-access-from
SF:\x20domain=\"\*\"\x20to-ports=\"\*\"\x20/></cross-domain-policy>")%r(NC
SF:P,8B,"<cross-domain-policy><site-control\x20permitted-cross-domain-poli
SF:cies=\"\*\"/><allow-access-from\x20domain=\"\*\"\x20to-ports=\"\*\"\x20
SF:/></cross-domain-policy>");
MAC Address: 3C:62:F0:15:6D:47 (Sercomm)
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.2 - 3.16
Network Distance: 1 hop
TRACEROUTE
HOP RTT ADDRESS
1 12.09 ms SC156D47.lan (192.168.1.125)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 55.26 seconds
```
> The very first thing that stood out to me
>
This linux kernel is extremely outdated, 3.2-3.16 is from around 2012-2014, there are many known privelege escalation CVE's associated with this kernel, as well as other attack methods. Some of these CVE's are listed below.
* CVE-2016-5195 ("Dirty COW") – A privilege escalation vulnerability in the Linux kernel’s copy-on-write mechanism allowing unprivileged users to gain root access.
* CVE-2017-7533 – A race condition in Linux’s inotify subsystem that allows local users to perform privileged file operations and escalate privileges.
* CVE-2017-1000253 – A flaw in the Linux kernel’s memory management (mm subsystem) that enables attackers to escalate privileges via crafted memory mapping operations.
* CVE-2017-7308 – A vulnerability in Linux’s packet socket (AF_PACKET) implementation allowing local attackers to execute arbitrary code with elevated privileges.
* CVE-2016-0728 – A use-after-free vulnerability in Linux’s keyring facility that lets local users escalate privileges to root.
* CVE-2015-1328 – An overlayfs privilege escalation in Ubuntu’s Linux kernel allowing local users to gain administrative access.
> The next thing I noticed!
After some research into the large output from port 843, I found that it is the there is a serious misconfiguration. It basically tells Flash clients that any domain can request resources from this device. This means there are no restrictions on who can ask the camera for data!!! The Asterics signify this.
```
<cross-domain-policy>
<site-control permitted-cross-domain-policies="*"/>
<allow-access-from domain="*" to-ports="*" />
</cross-domain-policy>
```
> There are also many legacy vulnerabilities that could lead to pivoting to the main ADT hub. This IP camera is the weak link for sure.
>
Now I am going to circle back to RTSP enumeration, to see if I can potentially brute force the digest authentication. I used hydra, and crafted a custom wordlists for this IP camera.
```
hydra -L users.txt -P passwords.txt rtsp://192.168.1.125:554
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2025-08-19 14:07:22
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 16 tasks per 1 server, overall 16 tasks, 720 login tries (l:15/p:48), ~45 tries per task
[DATA] attacking rtsp://192.168.1.125:554/
[INFO] Server does not need credentials
[554][rtsp] host: 192.168.1.125 login: admin password: 12345678
[INFO] Server does not need credentials
[554][rtsp] host: 192.168.1.125 login: admin password: 123456789
[INFO] Server does not need credentials
[554][rtsp] host: 192.168.1.125 login: admin password: root
[INFO] Server does not need credentials
[554][rtsp] host: 192.168.1.125 login: admin password: 1234567890
[INFO] Server does not need credentials
[554][rtsp] host: 192.168.1.125 login: admin password: admin
[INFO] Server does not need credentials
[554][rtsp] host: 192.168.1.125 login: admin password: 0000
[INFO] Server does not need credentials
[554][rtsp] host: 192.168.1.125 login: admin password: 123456
[INFO] Server does not need credentials
[554][rtsp] host: 192.168.1.125 login: admin password: 1111
[INFO] Server does not need credentials
[554][rtsp] host: 192.168.1.125 login: admin password: 1234567
[INFO] Server does not need credentials
[554][rtsp] host: 192.168.1.125 login: admin password: password
[INFO] Server does not need credentials
[554][rtsp] host: 192.168.1.125 login: admin password: 12345
```
This output was very telling! Notice how it says server does not need credentials... this means it is allowing anyone on the network to connect. This is an even bigger misconfiguration than port 843.
> I attempted to use the VLC command to open the stream
```
$ vlc rtsp://192.168.1.125:554/livestream
VLC media player 3.0.21 Vetinari (revision 3.0.21-0-gdd8bfdbabe8)
```
This output confirms that there is unauthenticated video access, and that there is a working RTSP stream. I wanted to gather more information using the curl command so I did as followed.
```
$ curl -v rtsp://192.168.1.125:554/livestream
* Trying 192.168.1.125:554...
* Connected to 192.168.1.125 (192.168.1.125) port 554
> OPTIONS * RTSP/1.0
> CSeq: 1
> User-Agent: curl/8.12.1
>
* Request completely sent off
< RTSP/1.0 200 OK
< Cseq: 1
< Public: OPTIONS,DESCRIBE,GET_PARAMETER,SETUP,SET_PARAMETER,PLAY,PING,PAUSE,TEARDOWN
<
* Connection #0 to host 192.168.1.125 left intact
```
> This confirms what capabilities are available to unauthenticated users, such as OPTIONS, DESCRIBE, GET_PARAMETER, etc. These paramters allow for access to footage, technical configurations of the device, and overall camera functions.
# Summary
This documentation examines the vulnerabilities discovered during my home ADT security system assessment. The goal was to identify security weaknesses and enumerate potential entry points that could lead to unauthorized access to the central security hub.
**Target Identification Summary**
Through network reconnaissance, I identified two primary targets within my ADT security infrastructure.
## Primary Targets
> Security Hub: 192.168.1.20 (Resideo/Honeywell) - Central control unit
> IP Camera: 192.168.1.125 (Sercomm) - Video surveillance device
The IP camera emerged as the primary attack vector due to multiple critical security flaws.
```
Critical Vulnerability Findings
IP Camera (192.168.1.125) - CRITICAL RISK
Complete Authentication Bypass
```
The most severe finding was the complete absence of authentication on the RTSP service. My testing with Hydra revealed that the camera responds with "Server does not need credentials" for any login attempt. This means..
* Any network user can access live video streams
* No password or authentication mechanism exists
* Direct access via vlc rtsp://192.168.1.125:554/livestream succeeds immediately
**Severely Outdated Linux Kernel**
Nmap OS detection revealed the camera is running Linux kernel 3.2-3.16, which dates back to 2012-2014. This 11+ year old kernel contains multiple critical privilege escalation vulnerabilities:
```
Key CVEs Present:
CVE-2016-5195 (Dirty COW) - Race condition allowing privilege escalation to root
CVE-2017-7533 - inotify race condition for privileged file operations
CVE-2017-1000253 - Memory management flaw enabling code execution
CVE-2017-7308 - Packet socket vulnerability allowing arbitrary code execution
CVE-2016-0728 - Keyring use-after-free leading to root access
CVE-2015-1328 - OverlayFS privilege escalation
```
These vulnerabilities have well-documented, publicly available exploits that would allow an attacker to gain root access on the camera system.
**Dangerous Cross-Domain Policy**
Port 843 analysis revealed an extremely permissive Flash cross-domain policy. The wildcard (*) configuration allows any external domain to request resources from the camera, creating potential for cross-site request forgery attacks.
### Security Hub (192.168.1.20) - HIGH RISK
**Outdated Web Server**
The security hub runs lighttpd 1.4.54, which is significantly behind the current version (1.4.80). This represents 26 version releases and approximately 5+ years of unpatched security vulnerabilities.
**Weak Digest Authentication**
Web interface analysis showed HTTP Digest authentication using MD5 algorithm, which is cryptographically weak and susceptible to-
* Brute force attacks
* Hash collision attacks
* Replay attacks due to predictable nonce generation
**Potentially Vulnerable OS**
OS fingerprinting suggests Linux 3.10-4.11 range, which may contain additional kernel-level vulnerabilities depending on the exact version.
### Attack Surface Analysis
The most concerning discovery is that the IP camera is essentially wide open to attack. Anyone who gains access to my network can immediately start watching my security camera feeds because there's no password or authentication whatsoever. What makes this worse is that the camera is running an ancient Linux kernel from 2012-2014 that has multiple well-known security holes that attackers can exploit to take complete control of the device.
Once someone compromises the camera, they can potentially use it as a stepping stone to attack the main security hub. The camera and hub communicate with each other, so an attacker could potentially impersonate the camera or intercept their communications to gain access to the central system.
The security hub itself also has problems. It's running outdated web server software that hasn't been updated in years, leaving it vulnerable to various attacks. The login system uses an old MD5-based authentication method that can be cracked with enough time and computing power.
**Risk Assessment**
This situation is extremely dangerous from a security perspective. The vulnerabilities I found don't require advanced hacking skills to exploit, the camera access requires no technical knowledge at all since there's no authentication. The kernel exploits have been public knowledge for years with step by step instructions available online. Basically, anyone with basic computer skills and network access could potentially compromise my entire security system.
The impact would be devastating. An attacker could watch my camera feeds in real time, potentially disable my security monitoring, and gain insight into my daily routines and when I'm home or away. This represents a serious privacy violation and could enable physical security threats.
Sign in with Wallet
Connect another wallet