IP camera verzendt data naar vreemde servers

Ik heb hier thuis een IP camera. Uiteraard netjes ingesteld, wachtwoorden en usernames aangepast, poorten geforward, etcetera.
Uit pure nieuwsgierigheid heb ik de camera afgelopen week eens aangesloten op 1 van mijn "aangepaste" routers (DDWRT firmware) om de data te bekijken die wordt gegenereerd als je op de IP camera inlogt.

Wat me vervolgens opviel, is dat de IP camera uit zichzelf constant data verzendt naar 3 IP adressen, hieronder volgt een kleine greep uit de in totaal 8114(!!!) keren dat de camera in de afgelopen 24 uur een poging heeft gedaan om verbinding te maken met de 3 vreemde servers:

(Het klopt dat ze op accept staan, hier kom ik zo op terug)

139.129.55.215
Een server in China, eigendom van dezelfde mensen als de AliBaba website.Waarschijnlijk een server van de fabrikant voor meldingen over software updates, doen meer apparaten.

De 2 andere IP's kan ik minder makkelijk rijmen:

54.214.22.83
Een Amazon server in Oregon (VS)

202.181.238.4
Een server in Hong Kong.

Het is me totaal onbekend wat er naar deze servers wordt verzonden. Wachtwoorden? Beelden van de camera? Alle 3 de servers ontvangen in ieder geval data op hetzelfde poortnummer.

Ik heb sinds gisteren via de router ingesteld dat deze data niet mag worden doorgelaten; zowel de server IP's als de betreffende poort (32100) waar naar verzonden wordt zijn nu dicht (vanuit de router dus). Ook maar email alerts ingesteld zodra iemand de webcam wil bekijken, zodat de tijd en IP's opgeslagen worden.
(in eerste instantie liet ik DDWRT alles droppen naar de externe servers, maar ik heb het nu via mijn hoofdrouter ingesteld, vandaar dat in de DDWRT logs alles nog op ACCEPT staat)

Het wordt vreemder:
Afgelopen middag is er dus een poging gedaan vanuit Hong Kong (een ander IP adres dan de server overigens) in te loggen op de camera. Wtf?
Er komen meer hits voorbij overigens, waarschijnlijk bots: 1 hit en het IP verdwijnt weer, maar dit waren er meer, ook al duurde het maar een paar seconden:


Volgende stap:
Proberen te achterhalen wat er precies verzonden wordt, al ben ik er nog niet helemaal over uit hoe. Ik denk dat ik alle verzonden packets laat kopieren vanuit DDWRT naar een 2e IP (dmv IPtables), waarop ik luister met Wireshark.

Meedenken wordt gewaardeerd!

[ Bericht 0% gewijzigd door NielsTriple op 06-10-2017 18:53:19 ]

quote:

Op vrijdag 6 oktober 2017 21:28 schreef DJSmiley het volgende:
Camera met cloud functie die default aan staat?

Of een eigen dyndns achtige functie die standaard aan staat?

Cloud is geen onderdeel van deze cam. DDNS optie is aanwezig, maar niet ingesteld (al weet ik niet wat er door de fabrikant zelf aan DDNS is ingebouwd)

Update:
Telnet bitches!
Zit nu de broncode door te spitten

quote:

Op vrijdag 6 oktober 2017 21:39 schreef ACT-F het volgende:
tcpdump

Google naar de mogelijkheden en laat specifiek het verkeer naar je camera loggen. Genereer gelijk een bestandsnaam met de extensie .cap zodat je het gelijk met Wireshark kan analyseren.

Ik heb mijn PC aan dezelfde router gehangen, als Angry IP Scanner zo klaar is, ga ik wireshark aanslingeren.

quote:

Op vrijdag 6 oktober 2017 21:53 schreef DJSmiley het volgende:
Wiresharken zou ik idd zeggen.
DDWRT lijkt een soort mirror functie te hebben:

https://www.question-defe(...)a-router-switch-port

Makkelijker is om een mirror poortje te configgen mits je een enigszins slimme switch hebt.

Heb ik! Maar was van plan te mirroren via IPtables in DDWRT (aangezien de switch meerdere dingen verbindt, en de betreffende DDWRT router alleen de IPcam momenteel).

quote:

Op vrijdag 6 oktober 2017 21:56 schreef DJSmiley het volgende:

[..]

Kan ook. Maar je kan in je switch natuurlijk ook alleen het poortje mirroren waar je IP cam op zit (of het AP waar die camera weer op verbonden zit)

Je kan natuurlijk ook gewoon een filtertje in Wireshark maken zodat je alleen verkeer van/naar je IP cam ziet. Dan boeit t niet of je desnoods je hele WAN poort mirrored.

Ik ga hier morgen ff mee bezig, bedankt voor je suggesties!
Ik ga er voor vanavond ff mee kappen.

To do:
dmv telnet verder kijken in de cam zelf
kijken of ik een dump kan maken van de cam, op m'n pc (ssh?)
wireshark gebruiken voor data analyse

quote:

Op vrijdag 6 oktober 2017 22:14 schreef ACT-F het volgende:

[..]

Hier gebruik je dus tcpdump voor. Laten opslaan naar een externe harde schijf als .cap bestand en achteraf Wiresharken.

Ik doelde op alle software van de cam, niet de data die verzonden wordt.

quote:

Op zaterdag 7 oktober 2017 00:40 schreef Farenji het volgende:
De software van de cam kun je wsch niet bij. Misschien dat je via ssh of telnet de sw kan updaten maar niet uitlezen en sowieso de broncode kan je niet inzien. Je kan hoogstens het verkeer van en naar de cam capturen. Via je router kun je waarschijnlijk niet alles capturen, daar zie je alleen de logs. Een manier om dat wel te doen is oa dmv arp poisoning waarmee je het verkeer van en naar de cam via een soort van proxy (eigenlijk is dit een man in the middle attack) laat lopen, dit doe je bijv met ettercap, http://ettercap.github.io/ettercap/. Dat draai je op een computer in je netwerk, met wireshark of tcpdump kun je dan alles makkelijk capturen. En dan maar hopen dat de boel niet encrypted is want dan heb je niks aan je captures.

Ik heb root access tot de cam via telnet, ik hoop eigenlijk dat ik dan wel overal bij kan. Ik weet ook (nog) niet of de data die verzonden wordt encrypted is, ik weet wel dat alles wat je via de reguliere GUI instelt, niet encrypted naar de cam wordt verzonden (inlog en wachtwoorden ook niet encrypted)
Ik ben overigens bekend met ettercap, zit standaard in de door mij gebruikte linux variant.

quote:

Op zaterdag 7 oktober 2017 01:19 schreef wootahH het volgende:
welke cam is dit?

Volgens mij een Foscam kloon (sowieso een Chinese kloon van een 'echt' merk. Als je heel hard "loempia" roept, springt ie uit elkaar )

*foutje

quote:

Op zaterdag 7 oktober 2017 11:41 schreef Farenji het volgende:

[..]

Dan heb je toegang tot de telnet shell maar niet per definitie tot het ruwe bestandssysteem. Met ssh/scp toegang zou je alle bestanden en mappen waarschijnlijk wel kunnen downloaden, of evt met scp vanaf de cam (indien beschikbaar) ergens uploaden, maar dan nog, dan heb je binaries en daar kun je waarschijnlijk ook niet veel mee. Die moet je dan decompilen en daar komt lang niet altijd iets bruikbaars uit. Maar het is natuurlijk het proberen waard.

Goed punt! Ik denk er dus waarschijnlijk te makkelijk over. Ik ben er overigens vandaag nog niet mee bezig geweest!

quote:

Op zaterdag 7 oktober 2017 19:40 schreef KomtTijd... het volgende:
Heb je gewoon de default poort geforward? Dan is de kans groot dat je geregeld bots op bezoek krijgt die proberen je password te bruteforcen. IOT devices zijn populaire targets voor botnets.

Ik zou persoonlijk helemaal niets open zetten naar buiten, maar alleen via een vpn. Of anders op zijn minst een andere poort gebruiken. En natuurlijk een kneiterlang random wachtwoord instellen en dagelijks checken of er updates of exploits zijn.

Nee. Ik heb alles aangepast, ook de poort. Alle IP's die de betreffende poort bezoeken worden opgeslagen in een log.

quote:

Op zaterdag 7 oktober 2017 19:28 schreef Iwanius het volgende:

[..]

Goeie vraag. TS welke cam heb je? Wel handig om dit te weten en om te voorkomen als je het zelf meemaakt.

*Edit DAMN you imgur! Hier een link: https://imgur.com/a/eaW2Q
(De QR code is text: "nip-028717-swlen" )

UPDATE:
IPCam is gisteravond om onbekende reden in een bootloop terecht gekomen (ik was er niet mee bezig, en dit is ook nog niet eerder voorgevallen)
Een harde reset bleek uiteindelijk de oplossing, echter is de cam sindsdien HEEL traag met het doorzetten van beelden naar m'n browser.

De vreemde IP's zijn nog steeds geblokkeerd, dus als dit er mee te maken heeft verwacht ik een dezer dagen weer een bootloop (tenzij dit allemaal HEEL toevallig is)

Update:
Voorspelling kennelijk correct, de cam is zojuist wederom zonder enige aanleiding in een bootloop terechtgekomen. :/
Heb nog geen succes gehad (weinig tijd...) met het onderscheppen van de data

Update:
Ja, ik ben hier nog steeds mee bezig.

Deze link heeft me heel veel info gegeven, omdat hier precies besproken wordt waar ik tegenaan gelopen ben:
https://jumpespjump.blogs(...)a-and-found.html?m=1

In het kort:
De verbindingen worden (dus toch) gemaakt naar een cloudserver, zodat je de cam met android of ios apps makkelijker kan bekijken.

"The cloud protocol is a nightmare. It is clear-text, and even if you disabled port-forward/UPNP on your router, the cloud protocol still allows anyone to connect to the camera, if the attacker knows the (brute-forceable) camera ID. Although this is the user-interface only, but now the attacker can use the command injection to execute code with root privileges. Or just grab the camera configuration, with WiFi, FTP, SMTP passwords included."

Dit is dus een behoorlijk lek.

- Upnp staat bij mij standaard uit.
- De cloud port (32100) was in mijn router al geblokkeerd voor uitgaand verkeer vanaf de cam nadat ik dit alles ontdekte.
- Ik heb de cam niet langer toegankelijk vanaf WAN, alleen maar lokaal. (Van buitenaf kan ik de cam bekijken door op mijn VPN server in te loggen).

Via de cloudserver is de cam dus zo LEK als een mandje:


Zowel de cloudfunctie als de telnet functie zijn niet beschreven in de handleiding.