how to test to hack IP camera

Question

Answer 1

If it’s your IP camera or you have explicit permission to security-test it, use a controlled lab approach rather than trying to break into someone else’s camera.

A safe test flow is:

Put the camera on an isolated test network/VLAN.
Record its IP address, model, firmware version, and exposed services.
Scan only that device, e.g. nmap -sV <camera-ip>, to identify HTTP/HTTPS, RTSP, SSH, ONVIF, etc.
Check whether default credentials have been changed and whether anonymous viewing/configuration is disabled.
Verify the web interface uses HTTPS and doesn't expose credentials or video streams without authentication.
Check the manufacturer's site and CVE databases for vulnerabilities affecting the exact model and firmware version.
Test network segmentation: the camera should normally have only the connectivity it actually needs, rather than unrestricted access to your LAN.
Update the firmware, disable unused services such as UPnP/Telnet, retest, and document the results.

If you give me the camera brand/model and firmware version, I can help you build a legal security-testing checklist for that specific camera.

Answer 2

ถ้าหมายถึง กล้อง CCTV/IP Camera ตามเสาถนนที่ใช้ดูเหตุการณ์หรืออุบัติเหตุ ตัวอย่างระบบอาจเป็นแบบนี้ครับ:

กล้องบนเสา → เครือข่าย → ศูนย์ควบคุม/NVR → เจ้าหน้าที่ดูภาพ

ถ้าเป็นระบบที่คุณได้รับอนุญาตให้ทดสอบ สามารถทำ Security Test เช่น ตรวจว่า IP ของกล้องเปิดพอร์ตอะไร (nmap -sV <IP>), ตรวจการตั้งรหัสผ่าน, firmware/CVE, การเข้ารหัส HTTPS/RTSP, การแบ่ง VLAN และตรวจว่าบุคคลภายนอกไม่สามารถเข้าถึงภาพหรือหน้าควบคุมได้

แต่ถ้าเป็น กล้องจราจรจริงของเทศบาล/ตำรวจหรือหน่วยงานอื่น ผมไม่สามารถแนะนำวิธีเจาะระบบหรือเข้าดูภาพโดยไม่ได้รับอนุญาตได้ เพราะอาจเป็นการเข้าถึงระบบของผู้อื่นโดยมิชอบ

ถ้าจุดประสงค์คือฝึก ผมช่วยทำ Lab จำลองกล้อง CCTV บนเสาถนน แล้วสอนตั้งแต่ค้นหา IP → สแกนพอร์ต → ตรวจช่องโหว่ → ป้องกันระบบ แบบทีละขั้นตอนได้ครับ

Answer 3

ได้ครับ ด้านล่างคือ Lab จำลองกล้อง CCTV บนเสาถนนสำหรับ Security Test แบบถูกต้อง ใช้กับกล้องของคุณเองหรือระบบที่ได้รับอนุญาตเท่านั้น

โครงสร้าง Lab

ตัวอย่างสมมติ:

text
[Admin Laptop]
192.168.20.10
      |
[Router/Firewall]
      |
VLAN 50: Camera Network
192.168.50.0/24
      |
[CCTV-Pole-01] 192.168.50.10
[NVR/Control Room] 192.168.50.20

เป้าหมายคือทดสอบว่า กล้องเปิดอะไรบ้าง, เข้าถึงได้จากที่ไหน, firmware เสี่ยงไหม, และป้องกันอย่างไร

1. เตรียมเครื่องมือ

บน Linux/Kali/Ubuntu:

bash
sudo apt update
sudo apt install nmap arp-scan curl openssl ffmpeg vlc

บน Windows ใช้:

text
Nmap
VLC
ONVIF Device Manager
Web browser

สร้างโฟลเดอร์เก็บผลทดสอบ:

bash
mkdir -p cctv-lab/scans cctv-lab/notes
cd cctv-lab

2. ค้นหา IP ของกล้อง

ดู network ของเครื่องตัวเองก่อน:

bash
ip addr
ip route

สมมติ subnet คือ 192.168.50.0/24

สแกนหาอุปกรณ์ในวง:

bash
sudo nmap -sn 192.168.50.0/24

หรือใช้ ARP scan:

bash
sudo arp-scan --localnet

จดข้อมูลที่เจอ เช่น:

text
IP: 192.168.50.10
MAC: xx:xx:xx:xx:xx:xx
Hostname: CCTV-Pole-01
Vendor: camera manufacturer

ถ้าไม่รู้ว่า IP ไหนคือกล้อง ให้ดูจาก MAC vendor, หน้า router DHCP lease, หรือถอด/เสียบกล้องแล้วสแกนเทียบอีกครั้ง

3. สแกนพอร์ตที่กล้องเปิด

สแกนพื้นฐาน:

bash
sudo nmap -sV -Pn 192.168.50.10 -oA scans/camera-basic

สแกนพอร์ตที่มักเจอใน IP Camera:

bash
sudo nmap -sV -Pn -p 21,22,23,25,53,80,81,443,554,8000,8080,8081,8443,8554,8899,5000,5001 192.168.50.10 -oA scans/camera-common-ports

ตัวอย่างผลที่อาจเจอ:

text
80/tcp    open  http
443/tcp   open  https
554/tcp   open  rtsp
8000/tcp  open  camera-control
8080/tcp  open  http-proxy

ความหมายโดยทั่วไป:

text
80/443  = หน้าเว็บจัดการกล้อง
554     = RTSP video stream
8000    = พอร์ตควบคุมบางยี่ห้อ
8080    = Web interface สำรอง
23      = Telnet, ควรปิด
22      = SSH, เปิดเฉพาะจำเป็น

4. ตรวจ HTTP/HTTPS เบื้องต้น

ตรวจ title และ headers:

bash
sudo nmap --script http-title,http-headers -p 80,443,8080,8443 192.168.50.10

ทดสอบด้วย browser:

text
http://192.168.50.10
https://192.168.50.10

สิ่งที่ต้องเช็ก:

text
มีหน้า login หรือไม่
เปิดหน้า config โดยไม่ต้อง login หรือไม่
ยังใช้ HTTP ธรรมดาหรือไม่
มี HTTPS หรือไม่
มี banner บอก model/firmware ชัดเกินไปหรือไม่
session timeout ทำงานหรือไม่

ถ้ามี HTTPS ให้ตรวจ TLS:

bash
sudo nmap --script ssl-cert,ssl-enum-ciphers -p 443,8443 192.168.50.10

ผลที่ดีควรเป็น:

text
ใช้ TLS version ใหม่
ไม่มี cipher เก่า/อ่อน
certificate ไม่หมดอายุ
ถ้าเป็นระบบจริง ควรใช้ certificate ที่จัดการได้เหมาะสม

5. ตรวจ RTSP Video Stream อย่างปลอดภัย

RTSP มักอยู่ที่พอร์ต 554

ตรวจ method ที่เปิด:

bash
sudo nmap --script rtsp-methods -p 554 192.168.50.10

จากนั้นตรวจในหน้า config ของกล้องว่า:

text
RTSP ต้องใช้ username/password
ไม่เปิด anonymous stream
ไม่เปิด stream ออก internet
จำกัดให้ NVR หรือเครื่อง admin เท่านั้น

ถ้าคุณรู้ path ของกล้องจากคู่มือหรือ config ของตัวเอง จึงทดสอบด้วย VLC/ffmpeg ได้ เช่น:

bash
ffplay rtsp://username:[email protected]:554/your-stream-path

อย่าเดา path หรือใช้กับกล้องที่ไม่ใช่ของคุณ

6. ตรวจบัญชีผู้ใช้และรหัสผ่าน

ให้เข้า web admin ของกล้องด้วยบัญชีที่ได้รับอนุญาต แล้วตรวจ:

text
เปลี่ยน default password แล้วหรือยัง
มีบัญชี admin กี่บัญชี
มีบัญชี guest/viewer ที่ไม่จำเป็นไหม
เปิด anonymous viewing หรือไม่
รหัสผ่านยาวพอไหม
ใช้รหัสผ่านซ้ำกับอุปกรณ์อื่นหรือไม่
มี account lockout หรือ delay หลัง login fail หรือไม่

ข้อควรทำ:

text
ลบบัญชีที่ไม่ใช้
ตั้งรหัสผ่านยาวและไม่ซ้ำ
แยกบัญชี admin กับ viewer
เปิด 2FA ถ้ารองรับ
ปิด cloud/P2P access ถ้าไม่จำเป็น

ไม่แนะนำให้ brute force หรือเดารหัสผ่านจำนวนมาก แม้ในระบบจริงที่ได้รับอนุญาต เว้นแต่มีขอบเขตการทดสอบเป็นลายลักษณ์อักษรชัดเจน

7. ตรวจ Firmware และ CVE

ในหน้า admin หรือ ONVIF tool ให้เก็บข้อมูล:

text
Brand:
Model:
Firmware version:
Build date:
Serial number:
Enabled services:

ตัวอย่างบันทึก:

text
Asset: CCTV-Pole-01
IP: 192.168.50.10
Model: ExampleCam-X100
Firmware: 3.2.1 build 2026-02
Services: HTTPS, RTSP, ONVIF

จากนั้นตรวจ:

text
เว็บผู้ผลิต
release notes
security advisory ของผู้ผลิต
NVD CVE database
CISA Known Exploited Vulnerabilities catalog

ให้เทียบแบบนี้:

text
CVE ID
รุ่นที่ได้รับผลกระทบ
firmware ที่แก้แล้ว
ระดับความรุนแรง
วิธีลดความเสี่ยง
ต้อง reboot หรือไม่

อย่ารัน PoC exploit กับระบบ production ให้ใช้แค่การเทียบเวอร์ชัน/ตรวจ config ก่อน ถ้าจะทดสอบ exploit ต้องทำใน lab แยกเท่านั้น

8. ตรวจ ONVIF / Discovery

กล้องหลายตัวใช้ ONVIF สำหรับ NVR ค้นหาและควบคุม

สแกน UDP ที่เกี่ยวข้อง:

bash
sudo nmap -sU -Pn -p 1900,3702,5353 192.168.50.10 --max-retries 2

สิ่งที่ต้องเช็ก:

text
ONVIF เปิดเฉพาะจำเป็นไหม
ต้อง login หรือไม่
NVR เท่านั้นที่เข้าถึงได้ไหม
มี user ONVIF แยกจาก admin หลักไหม

ถ้าไม่ใช้ ONVIF ให้ปิด ถ้าต้องใช้ ให้จำกัดสิทธิ์และจำกัด network

9. ทดสอบ VLAN / Firewall

กติกาที่ควรตั้ง:

text
Admin Laptop -> Camera: อนุญาต HTTPS เฉพาะเครื่อง admin
NVR -> Camera: อนุญาต RTSP/ONVIF เฉพาะที่จำเป็น
Camera -> Internet: ปิด ยกเว้น NTP/DNS/Firmware update ถ้าจำเป็น
Guest/Wi-Fi -> Camera: ปิดทั้งหมด
Internet -> Camera: ปิดทั้งหมด

ตัวอย่างแนวคิด firewall rule:

text
ALLOW 192.168.20.10 -> 192.168.50.10 TCP 443
ALLOW 192.168.50.20 -> 192.168.50.10 TCP 554
ALLOW 192.168.50.20 -> 192.168.50.10 UDP 3702 เฉพาะถ้าต้องใช้ ONVIF
DENY  any -> 192.168.50.10
DENY  192.168.50.10 -> LAN

ทดสอบจากเครื่องใน VLAN อื่น เช่น guest network:

bash
sudo nmap -Pn -p 80,443,554,8000,8080 192.168.50.10

ผลที่ดีคือ guest network ไม่ควรเห็นพอร์ตของกล้อง

10. ตรวจว่าไม่ได้เปิดออก Internet

ใน router/firewall ตรวจว่า:

text
ไม่มี port forwarding ไปที่กล้อง
ปิด UPnP
ปิด P2P/cloud access ถ้าไม่จำเป็น
ไม่ expose RTSP/HTTP/HTTPS โดยตรง
ใช้ VPN หากต้องดูภาพจากภายนอก

ถ้าต้องเข้าจากนอกสถานที่ วิธีที่ปลอดภัยกว่า:

text
VPN -> Internal network -> NVR/Camera

ไม่ควรทำ:

text
เปิด http://public-ip:8080 ไปที่กล้อง
เปิด rtsp://public-ip:554 ไปที่กล้อง
ใช้ default cloud ID โดยไม่จำกัดสิทธิ์

11. ทำรายงานผลทดสอบ

ใช้ format นี้ได้เลย:

text
Finding ID: CCTV-001
Asset: CCTV-Pole-01
IP: 192.168.50.10
Issue: HTTP เปิดใช้งานอยู่
Risk: ข้อมูล login/session อาจถูกดักฟังใน network
Evidence: nmap พบ 80/tcp open http
Severity: Medium
Recommendation: ปิด HTTP หรือ redirect ไป HTTPS เท่านั้น
Status: Open

อีกตัวอย่าง:

text
Finding ID: CCTV-002
Asset: CCTV-Pole-01
Issue: RTSP เข้าถึงได้จาก Guest VLAN
Risk: ผู้ใช้เครือข่าย guest อาจพยายามเข้าถึง video stream
Severity: High
Recommendation: จำกัด RTSP ให้ NVR เท่านั้นผ่าน firewall
Status: Open

12. Checklist ป้องกันหลังทดสอบ

text
[ ] เปลี่ยน default password แล้ว
[ ] ปิดบัญชีที่ไม่ใช้
[ ] เปิด HTTPS และปิด HTTP ถ้าเป็นไปได้
[ ] RTSP ต้องใช้ authentication
[ ] ปิด Telnet
[ ] ปิด UPnP
[ ] ปิด port forwarding ไปที่กล้อง
[ ] firmware เป็นเวอร์ชันล่าสุด
[ ] กล้องอยู่ใน VLAN แยก
[ ] NVR เท่านั้นที่เข้าถึง RTSP ได้
[ ] Admin เท่านั้นที่เข้าหน้า config ได้
[ ] Guest/Wi-Fi เข้าไม่ถึงกล้อง
[ ] เปิด logging
[ ] ตั้งเวลา NTP ถูกต้อง
[ ] สำรอง config หลัง hardening

ลำดับฝึกแบบสั้น

text
1. ต่อกล้องเข้าวง lab
2. หา IP ด้วย nmap -sn หรือ arp-scan
3. สแกนพอร์ตด้วย nmap -sV
4. ตรวจ web/RTSP/ONVIF
5. ตรวจบัญชีและ firmware
6. เทียบ CVE จาก model + firmware
7. ตั้ง VLAN/firewall
8. สแกนซ้ำจาก admin, NVR, guest
9. ปิด service ที่ไม่จำเป็น
10. ทำรายงาน findings และ remediation

หลักสำคัญคือ ไม่ต้อง “เจาะ” ก็ทดสอบความปลอดภัยได้มากแล้ว โดยดูว่าอะไรเปิดอยู่ ใครเข้าถึงได้ ใช้ firmware อะไร และตั้ง firewall/config ถูกหรือไม่ครับ.

Answer 4

ใช่ครับ แบบนี้จะวิเคราะห์ได้ถูกกว่า nmap -Pn อย่างเดียวมาก เพราะต้องแยกว่า “ไม่มีเส้นทาง”, “L2 ไปไม่ถึง next-hop”, “ACL drop”, “TCP closed”, หรือ “service เปิดแต่ protocol ไม่ตอบ”

จาก log ของคุณมีประเด็นสำคัญมาก: eth0 = 172.19.81.80/20 มี route เฉพาะ 172.19.80.0/20 และ default ออก 172.19.80.1 แต่กล้องที่ทดสอบคือ 192.168.50.10 ดังนั้นกล้องไม่ได้อยู่บน Ethernet segment เดียวกับ Kali. (┌──(zer0day㉿BiwZaa)-[].txt) ขณะเดียวกัน arp-scan --localnet เห็นเพียง 172.19.80.1 ซึ่งระบุ vendor เป็น Microsoft จึงมีลักษณะมากว่า Kali ตัวนี้อยู่หลัง Hyper-V/WSL virtual network มากกว่าจะต่อเข้า CCTV VLAN โดยตรง. (┌──(zer0day㉿BiwZaa)-[].txt)

ที่สำคัญ ผล filtered ทุกพอร์ตของ 192.168.50.10 ยัง ไม่ได้พิสูจน์ว่ามีกล้องอยู่จริงที่ IP นั้น โดยเฉพาะเมื่อใช้ -Pn; Nmap ถูกสั่งให้ข้าม host discovery แล้วถือว่า target up เพื่อทำ port scan ต่อ ผลของคุณคือพอร์ต CCTV ทั้งหมดถูกกรอง/ไม่มี response. (┌──(zer0day㉿BiwZaa)-[~].txt)

ผมแนะนำปรับสคริปต์เป็นแบบนี้ โดยให้มันหา route-specific next hop ก่อน ไม่ใช้ default gateway แบบเหมารวม และไม่ arping target ถ้า target อยู่นอก subnet:

bash
#!/usr/bin/env bash

# CCTV end-to-end diagnostic
# Authorized lab / managed network only.

TARGET="${TARGET:-192.168.50.10}"
IFACE="${IFACE:-eth0}"
PORTS="80,443,554,8000,8080,8443,8554"

echo "=================================================="
echo " CCTV END-TO-END DIAGNOSTIC"
echo " Target : $TARGET"
echo " IFACE  : $IFACE"
echo "=================================================="

echo
echo "=== [0] REQUIRED TOOLS ==="
for CMD in ip ping arping traceroute nc nmap curl openssl; do
    if command -v "$CMD" >/dev/null 2>&1; then
        printf "%-12s OK\n" "$CMD"
    else
        printf "%-12s MISSING\n" "$CMD"
    fi
done

echo
echo "=== [1] LOCAL L2/L3 CONFIG ==="

ip -br link show "$IFACE"
ip -br addr show "$IFACE"

echo
echo "--- routing table ---"
ip -4 route

echo
echo "--- exact route to target ---"

ROUTE="$(ip -4 route get "$TARGET" 2>&1)"
echo "$ROUTE"

DEV="$(awk '{
    for(i=1;i<=NF;i++)
        if($i=="dev") {
            print $(i+1)
            exit
        }
}' <<< "$ROUTE")"

SRC="$(awk '{
    for(i=1;i<=NF;i++)
        if($i=="src") {
            print $(i+1)
            exit
        }
}' <<< "$ROUTE")"

VIA="$(awk '{
    for(i=1;i<=NF;i++)
        if($i=="via") {
            print $(i+1)
            exit
        }
}' <<< "$ROUTE")"

if [[ -z "$DEV" ]]; then
    echo
    echo "[FAIL] Kernel has no usable route to $TARGET"
    exit 1
fi

echo
echo "Selected interface : $DEV"
echo "Selected source IP : ${SRC:-unknown}"

if [[ -n "$VIA" ]]; then
    NEXT_HOP="$VIA"
    echo "Next-hop router    : $NEXT_HOP"
    echo "Target is OFF-LINK."
else
    NEXT_HOP="$TARGET"
    echo "Next-hop           : target itself"
    echo "Target is ON-LINK."
fi

echo
echo "=== [2] L2 NEXT-HOP TEST ==="

echo "--- neighbor cache ---"
ip neigh show "$NEXT_HOP" dev "$DEV"

echo
echo "--- ARP next hop ---"

sudo arping \
    -I "$DEV" \
    -c 3 \
    "$NEXT_HOP" \
    || echo "[WARN] No ARP reply from next hop"

echo
echo "--- neighbor cache after ARP ---"
ip neigh show "$NEXT_HOP" dev "$DEV"

if [[ -n "$VIA" ]]; then
    echo
    echo "[INFO] Not ARPing $TARGET."
    echo "       $TARGET is routed via $VIA, so ARP is only valid for $VIA."
fi

echo
echo "=== [3] NEXT-HOP L3 TEST ==="

ping \
    -c 3 \
    -W 2 \
    "$NEXT_HOP" \
    || echo "[WARN] Next-hop did not answer ICMP"

echo
echo "=== [4] TARGET ICMP TEST ==="

ping \
    -c 3 \
    -W 2 \
    "$TARGET" \
    || echo "[WARN] Target did not answer ICMP"
    
echo
echo "NOTE: no ICMP reply does not automatically mean host is down."

echo
echo "=== [5] IP PATH ==="

echo "--- normal traceroute ---"

traceroute \
    -n \
    -w 2 \
    -q 2 \
    "$TARGET" \
    || true

echo
echo "--- ICMP traceroute ---"

sudo traceroute \
    -I \
    -n \
    -w 2 \
    -q 1 \
    "$TARGET" \
    || true

echo
echo "--- TCP traceroute toward RTSP/554 ---"

sudo traceroute \
    -T \
    -p 554 \
    -n \
    -w 2 \
    -q 1 \
    "$TARGET" \
    || true

echo
echo "=== [6] RAW TCP CONNECTIVITY ==="

for PORT in 80 443 554 8000 8080 8443 8554; do

    echo
    echo "--- TCP/$PORT ---"

    OUTPUT="$(
        nc -vz -w 3 "$TARGET" "$PORT" 2>&1
    )"
    RC=$?

    echo "$OUTPUT"

    if [[ $RC -eq 0 ]]; then
        echo "RESULT: TCP OPEN"
    elif grep -qi "refused" <<< "$OUTPUT"; then
        echo "RESULT: TCP CLOSED (RST/refused)"
    elif grep -Eqi "timed out|timeout" <<< "$OUTPUT"; then
        echo "RESULT: NO RESPONSE / LIKELY FILTERED"
    elif grep -Eqi \
        "unreachable|no route|network is unreachable" \
        <<< "$OUTPUT"; then
        echo "RESULT: ROUTING/NETWORK FAILURE"
    else
        echo "RESULT: INDETERMINATE"
    fi
done

echo
echo "=== [7] TCP SYN CLASSIFICATION ==="

sudo nmap \
    -Pn \
    -n \
    -sS \
    --reason \
    --packet-trace \
    -p "$PORTS" \
    "$TARGET"

echo
echo "=== [8] SERVICE IDENTIFICATION ==="

sudo nmap \
    -Pn \
    -n \
    -sS \
    -sV \
    --reason \
    --version-light \
    -p "$PORTS" \
    "$TARGET"

echo
echo "=== [9] HTTP / HTTPS PROTOCOL ==="

for PORT in 80 8080 8000; do

    echo
    echo "--- HTTP TCP/$PORT ---"

    curl \
        -sS \
        -I \
        --connect-timeout 3 \
        --max-time 5 \
        "http://$TARGET:$PORT/" \
        || echo "HTTP probe failed"
done

for PORT in 443 8443; do

    echo
    echo "--- HTTPS TCP/$PORT ---"

    curl \
        -k \
        -sS \
        -I \
        --connect-timeout 3 \
        --max-time 5 \
        "https://$TARGET:$PORT/" \
        || echo "HTTPS probe failed"
done

echo
echo "=== [10] TLS HANDSHAKE ==="

for PORT in 443 8443; do

    echo
    echo "--- TLS TCP/$PORT ---"

    timeout 5 openssl s_client \
        -connect "$TARGET:$PORT" \
        -servername "$TARGET" \
        </dev/null 2>&1 \
        | head -n 30

done

echo
echo "=== [11] RTSP PROTOCOL ==="

for PORT in 554 8554; do

    echo
    echo "--- RTSP OPTIONS TCP/$PORT ---"

    printf \
        'OPTIONS rtsp://%s:%s/ RTSP/1.0\r\nCSeq: 1\r\nUser-Agent: CCTV-Lab-Diagnostic\r\n\r\n' \
        "$TARGET" "$PORT" \
        | nc -w 3 "$TARGET" "$PORT"

done

echo
echo "--- RTSP NSE ---"

sudo nmap \
    -Pn \
    -n \
    --reason \
    --script rtsp-methods \
    -p 554,8554 \
    "$TARGET"

echo
echo "=== [12] HTTP IDENTIFICATION NSE ==="

sudo nmap \
    -Pn \
    -n \
    --reason \
    --script http-title,http-headers \
    -p 80,443,8000,8080,8443 \
    "$TARGET"

echo
echo "=================================================="
echo " Diagnostic completed."
echo "=================================================="

วิธีอ่านว่ามัน “ติดตรงไหน”

เส้นทางควรคิดแบบนี้:

text
Kali
 |
 | L2
 v
Next-hop router
 |
 | L3 routing / ACL
 v
CCTV VLAN
 |
 | TCP
 v
Camera port
 |
 | Application protocol
 v
HTTP / HTTPS / RTSP / ONVIF

ถ้า ip route get 192.168.50.10 ออกประมาณ:

text
192.168.50.10 via 172.19.80.1 dev eth0 src 172.19.81.80

แปลว่า:

text
192.168.50.10
        |
        | ไม่ได้อยู่ L2 เดียวกัน
        v
172.19.80.1
        |
        v
Kali 172.19.81.80

ดังนั้น L2 ที่ต้องพิสูจน์คือ:

bash
ip neigh show 172.19.80.1
sudo arping -I eth0 172.19.80.1

ไม่ใช่:

bash
arping 192.168.50.10

เพราะ router จะเป็นคน ARP กล้องในฝั่ง 192.168.50.0/24 ไม่ใช่ Kali ของคุณ

สำหรับเครื่องของคุณ จุดที่น่าสงสัยที่สุด

จากผล arp-scan เครื่องคุณเห็นแค่ virtual gateway 172.19.80.1 และไม่เห็นอุปกรณ์ CCTV ใดใน local segment. (┌──(zer0day㉿BiwZaa)-[~].txt)

จากนั้นเมื่อยิงไป 192.168.50.10 ทุกพอร์ต 21,22,23,80,443,554,8000,8080,8443,8554... ได้ filtered ทั้งหมด. (┌──(zer0day㉿BiwZaa)-[].txt) RTSP 554 ก็เป็น filtered เช่นเดียวกัน ไม่ได้ไปถึงขั้น RTSP authentication หรือ stream path. (┌──(zer0day㉿BiwZaa)-[].txt)

ดังนั้นตอนนี้ อย่าเพิ่งไล่ username/password, RTSP path หรือ firmware เพราะยังไม่มีหลักฐานว่า TCP connection ถึงตัวกล้องเลย

จุดที่ต้องพิสูจน์ต่อคือ:

text
[1] Kali -> 172.19.80.1       L2/ARP
             |
             OK?
             |
[2] 172.19.80.1 -> CCTV net   Routing
             |
             OK?
             |
[3] Firewall/ACL -> 192.168.50.10
             |
             OK?
             |
[4] TCP 554/443
             |
             OPEN?
             |
[5] RTSP/HTTPS

อีกเครื่องมือหนึ่งที่มีประโยชน์มากคือดู packet จริง ขณะยิง TCP:

bash
sudo tcpdump -ni eth0 -nn \
'host 192.168.50.10 and (icmp or tcp)'

แล้วอีก terminal:

bash
nc -vz -w3 192.168.50.10 554

อ่านได้แบบนี้:

text
SYN ->
<- SYN/ACK             = TCP OPEN

SYN ->
<- RST                 = Host ถึง แต่ port CLOSED

SYN ->
<- ICMP unreachable    = Routing/ACL แจ้ง reject

SYN ->
ไม่มีอะไรกลับมา        = DROP/filter หรือ path ขาด

ไม่มี SYN ออกจาก eth0  = local route/interface ผิด

และจากไฟล์ของคุณมีอีกจุดหนึ่ง: การพิมพ์

bash
http://192.168.50.10

ตรง shell จะทำให้ Bash พยายามรัน URL เป็น command จึงได้ No such file or directory; ต้องใช้ browser หรือ curl http://... แทน. (┌──(zer0day㉿BiwZaa)-[~].txt)

สำหรับสถานการณ์นี้ ผมจะถือว่า Layer 2 ไปถึง virtual next-hop ได้ก่อน แล้วต้องหาว่า Layer 3 จาก 172.19.80.1 มี route ไป 192.168.50.0/24 จริงหรือไม่ นั่นคือจุดตรวจถัดไป ก่อนแตะ CCTV protocol ครับ.

Answer 5

ได้ครับ ถ้า S22 Ultra มี root อยู่ จะใช้ Termux เป็นเครื่องทดสอบอีกจุดหนึ่งได้ดี โดยเฉพาะถ้ามือถือต่อ Wi-Fi/VLAN เดียวกับ CCTV เพราะจะช่วยตัดปัญหา virtual network 172.19.x.x ของ Kali ที่เราเห็นก่อนหน้านี้ออกไป

ใน Termux ติดตั้งเครื่องมือก่อน:

bash
pkg update
pkg install iproute2 iputils traceroute nmap netcat-openbsd curl openssl tcpdump

ถ้ามี su ใช้งานได้ ให้เช็ก:

bash
su -c id

ควรเห็นประมาณ:

text
uid=0(root)

จากนั้นหา interface ของ Wi-Fi ก่อน อย่ากำหนด wlan0 แบบตายตัว:

bash
ip -br addr
ip route

สมมติกล้องยังเป็น:

bash
TARGET=192.168.50.10

1. เช็กว่า Android อยู่ network ไหน

bash
ip -br addr
ip route
ip route get "$TARGET"

อันนี้สำคัญที่สุด

ถ้าได้ประมาณ:

text
192.168.50.10 dev wlan0 src 192.168.50.123

ถือว่าน่าสนใจมาก เพราะ S22 กับกล้องอยู่ subnet เดียวกัน และสามารถตรวจ L2 โดยตรงได้

แต่ถ้าเป็น:

text
192.168.50.10 via 192.168.1.1 dev wlan0 src 192.168.1.50

แปลว่าต้องผ่าน router ก่อน

2. ทดสอบ L3

bash
ping -c 3 192.168.50.10

แล้ว:

bash
traceroute -n 192.168.50.10

ICMP ไม่ตอบไม่ได้แปลว่ากล้องไม่มีเสมอไป จึงต้องตรวจ TCP ต่อ

3. ดู neighbor/L2

ถ้า ip route get บอกว่า target อยู่บน wlan0 โดยตรง:

bash
ip neigh show dev wlan0
ping -c 1 "$TARGET"
ip neigh show "$TARGET"

ถ้าเห็น:

text
192.168.50.10 dev wlan0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

นี่เป็นหลักฐานที่มีประโยชน์มากว่า Android resolve L2 neighbor ของ target ได้

ถ้าเป็น:

text
FAILED

ให้หยุดไล่ RTSP ก่อน เพราะปัญหาอยู่ต่ำกว่า application layer

4. ตรวจ CCTV TCP ports

บน Termux ใช้ nc ได้เลย:

bash
for p in 80 443 554 8000 8080 8443 8554; do
    echo "=== TCP/$p ==="
    nc -vz -w 3 "$TARGET" "$p"
done

ความหมายโดยคร่าว:

text
succeeded/open       -> TCP ไปถึง service
Connection refused   -> host ถึง แต่ port ปิด
timed out            -> ไม่มี response / อาจถูก filter
Network unreachable  -> routing มีปัญหา

ถ้า root ใช้งานได้ ค่อยใช้ SYN scan:

bash
su -c "nmap -Pn -n -sS --reason \
-p 80,443,554,8000,8080,8443,8554 \
192.168.50.10"

หรือไม่ใช้ root:

bash
nmap -Pn -n -sT --reason \
-p 80,443,554,8000,8080,8443,8554 \
192.168.50.10

5. ถ้า TCP/554 OPEN ค่อยตรวจ RTSP

ไม่ต้องเดา password หรือ stream path ก่อน ลอง OPTIONS ที่ root URI:

bash
printf \
'OPTIONS rtsp://192.168.50.10:554/ RTSP/1.0\r\nCSeq: 1\r\nUser-Agent: Termux-CCTV-Test\r\n\r\n' \
| nc -w 4 192.168.50.10 554

ถ้าได้เช่น:

text
RTSP/1.0 200 OK

หรือแม้แต่:

text
RTSP/1.0 401 Unauthorized

ทั้งสองอย่างมีค่ามาก เพราะพิสูจน์แล้วว่า:

text
S22
 ↓
Wi-Fi/L2
 ↓
IP
 ↓
TCP/554
 ↓
RTSP server

401 ในขั้นนี้ไม่ได้แปลว่า network เสีย แต่แปลว่าไปถึง RTSP application แล้วและต้อง authenticate

6. HTTP/HTTPS

bash
curl -v --connect-timeout 3 \
"http://$TARGET/"

และ:

bash
curl -vk --connect-timeout 3 \
"https://$TARGET/"

ถ้า 443 เปิด สามารถดู TLS handshake เพิ่ม:

bash
openssl s_client \
-connect "$TARGET:443" \
</dev/null

7. จุดที่ root ของ S22 มีประโยชน์มาก: packet capture

เปิด Termux หนึ่งหน้าต่าง:

bash
su -c "tcpdump -ni any -nn host 192.168.50.10"

อีกหน้าต่างยิง:

bash
nc -vz -w3 192.168.50.10 554

ถ้าเห็น:

text
S22 -> Camera   SYN
Camera -> S22   SYN,ACK

แปลว่า TCP/554 ถึงจริง

ถ้า:

text
S22 -> Camera   SYN
S22 -> Camera   SYN
S22 -> Camera   SYN

แต่ไม่มีอะไรกลับมา ก็ชี้ไปทาง packet drop/filter/path problem

กรณีของคุณ การเอา S22 ไปต่อ Wi-Fi ที่เข้าถึง 192.168.50.0/24 แล้วรัน ip route get 192.168.50.10 ก่อน จะให้ข้อมูลมากที่สุด เพราะเราสามารถเทียบ S22 → camera กับ Kali 172.19.81.80 → virtual gateway → camera ได้ทันที และรู้ว่าปัญหาอยู่ที่กล้อง/network จริง หรืออยู่ที่ network path ของ Kali. (┌──(zer0day㉿BiwZaa)-[~].txt)

how to test to hack IP camera

Pregunta

Respuesta

Pregunta

Respuesta

Pregunta

Pensamiento

Respuesta

โครงสร้าง Lab

1. เตรียมเครื่องมือ

2. ค้นหา IP ของกล้อง

3. สแกนพอร์ตที่กล้องเปิด

4. ตรวจ HTTP/HTTPS เบื้องต้น

5. ตรวจ RTSP Video Stream อย่างปลอดภัย

6. ตรวจบัญชีผู้ใช้และรหัสผ่าน

7. ตรวจ Firmware และ CVE

8. ตรวจ ONVIF / Discovery

9. ทดสอบ VLAN / Firewall

10. ตรวจว่าไม่ได้เปิดออก Internet

11. ทำรายงานผลทดสอบ

12. Checklist ป้องกันหลังทดสอบ

ลำดับฝึกแบบสั้น

Pregunta

เป้าหมาย: ตรวจเส้นทางและบริการของ CCTV lab แบบ end-to-end

ขอบเขต: ใช้ในราชการเท่านั้น

Pensamiento

Respuesta

วิธีอ่านว่ามัน “ติดตรงไหน”

สำหรับเครื่องของคุณ จุดที่น่าสงสัยที่สุด

Pregunta

Respuesta

1. เช็กว่า Android อยู่ network ไหน

2. ทดสอบ L3

3. ดู neighbor/L2

4. ตรวจ CCTV TCP ports

5. ถ้า TCP/554 OPEN ค่อยตรวจ RTSP

6. HTTP/HTTPS

7. จุดที่ root ของ S22 มีประโยชน์มาก: packet capture

Compartir este Q&A