EBay voert lokale portscan uit bij bezoekers

Veilingsite eBay doet een lokale portscan bij alle bezoekers van de site. Bij wie eBay bezoekt, wordt het systeem gescand op de aanwezigheid van tools die toegang op afstand mogelijk maken, zoals Windows Remote Desktop of TeamViewer. De site scant veertien poorten.

De site doet dat via een check.js-javascriptcode. Bij bezoekers die naar ebay.com gaan, wordt daarmee automatisch gescand of ze bepaalde poorten op hun computer hebben openstaan. Verschillende websites, waaronder Bleeping Computer, ontdekten dat het om minstens veertien poorten gaat.

Programma	Naam die eBay geeft	Poort
VNC	VNC	5900
VNC	VNC	5901
VNC	VNC	5902
VNC	VNC	5903
Remote Desktop Protocol	RDP	3389
Aeroadmin	ARO	5950
Ammyy Admin	AMY	5931
TeamViewer	TV0	5939
TeamViewer	TV1	6039
TeamViewer	TV2	5944
TeamViewer	TV2	6040
Anyplace Control	APC	5279
AnyDesk	ANY	7070

Ook wordt voor een nog onbekend programma gescand op poort 63333.

Het is niet bekend waarom eBay precies aan portscans doet. De originele ontdekker, NullSweep, speculeert dat het gaat om een beveiligingsmaatregel. Tools zoals VNC worden soms door botnets of malware misbruikt om toegang tot een pc te krijgen.

Portscans kunnen op zichzelf niet veel kwaad, maar het is wel opvallend als een site het doet. EBay is ook niet de eerste site die portscans doet, maar meestal gebeurt dat door bijvoorbeeld banken, die het systeem van gebruikers op virussen willen scannen.

EBay zelf heeft nog niet gereageerd op de ontdekking. Gebruikers op onder andere Reddit merken op dat het portscannen geblokkeerd kan worden met add-ons als NoScript of met adblockers.

Reacties (158)

[mrmrmr]

Dat script doet meer dan alleen portscannen en firewall bypassing. Het probeert ook ActiveX, XMLHttpRequest, Canvas, Font enumeratie, WebGL, WebRTC, etc. En dat allemaal onder obfuscatie.

Ruim voldoende reden om dit hele script niet te laden.

[MiesvanderLippe]

Het is een fingerprinting script. Dat doen ze allemaal. En natuurlijk trek je dat door een uglyfier en minifier heen, het is je intellectueel eigendom en bron van inkomsten.

[anargeek]

Het lijkt inderdaad "gewoon" een fingerprinting script te zijn. Maar dit is geen uglifyjs, het is daarvoor te complex met veelgebruikte trucs die duiden op handmatige obfuscatie ipv automatisch.

Wel gaaf script, maar 'ns wat tijd instoppen om dit te deobfuscaten

[xoniq]

Deze site doet dat best netjes:

http://www.jsnice.org/

[anargeek]

Eerlijk gezegd is zoiets als dit alleen handmatig te deobfuscaten. Tools maken het wat makkelijker, maar ben er nog nooit 1 tegengekomen die werkelijk goed deobfuscate.
Ik zie jsnice bijvoorbeeld een hele hoop aannames maken over variabelen die op mij nogal dubieus overkomen, wat eerder tot meer verwarring leidt dan tot meer duidelijkheid.

[Terrestrial]

Ik zie nog steeds niet in waarom er überhaupt scripts op de client geladen moeten worden, doe dat maar serverside en ja dat kost meer cpu kracht en geheugen maar dat is niet ons probleem.. Het wordt tijd dat alle browsers support voor al dit soort dingen laten vallen, geen cookies meer, geen local scripting en allerlei andere flauwekul. Ben je meteen van een hele hoop ellende verlost waaronder tracking en de kans op malware besmettingen wordt ook een stuk kleiner.

Nu moet je weet ik veel hoeveel addons gaan installeren om een beetje normaal te kunnen browsen, men leeft letterlijk van de informatie die ze uit jou browser kunnen los peuteren.

[Aanwezig]

Alles wat maar interactief is gaat client-side. Daar ontkom je niet aan tenzij je terug wil naar het jaar 0

Je kan er ontzettend mooie dingen mee en de client side talen scoren op het moment erg hoog onder ontwikkelaars omdat er veel vraag naar is. De browser/developer implementaties zijn helaas nogal brak waardoor je 8 cores en 6 gb ram nodig hebt in je telefoon voor een goede ervaring.

[Terrestrial]

Alles wat je client side doet kun je ook server-side alleen moet de mentaliteit eerst radicaal veranderen. Nu geven de community en developers geen fuck want het is wel makkelijk zo. De grote browsers moeten het voorbeeld gaan geven, dan kan het ineens wel.

[Argantonis]

Alles wat je client side doet kun je ook server-side alleen moet de mentaliteit eerst radicaal veranderen. Nu geven de community en developers geen fuck want het is wel makkelijk zo. De grote browsers moeten het voorbeeld gaan geven, dan kan het ineens wel.

Klopt gewoon niet, je hebt server-side niet zulke toegang tot iemand's device.
Daarnaast gaat de latency verschrikkelijk hard omhoog voor de dingen die wél kunnen. Dag fijn en snel reagerende user interface.

Dit staat verder helemaal los van cookies en tracking, dát zou inderdaad veel meer aan banden gelegd kunnen en moeten worden en inzichtelijker moeten worden gemaakt.

Bron: 10 jaar backend ontwikkelaar.

[Terrestrial]

Nee natuurlijk heb je niet zulke toegang tot de device, daar gaat het juist om. Zomaar toegang to een client device mag er nooit meer komen. En latency is geen probleem en anders maar een iets minder snappy interface.

[Reactie gewijzigd door Terrestrial op 24 juli 2024 10:10]

[TIGER79]

Iets minder snappy zou je wel eens zwaar kunnen tegenvallen.
Het wordt dus waarschijnlijk ook een heel stuk minder mooi (animaties die bijv "realtime" op je input reageren)en dat is al moeilijk te verkopen aan managers, verkopers en e-merce marketeers, maar ook simpelweg aan de gebruikers want die zijn het immers gewend. Dat is de factor mooiheid. Daarnaast heb je de factor snelheid. Kijk wij zijn verwend met snelle verbindingen met dat heeft de overgrote meerderheid van de wereld niet. Oftewel, in tegenstelling tot wat jij beweert: latency is wel een probleem. Dan wordt de door jou aangekaarte transitie nog veeeeeel moeilijker. Client-side betekend ook minder data verkeer, niet enkel minder server-power.
Het is makkelijk om dit soort uitspreken te doen vanuit een verheven positie maar de wereld is beduidend groter dan enkel ons kikkerlandje....

[Reactie gewijzigd door TIGER79 op 24 juli 2024 10:10]

[tarnov]

Dus bij elke actie van de gebruiker niet meer de DOM aanpassen en/of informatie via een REST call opvragen/verzenden maar de hele pagina opnieuw serverside genereren? Kan natuurlijk.. Maar dan kun je net zo goed terug naar de tijd van de domme terminal, maar dan grafisch..

[Eonfge]

Wel apart dat ze via het web socker protocol zulke ports kunnen scannen. Je zou dan juist weer verwachten van browsers dat ze zulke connecties verbieden om de client te beschermen.

Je kunt deze techniek namelijk ook gebruiken om data van ontwikkelaar-machines af te halen:
https://medium.com/@stest...g-websockets-254f98d577a0

Kort gezegd; niets weerhoudt Ebay (of elke andere website) om port 3000 (of 4200, of 8080) te scannen, de standaard port voor de meeste web-frameworks als je aan het ontwikkelen bent.

[Reactie gewijzigd door Eonfge op 24 juli 2024 10:10]

[Gamebuster]

(Gebrek aan) CORS headers houden normale HTTP requests wel tegen toch?

Lijkt me toch dat als je vanaf ebay.com een request naar localhost:3000 doet, en localhost:3000 heeft geen Allow-Origin: * o.i.d., dat de browser de request dan weigert.

Wellicht kan je dan nog wel o.b.v. timing kijken of er een server draait, maar meer ook niet.

Worden bij websockets de CORS headers genegeerd? Zo te zien wel.

Andere bron: https://www.freecodecamp....connections-d0be0996c556/

Waarom is er geen CORS check voor websockets?

[Reactie gewijzigd door Gamebuster op 24 juli 2024 10:10]

[GertMenkel]

Aangezien websockets geen raw sockets zijn (je kunt er niet zomaar HTTP mee spreken) is de impact lager dan een normaal verzoek met HTTP. Het enige dat je ermee zou kunnen doen is een lokale websocket-server aanspreken, en daar zou als het goed is beveiliging op moeten zitten (zal in de praktijk wel niet zoveel voorkomen).

Daar komt bij dat websockets die over HTTPS worden geserveerd alleen over HTTPS kunnen praten en lokale websocket-servers vaak geen HTTPS doen (niet als je een ontwikkelaar bent, doorgaans). Dus, als je websites over HTTPS bezoekt wordt het al lastiger om hier misbruik van te maken. Nog steeds kun je hier natuurlijk mee port scannen, maar de inhoud van de berichten daadwerkelijk uitlezen wordt lastig.

Ik geloof dat het gebrek aan CORS komt door de visie dat websockets peer-to-peer communicatie zouden moeten kunnen doen, net als WebRTC maar dan betrouwbaar i.p.v. snel. Ook was volgens mij het idee om verschillende servers aan te kunnen spreken (denk IRC maar in je browser) waarmee je dus meer flexibiliteit hebt in je webapplicatie. Of websites daar ook gebruik van maken weet ik niet, maar het is een use case van websockets.

Ik vind het raar dat browsers localhost en het lokale subnet toestaan vanaf een externe bron. Na DNS-resolutie mag daar van mij toch wel een filter of permissie tussen komen te zitten. Dit is een stap terug in webapplicatiebeveiliging om weinig-gebruikte features te ondersteunen.

[Gamebuster]

Ik geloof dat het gebrek aan CORS komt door de visie dat websockets peer-to-peer communicatie zouden moeten kunnen doen, net als WebRTC maar dan betrouwbaar i.p.v. snel.

Zodra je een websocket verbinding legt, begint de browser toch echt eerst met iets dat heel sterk lijkt op een HTTP request. (hint: Het is gewoon een HTTP request)

Er is eerst een request, bijv.:

GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Vervolgens geeft de server terug:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Hoe ingewikkeld is het om hier gewoon een Access-Control-Allow-Origin: mee terug te sturen? (die vervolgens ook gecheckt moet worden door de browser) Ik kan me gewoon geen nadeel bedenken, maar ik heb dan ook de standaard niet bedacht. Performance lijkt me in ieder geval niet het probleem... dit zou alleen nodig zijn bij de 1e request/response, vlak voordat protocol gewisseld wordt, en dus niet bij iedere frame.

Nog beter (naar mijn idee) is gewoon vooraf eerst die HEAD /chat te sturen die een browser ook zou sturen bij ieder ander XHR/script/whatever request naar een ander domeinnaam. I.c.m. een keep-alive header zou dit echt totaal niet merkbaar moeten zijn qua performance impact.

Overigens, volgens MDN:

Tip: All browsers will send an Origin header. You can use this header for security (checking for same origin, whitelisting/ blacklisting, etc.) and send a 403 Forbidden if you don't like what you see. However, be warned that non-browser agents can just send a faked Origin. Most applications will reject requests without this header.

Je moet het dus zelf checken, volgens MDN. Ik vind het maar raar dat het zo werkt ipv CORS.

[Reactie gewijzigd door Gamebuster op 24 juli 2024 10:10]

[StefanJanssen]

is 3000 de standaard port voor web-frameworks? Ik kan me niet herinneren dat ik dat ooit gezien heb.
voor PHP servertjes gebruiken mensen vooral 8080, voor node servers is het vaak 8080 of 4200. dotNet core draait op 80, maar binnen een docker container standaard op 5000.

[elmuerte]

8008 en 8080 zijn officieel toegekende alternatieve HTTP porten. Het zou fijn zijn als (dev-)webservers deze als standaard zouden gebruiken in plaats van een willekeurige. Net zoals je bijvoorbeeld standaard example.org of example.com gebruikt als standard domain names, of de .test en .example TLDs.

[supersnathan94]

nee juist niet. Dev wil je niet op die poorten hebben draaien. 8008 en 8080 zijn juist voor je productie webservers.

Dev werk doe je maar lekker op andere poorten.

in plaats van een willekeurige.

Nou zo willekeurig zijn die poorten niet hoor. Als je ook maar een beetje frontend doet weet je ze uit je hoofd.

Edit: om even duidelijk te zijn. Je wil geen frontend applicaties hebben draaien op 8080 als je ook lokaal je backend hebt draaien. 8080 is een standaard poort voor Spring Boot Jetty en apache tomcat. Als je dus een applicatie aan het ontwikkelen bent wil je dus je frontend niet hebben draaien op die poorten want dat geeft conflicten. Dat is dan ook de reden dat Node op andere poorten draait. Vaak een 3000 of 4200. Puur zodat je niet met je backend in de knoop komt.

[Reactie gewijzigd door supersnathan94 op 24 juli 2024 10:10]

[Wim-Bart]

80 altijd redirect naar 443
8080 is proxy

Overigens maakt de poort niet eens zo veel uit. Zolang je maar documenteert. Voor de eindgebruiker moet het simpel zijn, geen geknoei met poortnummers maar gewoon standaard 80 (met achterliggende redirect) en 443, eventueel allemaal met host-header of SNI. Backend services moeten sowieso HTTPS draaien, maar liefst op een andere poort dan standaard 443 om te voorkomen dat iemand per ongeluk op zo een server uit komt.

[supersnathan94]

Backend services draaien lokaal eigenlijk nooit HTTPS en ook niet op een vaste poort. Poortjes heb je immers altijd maar 1 van. Heb je microservices dan heb je dan al direct een probleem. Docker draait standaard niet voor niks in de range 32768 tot 65535. K8s en Docker hebben allebei hele andere manieren van routing en dus is er geen standaard manier waarop het werkt.

HTTPS termineer je direct bij binnenkomst door iets als Traefik of NGinx. Achterliggend verkeer is gewoon HTTP.

Allemaal voorbeelden van hoe het kan. Er is dus niet een standaard manier om iets te doen, maar frontend applicaties draaien op 8080 is voor dev werk vaak gewoon niet handig omdat je dan met je backend poorten in de knoei kan raken omdat die vaak wel 8080 en 8081 (voor metrics bijvoorbeeld) gebruiken.

80 altijd redirect naar 443 is lokaal dus gewoonweg geen optie. Je kan immers geen certificaat krijgen voor localhost anders dan wat self signed spul en dan kan je net zo goed gewoon geen cert gebruiken tenzij je echt HTTPS nodig hebt. Lokaal is dat veelal gewoon niet te doen omdat je dan heel veel moet gaan proxy-en en je door de bomen het bos niet meer ziet.

Voor de eindgebruiker moet het simpel zijn

De eindgebruiker heeft niks te maken met interne poorten. Die pakt uiteraard idd gewoon 80 of 443 voor HTTP(S) verkeer.

Je verhaal is allemaal gericht op de buitenwereld en dat is nu exact niet waar het over gaat. Het gaat juist om intern LAN en daar heb ik heeeel veel dev spul op verschillende poorten draaien. Dat hoeft Ebay niet te weten.

[Wim-Bart]

Bij ons draait alles intern HTTPS. Omdat bepaalde services niet eens werken met SSO wanneer deze over http draaien. En bovendien zit je security technisch met een issue. De backend, wanneer je aan de voorkant een webservice hebt draaien en een applicatie server aan de achterkant dan gaat dat gewoon ook met https, meestal op een andere poort. Certificaten zijn totaal geen issue want we hebben interne PKI waar we gewoon certificaten kunnen aanvragen. Daarnaast zit onze interne namespace gewoon onder een extern geregistreerde com domein (extern bedrijf.com, intern ad.bedrijfinternal.com) waardoor we voor onze interne PKI een extern te valideren certificaat kunnen gebruiken als trusted root.

Externe sites komen binnen op firewall die extern certificaat gebruikt, die pakt alles uit en weer in en stuurt het door naar een server in een DMZ. Deze server heeft alleen basis applicatie logica en zet alles door naar achterliggende systemen via een andere firewall. Meeste systemen werken met presentatie/applicatie/data tiers welke allemaal via firewalls gescheiden zijn en ook allemaal DPI doen en HTTPS.

Poort 80 is uit den boze. SSL is verplicht.

[supersnathan94]

Het kan ook allemaal wel als je het wil. Maar dat vetekent dus dat iederE appliance met een IP 1 service draait. Anders kan je nooit op service niveau op dezelfde poort draaien. Sterker nog. Hoe wil je dan dingen doen als metrics verzamelen via iets als Prometheus waar dit ook via webserver geserveerd wordt?

Lokaal draaien van een deel van de stack is hiermee overigens vrijwel onmogelijk zonder proxy. Behoorlijk irritant als je het mij vraagt. Met SSO begrijp ik het overigens wel, maar binnen een intern netwerk is het enige wat dan belangrijk is encryptie van credentials.

Begrijp me goed. Ik snap de use cases, maar ik probeer even aan te geven dat het lokaal gewoonweg onbegonnen werk is om het op doe manier te doen.

Overigens ga je er hier dus ook vanuit dat er lokaal tijdens dev werk van alles geproxyed wordt. Ik weet biet hoe jullie development doen, maar ik kan me voorstelen dat het een pain in the ass kan zijn als dit niet goed onderhouden wordt. Zit behoorlijk wat complexiteit in je infra die lokaal development er niet sneller van maakt.

[onok]

React app draait standaard op 3000. Dat is wel een veel gebruikte.

[StefanJanssen]

React is een van de weinige webframeworks die ik nog nooit gebruikt heb. Vuejs is 8080 en Angular 4200

[Snippo]

ExpressJS gebruikt standaard ook poort 3000.

[gottamusic8]

Het veelgebruikte Nuxt.js framework voor Vue draait ook standaard op poort 3000, evenals het Next.js React framework waar Nuxt op gebaseerd is.

[Gamebuster]

In Rails/Javascript land is 3000/4000/5000 en 8000 erg populair. Ik zie eigenlijk bijna nooit development servers standaard op 8080 draaien. Ik denk dat dat geassocieerd wordt met "oude software", of dat er vaak al iets op draait.

[Reactie gewijzigd door Gamebuster op 24 juli 2024 10:10]

[Cyb]

De hele Java wereld draait standaard op 8080. 8080 behoort daarmee dus tot één van de meest voorkomende webserver porten. 8080 wordt ook veel gebruikt bij proxy servers.

[Wim-Bart]

De hele Java wereld draait standaard op 8080. 8080 behoort daarmee dus tot één van de meest voorkomende webserver porten. 8080 wordt ook veel gebruikt bij proxy servers.

En dat eerste veroorzaakt zo veel issues in omgevingen wanneer automatic proxy discovery aan staat in Windows. Dan krijgen werkstations opeens reactie van een server op 8080 en dan denken ze "hey een proxy gevonden" waardoor reactiesnelheid trager wordt omdat er dan extra tests uitgevoerd worden. Eigenlijk moet je 8080 gewoon vermijden in je netwerk.

[BCC]

Rails is ook standaard 3000

[Cyb]

Ik vind het toch wel erg kwalijk dat dit zomaar kan met WebSockets. WebSockets bestaat al sinds 2010. Ik vind het vreemd dat niemand eerder had kunnen bedenken dat dit (het portscannen) tot problemen kan leiden. Maar dat van dat Medium artikel gaat nog een stuk verder, voor ontwikkelaar machines. Veel JavaScript ontwikkelaars kunnen nu dus standaard niet zomaar even rondsurfen met hun development tools aan, want dan kunnen derden dus bij development gegevens komen.

Het scannen gaat overigens zeer snel, dus de port die gekozen wordt is eigenlijk irrelevant. "scanning 10k ports takes a second or so".

[Wim-Bart]

Je kan het ook omdraaien. Waarom zijn er blijkbaar services die ongeautoriseerd verkeer toelaten terwijl het protocol daar in voorziet?

Wat ik begrijp, ben een leek in websockets, the moet de applicatie zelf checken of de aanvraag goed is. Dus wanneer de applicatie dit niet doet, dan is de applicatie die de socket aanbied gewoon ruk.

Zie het als een gebouw met allemaal Candoo deuren. Je bouwt het gebouw, je hangt de deuren er in en na 1 dag is het hele gebouw leeg. Je kijkt naar het gebouw en ziet dat je de deur zonder problemen open doet. Je kijkt verder en denkt wat een klote deuren, er zit nergens een slot in. Maar het zijn geen klote deuren, nee de bouwer is vergeten dat de deuren zonder slot worden geleverd, want die moet je zelf plaatsen, zelfs de gaten zitten er klaar voor. Kortom de bouwer is een prutser, niet de deur fabrikant.

[Cyb]

Het is inderdaad een discussiepunt of de lokale websocket server daar verantwoordelijk voor is. Zelf vind ik van niet, ondanks dat daar wel beveiliging kan worden ingebouwd. Het is namelijk ongebruikelijk dat een browser die resources van een willekeurig externe webserver laadt, vervolgens gegevens van lokale services gegevens naar internet lekt. Ontwikkelaars verwachten zoiets niet, omdat het in gaat tegen algemeen geaccepteerde security ontwerpen. Een dergelijk ontwerp is vragen om problemen, Firewalls kunnen er ook moeilijk op controlleren, omdat het vanuit de lokale browser gebeurt.

En los van dit developersprobleem (van het Medium artikel), bestaat er dus ook nog dat websocket portscanning probleem, iets waar je als gebruikers niet tegen kan doen, anders dan het volledig uitschakelen van WebSockets.

Dit geeft naar mijn mening aan dat men niet goed heeft nagedacht over het WebSocket ontwerpen in browsers.

[Wim-Bart]

Op zich vind ik een werkplek eigenlijk ook geen plek om servers te draaien. Maar tegenwoordig doet bijna iedere fabrikant dat, dat is ook 1 van de redenen dat ik van Nvidia afgestapt ben, die installeerde een server service die zonder enige moeite te exploiten was.

[Cyb]

Ook Windows en Linux openen er standaard vaak een paar op normale client computers, dus het portscanning probleem geldt niet alleen voor developer machines. Het gaat om elke TCP/UDP port die op "listen" status staat. Deze vormen dan onderdeel van de fingerprint die EBay kan maken.
Met "netstat -an" in de commandline kan je zien welke porten open staan op "listen" status.

[Wim-Bart]

Ja, maar waar het mij om gaat is, dat je zo veel mogelijk aanvalsvectoren moet elimineren. Bijvoorbeeld:
AMD RaidXpert, waarom een web service?
NVidia Geforce Experience, waarom een web service?
En zo is er veel meer.

Kortom, waarom moeten bepaalde services van buitenaf beschikbaar zijn?

Ik kan mij voorstellen als develloper dat je een local repository hebt die in sync moet blijven, maar dat kan ook in een push/pull architectuur (data uit = push, data in = pull).

Wanneer je aan web development doet kan ik me ook voorstellen dat je lokaal een database server hebt voor de eerste ontwikkeling, en een webserver om tegen te kunnen debuggen. Maar voor de rest.

Ik zie het al voor me, ik koop een koelkast en monteer deze zodanig dat de deur buiten mijn huis zit. Wanneer ik hem vul doe ik dat aan de achterkant, heb ik wat nodig moet ik eerst naar buiten, en ik doe er ook geen slot op zodat de hele buurt er bij kan.

[Cyb]

Voor degenen die WebSockets (de api die dit mogelijk maakt) willen uitschakelen in Firefox:
https://stackoverflow.com...in-firefox-or-in-my-proxy
Eventueel kan je met meerdere Firefox profiles werken, zodat je het bijvoorbeeld standaard aangeschakeld kan laten onder een apart profiel.
Het uitschakelen kan er voor zorgen dat bepaalde sites niet lekker draaien, zoals chat sites of live grafiek aandelen sites (sites waar vaak veel server responses nodig zijn, willekeurig in tijd na de page load). Vaak vallen dergelijke sites dan terug op polling methodes, waardoor server responses wat vertraging hebben. (Dus bijv. het enkele seconden later zien van een chat berichtje.)

Voor Chrome heb ik nog geen simpele oplossing gezien.

Hier kan je testen of WebSockets uitgeschakeld is: https://www.websocket.org/echo.html
(Klik vervolgens op "Connect", waar je dan een error krijgt als het uitgeschakeld is.)

[Reactie gewijzigd door Cyb op 24 juli 2024 10:10]

[BLACKfm]

Of, en dan zet ik even mijn aluminium hoedje op, er wordt een database aangelegd met mogelijke zwakheden in de computer van de gebruiker. En deze eindigt straks ergens op de zwarte markt.
En ja, Ebay vertrouw ik wat dat betreft dan net zo min als elk willekeurig andere website. Dat vertrouwen over privacy en beveiliging staat tegenwoordig op een laag pitje.

Volgende stap is om te testen als je via dat soort programma's bestellingen doet of je daar dan enige rechten uit kunt ontlenen. Of welke nadelen je er aan ondervind. Zoals het claimen dat je iets niet besteld hebt om vervolgens de mededeling te krijgen 'Ja, maar u heeft teamviewer en VNC op uw computer draaien, mogelijk was daar de beveiliging niet van op orde en daardoor is deze foute bestelling uw eigen fout'.

[Helium-3]

Alle IPv4 adressen zijn tegenwoordig te scannen in luttele minuten. En dit is niet langer exclusief voor entiteiten met veel geld en resources, maar iedere 'skid' kan een dedicated server met gigabit verbinding huren en binnen tien minuten alle IPv4 adressen op één poortje scannen. Als je dit wil doen met de 15 poorten die in het artikel genoemd werden ben je dus hooguit een paar uurtjes kwijt.

Het is heel aannemelijk dat alle genoemde poorten en nogmeer op jouw internetverbinding al veelvuldig gescand zijn sinds het uitkomen van dit artikel, een paar uur geleden.

Dus nee, ik denk dat we het hier niet over uitzonderlijk gevoelige gegevens hebben. Dit vanwege het feit dat iedereen binnen een praktische en korte tijd het "hele" (IPv4) internet gescand kan hebben.

Q: Dit zouden ze eens moeten scannen en openbaar maken, als een soort van zoekmachine ofzo?
A: Got you, https://www.shodan.io/

[coolkil]

Dit is toch wel even iets anders. Alle publieke adressen scannen is tot daar aan toe en dit scherm je vaak af met een lading aan firewall regels en je kan eventueel nog gebruikmaken van ids en ips om te monitoren wat voor troep naar jou adres wordt gestuurd.

Dit doet echter een portscan op 127.0.0.1 das wat anders en normaal lastig te doen vanaf een publiek adres. Tevens is dat ook lastig te beschermen omdat er soms applicaties zijn die gebruik maken van je loopback interface en om daar nou ook een firewall voor bij te gaan houden...

[sprankel]

En ondertussen hebben de mensen thuis zonder dat ze het vaak beseffen een IPV6 adres dat niet achter een NAT zit en waar dus hang je rechtstreeks aan het internet.

Tenzij je IPV6 volledig afblokt denken mensen dat ze op hun intern netwerk safe zitten omdat ze op IPV4 achter een NAT zitten. En we zijn dat zo gewoon dat we het normaal en handig zijn gaan vinden terwijl IPV4 met NAT nooit had mogen gebeuren, we hadden nooit het internet zoals vandaag op IPV4 mogen online brengen, nu staan we hier mooi, het kost ons zeker nog 20 jaar om IPV4 met zijn NAT toestanden uit de wereld te krijgen en dan nog zal IPV4 nog altijd bestaan.

Door een NAT ben je wat meer gescheiden van het internet en ja dat geeft wat security maar eigenlijk is dat maar flut security. Net zoals een firewall, je kan wat poorten dichtgooien, protocols dichtgooien en ip adressen blacklisten. Maar dan zet je gewoon een encrypted verbinding op en wat kan die firewall nog zien? juist niets terwijl we op alle lagen van communicatie net overal encryptie willen insteken. Of van een ander IP adres afkomen dat je niet geblokkeerd hebt, een firewall werkt enkel deftig als je alles blacklist en enkel datgeen white list wat je wilt en dat is mogelijk heel handig voor een tweaker maar dat kan je niet van jan met de pet vragen.

En dan zit je met het probleem dat u thermostaat achter een NAT zit en de thermostaat eerst met een server connectie moet maken voor je hem buitenhuis kan raadplegen, of je moet een VPN gaan opstellen, we vinden dat allemaal normaal maar eigenlijk is het gewoon een dikke fail van de IT geweest.

Maar naar de toekomst toe, het is heel eenvoudig, u devices moeten secure genoeg zijn om aan IPV6 en dus rechtstreeks aan het internet te hangen zonder NAT en zonder Firewall. En als je met legacy toestanden zitten die dat niet kunnen, begin maar te denken hoe je ze gaat ombouwen.

[Reactie gewijzigd door sprankel op 24 juli 2024 10:10]

[coolkil]

Simpelweg niet waar. Ook dan maak je gewoon gebruik van een firewall die tussen jou en het publieke internet staat. NAT of PAT is geen beveiligings maatregel (ookal wordt deze wel zo gebruikt) het is ooit bedacht omdat er te weinig adressen waren en de meeste apparaten nog geen degelijke IPv6 ondersteuning hadden. Een daarnaast kan je bij mijn weten ook gewoon een statefull firewall bouwen over IPv6 en alleen outbound en established verkeer toe staan. op die manier wordt all het traffic wat niet door jou geïnitieerd is keurig geblokt op de firewall en komt het nooit bij jou host aan. Op die manier kan je daar fijn mazig mee om gaan. dat je vervolgens bepaalde poorten daarvoor uitzonderd is een keuze en inderdaad dan moet je wel goed weten dat de applicatie die op die poort draait een degelijk beveiligings niveau heeft.

encryptie heeft hier niks mee te maken en is voor zowel IPv4 als IPv6 een beperking voor Deep Packet Inspection.

Maar zelfs dan nog heeft dit niks te maken met het gedrag van websites wat hierboven besproken wordt. enige verschil zou zijn dat als dit op IPv6 gebeurde dat de websockets naar het ::1 addres gericht zou zijn.

Daarnaast als je onwetend bent dat je IPv6 hebt heeft je provider router daar een keurige firewall voor die je in ieder geval basis bescherming biedt.

[sprankel]

Juist om de records goed te zetten.

IPV4 is het jaar '80
IPV5 is '90 en update in '95
In '92 besloot dat IPV5 niet dat was maar versie 4 had niet genoeg adressen dus private adressen en NAT werd erover gegooid
In '95 kwam IPV6 uit met nog een update in '98

Het internet komt online op IPV4 en geen enkele internetprovider zag de noodzaak voor een upgrade want hoeveel computers je thuis ook had, je zat toch altijd achter 1 adres dus nergens ondersteuning te krijgen, niet in je os, niet in je router, nergens, het is alsof IPV6 niet bestaat.

En dan gebeurd de smartphone, plots heeft iedereen een device op zak dat rechtsreeks aan het internet hangt buitenhuis en krijg je opkomende landen die online komen zuiver op smartphones, dat is het moment dat het heel duidelijk was, we are screwed, very screwed.

En terwijl iedereen nu echt wel doorheeft dat IPV4 buiten moet, begin het nu maar op te lossen. Vervolgens is IPV4 echt wel uitverkocht, dan heb je het IoT verhaal, behalve je smartphone, je horloge komt ook online, je auto komt online en die zitten niet achter een thuis netwerk. Een van de beweegredenen dat onder de IoT noemer te steken is om ervoor te zorgen dat dat allemaal IPV6 only online komt want daar is echt wel geen ruimte voor op IPV4, dat is immers nu reeds uitverkocht.

Het jaar '92 en het jaar '95, daar is het fout gelopen en die fout gaat ons extreem lang achtervolgen.

[Reactie gewijzigd door sprankel op 24 juli 2024 10:10]

[eric.1]

Je hebt op zich gelijk, alleen zie nog wel een verschil tussen je publieke IP scannen en je lokale machine (127.0.0.1, zoals ebay doet). Op mn publieke adres verwacht ik het wel (al is zelfs dat soms strafbaar, afhankelijk van de intentie, maar goed), maar wat moeten ze met mijn lokale machines?

Dat ik een poortje open heb staan voor een lokaal<->lokaal verbinding, wat hebben ze daar mee te maken?

[supersnathan94]

Maar dat is allemaal vanaf extern. Dat is inderdaad gewoon publieke info, maar wat ik op mijn PC lokaal heb draaien gaat Ebay sowieso geen drol aan, laat staan dat ze er iets mee moeten. Als ik teamviewer heb draaien betekent dat niet dat dit ook direct aan het internet hangt. Als ze nou extern een portscan deden voor security dan oke fair point. Ik heb het dan zelf openstaan naar de buitenwereld, maar intern op LAN hebben zij daar helemaal niks te zoeken.

[Verwijderd]

Ik denk niet dat ebay deze gegevens gaat verkopen aan concurrenten, ze houden dit natuurlijk liever zelf 😉

Ik denk echt eerder aan veiligheid, gehackte accounts, valse advertenties etc kost ze bakken met geld

[gooos]

BLACKfm zegt ook niet zozeer dat hij denkt dat eBay deze info zal verkopen, maar dat het mogelijk op de zwarte markt terecht komt. Dat kan bijvoorbeeld door een lek / hack / bijverdienende eBay medewerker...

[mbbs1024]

Of bij de VS spionage diensten, die op die manier een makkelijke ingang zoeken.
Amerikaanse bedrijven zijn verplicht om gegevens aan de overheid door te spelen, dmv hun geheime rechtbanken.

[keizert]

Fout, de fingerprints worden veelal inclusief userdata verkocht aan allerlei ‘datapartners’

[keizert]

Het wordt gebruikt om te fingerprinten, die hele code zit er vol mee. Volstrekt onwettig zonder toestemming.

[Reactie gewijzigd door keizert op 24 juli 2024 10:10]

[Wim-Bart]

En welk artikel in de wet legt dit vast?

[keizert]

Het raakt met name de Telecommunicatiewet en de AVG.
https://www.emerce.nl/ach...ting-valt-onder-cookiewet

AVG moge helder zijn. Er wordt dmv het fingerprinten een pseudoniem gegenereerd die rechtstreeks te herleiden valt naar een natuurlijk persoon.
https://nl.m.wikipedia.org/wiki/Pseudonimiseren

[Wim-Bart]

Het raakt met name de Telecommunicatiewet en de AVG.
https://www.emerce.nl/ach...ting-valt-onder-cookiewet

AVG moge helder zijn. Er wordt dmv het fingerprinten een pseudoniem gegenereerd die rechtstreeks te herleiden valt naar een natuurlijk persoon.
https://nl.m.wikipedia.org/wiki/Pseudonimiseren

En toch wordt het gebruikt in opsporing. En mensen moeten zeker niet de illusie hebben dat ze er aan ontkomen. Hackers draaien daarom ook al hun spul in virtuele machines die direct na gebruik ook weg worden gegooid. En VPN is ook een illusie want de fingerprints gaan gewoon door de tunnel.

Veel mensen gebruiken VPN om IP af te schermen. En laat dat nou juist het meest oninteressante zijn. Het maakt herleiden makkelijker maar dat is dan ook alles.

Zoals een vriend van mij zegt die bij de overheid aan Cyber opsporing doet: "Zolang mensen maar denken dat ze veilig zijn achter hun VPN, maakt het voor ons alleen maar makkelijk". En de achterliggende gedachte, achter een VPN zijn mensen roekeloos en maken ze alle fouten die ze niet zouden maken zonder VPN.

[Tokus]

Of, en dan zet ik even mijn aluminium hoedje op, er wordt een database aangelegd met mogelijke zwakheden in de computer van de gebruiker. En deze eindigt straks ergens op de zwarte markt.

waarom op de zwarte markt? Ebay heeft zelf een groot platform om spullen te verkopen

[3x3]

Als dit helpt tegen fraudeurs die met gehackte accounts mensen oplichten dan vind ik het niet eens zo'n gekke maatregel.

[denPes]

Ja, dit zouden alle websites moeten doen. Continue portscans van alle bezoekers, om elkaar te "helpen" voor een veiliger internet.

[Verwijderd]

Internet providers doen dit ook en aan de andere kant blokkeren ze standaard poorten (SMTP TCP:25 bijvoorbeeld). Daar vindt ik het wel een goede actie gezien zij verantwoordelijk zijn voor de veiligheid van hun klanten. Ze moeten echter wel de optie bieden om dit uit te zetten, wat velen dan weer niet doen.

[kodak]

Welke internetproviders scannen volgens jou (al dan niet via je client) je poorten zonder het te vragen?

[Verwijderd]

Ik weet dat XS4ALL vroeger al poorten scande en je afsloot als er iets niet goed was. Dit was wel lang geleden waar ik klanten hielp bij open relays van e-mailservers.

Ik kan niet met zekerheid zeggen of ze dit nu nog doen maar ik zou het niet verkeerd vinden.

[supersnathan94]

Ja maar dat was van buitenaf. Als consumenten ineens een open SMTP server op komt dan is dat best wel gevaarlijk. SMTP protocol is nou eenmaal vrij slecht beveiligd (helaas staat de S dan ook voor simple en niet secure).

Wat Ebay hier doet is intern kijken wat jij binnen je netwerk allemaal niet hebt draaien. Best wel gevaarlijk een voor mij een reden om maar eens goed te gaan kijken naar VLAN scheiding van interne netwerk en toch maar eens guest isolation aanzetten voor apparaten die naar buiten gaan.

[Verwijderd]

Ah, dit was mij niet duidelijk geworden uit het artikel.
Sorry voor eventuele verwaring.

[Brahiewahiewa]

Ziggo doet dat op port 25

[RoRoo]

Ja en gelijk een database aanleggen met onveilige pc's en hun publieke IP's en die dan verkopen of lekken.
Het gaat niemand wat aan als iemand VNC of Teamviewer heeft draaien..

Toch??

[Z80]

Wat ik aan de binnen kant op mijn eigen netwerk openzet doet er niet toe. Ik wil bv mijn laptop vanaf mijn werkmachine benaderen. Wat ik niet wil is dat dit van buitenaf kan. Een scan vanaf die kant zou bij bepaalde sites nog te begrijpen zijn. Vanuit binnen absolute niet.

[goldrnr]

hmmm mischien kan onze regering een appaton uitschrijven om zoiets te ontwikkelen

[webside007]

inderdaad.
Hopelijk komen ze met een verklaring

[WienerBlut]

Ja, en een goede ook hoop ik... Ik vind het best wel een heftig iets. Maar dat dit kan verbaast mij wel! Het lijkt mij best wel een feature die ik als browser-bouwer zou blocken...

[Roy23]

Best wel heftig? Weet je wel wat een poortscan inhoudt? De scan ansich stelt niks voor en geeft enkel inzicht in poorten die wel of niet "open" staan.
En een browser die deze feature blokkeert..... Daar valt eenvoudig omheen te werken. Je ziet wat het IP adres van de bezoeker is en stuurt een commando naar een andere server om de poortscan uit te voeren. Geen browser meer nodig voor de check.

[WienerBlut]

Ik weet wat het is ja... maar blijkbaar is het nu dus niet vanuit extern, maar vanuit de browser... Wanneer ik een interface zonder firewall, die ook niet door de NAT van een provider beschermd wordt, rechtstreeks aan het internet hangt dan zie je pas wat een open riool het internet is... een bombardement van portscans etc... Velen en ik ook willen mij daartegen beschermen met een firewall of NAT/PAT... Ook al kan de portscan ansich geen kwaad, het is verzamelen van data.

Maar het opmerkelijke wat er nu gebeurt, en daarom is het ook nieuws, is dat het portscannen vanuit de browser gebeurt door een gerenommeerde site eBay. Dus nu omzeilen ze alle beveiliging die je hebt in je netwerk. En dat vind ik wel best wel even iets als binnenkomen zonder kloppen...

[FreshMaker]

Best wel heftig? Weet je wel wat een poortscan inhoudt? De scan ansich stelt niks voor en geeft enkel inzicht in poorten die wel of niet "open" staan.
En een browser die deze feature blokkeert..... Daar valt eenvoudig omheen te werken. Je ziet wat het IP adres van de bezoeker is en stuurt een commando naar een andere server om de poortscan uit te voeren. Geen browser meer nodig voor de check.

Best wel heftig .... ja

Ebay heeft geen donder te maken met mijn poort-indeling.

Om het naar de echte wereld te trekken :
De postbode die een rondje om mijn woning loopt, en een alle ramen en deuren pakt om te zien of er iets open staat ?
Daar heb ik een beveiliger / politie voor, die dat zouden kunnen doen, niet een postbode of de AH-bezorger

[Z80]

In dit geval de postbode die naar binnen loopt, en dan vervolgens aan de ramen gaat voelen of deze wel vergrendeld zijn.
Dus niet van buitenaf benaderen. Wat ik nog kan begrijpen.

[supersnathan94]

Nou eerder nog de deuren binnen. Heb jij je toilet deur op wel op slot? Of je badkamer?

Je voordeur zou dit normaal tegenhouden als je van buiten af kijkt.

[Reactie gewijzigd door supersnathan94 op 24 juli 2024 10:10]

[Verwijderd]

Best wel heftig .... ja

Ebay heeft geen donder te maken met mijn poort-indeling.

Jouw reactie was ook mijn eerste reactie. Maar misschien moet je blij zijn dat eBay dit doet. Want als zij het doen, doen anderen het ook. Nu het om eBay gaat wordt het nieuws. Misschien dat browsers standaard dit soort mogelijkheden dicht gooien.

Hopelijk is het een wake-up-call voor velen. 'One day the Internet is going to bite you in the ass hard..'.

[S-1-5-7]

Nee een portscan vanuit buiten is heel anders dan één vanuit binnen het netwerk. Een internet firewall zal dan een hoop tegenhouden wat nu dus omzeild wordt op deze manier.

Vind het bijzonder dat een browser dit toe staat. Er zal ongetwijfeld een technisch nut zijn

[Reactie gewijzigd door S-1-5-7 op 24 juli 2024 10:10]

[Zynth]

Toch vind ik het niet prettig als marktplaats bij elke interactie even om mijn huis heen loopt om te kijken of er een raam open staat.

[cracking cloud]

De browser heb je juist nodig omdat die lokaal draait. Er wordt een check gedaan op 127.0.0.1, dat is je localhost. Als je een portscan zou doen vanaf een andere server kom je bij het externe IP uit en daar zit als het goed is wel een firewall voor.
Het 'mooie' van deze feature is dat je al binnen in het netwerk bent.

[heuveltje]

-Je kunt normaal gesproken mijn pc niet portscannen, daar hangt een nat translatie met extra firewalls tussen.
-Daarnaast is het vooral belachelijk dat Ebay dit doet. dat is alsof je de postbode binnenlaat in je flat om een pakketje af te geven. En nu hij er toch is gaat ie meteen even in heel de flat controleren welke ramen en deuren wel of niet op slot zijn. Zelfs al heeft ie goede bedoelingen, dan nog is dit compleet ongepast.

[egeszsegedre]

Wat moet een website waar spullen verkocht en gekocht kunnen worden, met een portscanner vanuit iemand's PC?

[Durandal]

Klanten kwijtraken.

[Fonta]

Hoe zou een poortscan hierbij moeten helpen?

[MiesvanderLippe]

Als een port vooral gebruikt word door een RAT (remote access tool) dan is dit een indicatie dat het deel is van een botnet. Een beetje een knullig botnet wel te verstaan, maar goed.

Persoonlijk denk ik dat het een fingerprinting of marketing script is.

[heuveltje]

Of dat het iemand is die rat voor zijn werk gebruikt ? Op onze werkpc's staat ook een rat poort open, gewoon om de IT zijn leven een stuk simpler te maken

[johanneslol]

Ik denk dat ze deze scans doen voor mensen die bots gebruiken om te bieden op veilingen.

[supersnathan94]

Tsja. Dan gebruik je een andere poort. Probleem opgelost. Binnen interne netwerk heb je tienduizenden poorten die je vrij kunt gebruiken. Standaard poorten gebruiken als je dit soort dingen gaat doen is een beetje knullig.

[Seth_Chaos]

Wel als de data wordt vastgelegd. Helemaal als dat ook nog wordt gerelateerd aan persoonsgegevens. Dan is het een veiligheidsrisico.

[kodak]

Dan lijkt me dat Ebay wel eerst moet uitleggen hoe dat daarin dat zou helpen, waarom dat nodig is en hoe hun klant het daar mee eens is. Dat je het systeem van je klant kan gebruiken om meer te weten te komen over de klant of mogelijke ongewenste zaken wil nog niet zeggen dat dit een goede maatregel is.

[latka]

Nee, tegen frauduleuze verkopers werkt dit niet. Het helpt bijvoorbeeld wel om te zien of de PC van een koper via remote-control overgenomen kan zijn ipv. dat het de koper zelf is.

[Bensimpel]

En als je via een VPN gaat? Lijkt me niet dat ze dan alsnog een portscan kunnen doen?

[GieltjE]

Ze verbinden op jou pc met 127.0.0.1, een VPN heeft dus geen effect hiertegen.

[FreshMaker]

Ze verbinden op jou pc met 127.0.0.1, een VPN heeft dus geen effect hiertegen.

Leg die eens uit dan ?

Want er zijn maar weinig commerciele VPNs die portforwarding toelaten, en het zou al helemaal goed zijn, als die één op één staan

127.0.0.1 is niet bereikbaar buiten het thuisnetwerk ... iig niet als je jouw PC wilt hebben, iedereen kan naar dat IPadres .... maar zijn eigen PC - het is je localhost

[Gamebuster]

Port forwarding? 127.0.0.1 is geen poort, dat is een IP.

Met een VPN zet je een tussenpersoon bij verbindingen tussen jezelf en externe webservers. 127.0.0.1 is je eigen PC, dus verbinden naar je eigen PC gaat niet via een VPN.

De website die jij bezoekt kan code uitvoeren in je browser via Javascript. In deze code kan je verbindingen leggen naar andere servers, waaronder 127.0.0.1. 127.0.0.1 verwijst naar "de machine waar deze code nu op draait". Gezien de browser op jouw computer draait, wordt er dus verbonden met jouw computer.

De informatie die hieruit opgehaald wordt, kan vervolgens verzonden worden naar een andere server, bijv. van de website die je bezoekt. Het verzenden van deze informatie gaat netjes over je VPN.

Je eigen externe IP blijft netjes verborgen, maar o.b.v. beschikbare poorten kan er dan toch informatie over je systeem verzameld worden, ondanks dat je een random IP hebt.

Zo kan je ook 1000en andere manieren vinden om een systeem te herkennen. Zie: https://fingerprintjs.com/open-source/ - Een VPN biedt hier zeer weinig bescherming tegen. De marketing van VPNs waarin ze claimen je privacy te beschermen is dan ook voornamelijk gewoon een verkoop praatje. VPN is een tool waarmee je 1 manier van het herkennen van gebruikers/bezoekers omzeilt, maar niet de 999 andere manieren.

[Reactie gewijzigd door Gamebuster op 24 juli 2024 10:10]

[Wim-Bart]

Een aanvulling over het misleidende van VPN reclames.

Het enge is dat mensen denken veilig te zijn met een VPN. Echter is er altijd een (gedeeltelijke) fingerprint van het systeem. Soms net genoeg om iemand toch te kunnen achterhalen, zie bijvoorbeeld die DoSSer die ING had aangevallen en via Tweakers is ontmaskert.

Op het moment dat iemand een externe site benaderd zonder VPN dan is er al een match te maken tussen een actie via VPN en buiten VPN om. Het meest enge daarin is dat dit dan ook nog extra gevaar met zich mee brengt wanneer je bijvoorbeeld DoH gebruikt waarbij beide fingerprints bij 1 partij liggen.

Daarnaast is er een ander gevaar, synchroniseren van favorites+cookies+accounts tussen devices. Stel je gebruikt een VPN op je telefoon of iPad buiten de deur. Je gaat via VPN dus je IP is onbekend. Sites fingerprinten je device. Je komt thuis, slingert de PC aan, je account synct, je gaat naar Facebook en je mobile device wordt gekoppeld aan je PC aan de persoon. Leuk VPN maar hielp geen zier.

En zo simpel is het. Geen moeilijke acties of techniek.

[MiesvanderLippe]

127.0.0.1 is niet bereikbaar buiten het thuisnetwerk ... iig niet als je jouw PC wilt hebben, iedereen kan naar dat IPadres .... maar zijn eigen PC - het is je localhost

Javascript draait toch in jouw thuisnetwerk, op jouw computer Harry?

[eric.1]

Ze doen een lokale scan, dus geinitieerd vanuit de browser (soort van) naar het 127.0.0.1 adres. Daar helpt een vpn niets tegen.

[jvanhambelgium]

Toch wel, als je een VPN open hebt staan dan gebruik je eigenlijk gewoon iemand anders z'n IP. Dat VPN-bedrijfje waar dan ook ter wereld z'n IP-pools (voor hun klanten) kunnen even goed een scan ondergaan hoor. Een VPN is ook maar "een tunnel" (welliswaar met versleuteling) maar ook niet meer dan dat.
Nu kan het zijn (en dat lijkt me vanzelfsprekend) dat VPN-providers ook wel een firewall hebben staan en dus niets van "buiten" binnnenlaten dat niet gerelateerd is aan lopende sessies etc. en dus zullen scans nooit tot op je VPN-client terechtkomen.

[zjorsie]

Jawel. zoals al vaker uitgelegd worden deze 'scans' door je eigen PC op zichzelf uitgevoerd, op een intern gebruikt (loopback) adres (127.0.0.1).

Het script wordt geladen via de vpn verbinding, maar als dit script wordt uitgevoerd worden de genoemde poorten via dit lokale adres gescand. Heeft dus helemaal niks met VPN te maken.

[jvanhambelgium]

Ah ok, dan is het in dit geval inderdaad niet relevant.
Maar wel van toepassing op alle andere vormen van conventioneel portscannen.

[caspar M]

Het zou ook een maatregel kunnen zijn om slachtoffers van scammers te beschermen? omdat de meeste programma's die in de lijst staan ook door die scammers worden gebruikt. Ze laten het slachtoffer dan zelf naar de website gaan om dingen te bestellen voor de scammer?

[Antipater]

Dit is het waarschijnlijk. Er zijn ontzettend veel mensen die opgebeld worden door scammers met een lulverhaal dat ze van *bekend bedrijf X* zijn en voor 200 euro ofzo hun computer van virussen afhelpen. Vervolgens halen ze de slachtoffers over hun toegang te geven via teamviewer en worden ze leeggetrokken.

Ik kan me voorstellen dat Ebay hier veel last van heeft, al is het niet hun schuld, en er dus voor kiest hun klanten stilzwijgend te beschermen. Dit is niet ongebruikelijk, financiele instellingen doen het ook.

[defixje]

Ok, en dan?

Stel ik heb VNC en Team Viewer op mijn PC staan (zelf bewust er op gezet) en RDP voor het makkelijke ook aangezet, en dan?

Gaan ze mij dan blokkeren ofzo?

Wat willen ze doen met die informatie?

[Antipater]

Ik werk niet bij ebay, dus ik heb geen idee hoe ze die informatie gebruiken.

Maar ze zouden bijvoorbeeld een security code naar je email kunnen sturen als extra beveiligingscontrole, of (grote) uitgaven kunnen blokkeren totdat je teamviewer hebt uitgezet, of enkel je uitgaven flaggen zodat er een persoon naar kijkt voor verdachte patronen. Er zijn allerlei maatregelen mogelijk die minder ingrijpend zijn dan je helemaal blokkeren.

[defixje]

Ah, daar heb je een paar goede punten ja.

[Remmilou]

Maar weer eens een oude bekende geraadpleegd: https://www.grc.com/x/ne.dll?rh1dkyd2
Shields Up van grc.com
Alles nog dicht. Ik nbeem aan dat Ebay dan tot hetzelfde resultaat komt? Of vergis ik me daarin?

[twiFight]

Als posts zoals coolkil in 'nieuws: EBay voert lokale portscan uit bij bezoekers' kloppen dan is dit dus wel degelijk anders.

Ze gebruiken dus je browser om locaal in het netwerk van de gebruiker het netwerk te scannen, waardoor de beveiliging aan de poort omzeild wordt.

[zjorsie]

Wat ik zo lees klopt de post van coolkil.

Echter een kleine nuance: dit script scant niet vanuit het netwerk, maar de loopback interface van het systeem. Ieder systeem heeft deze interface met adres 127.0.0.1 en (meestal?) localhost.

Deze interface wordt gebruikt voor allerlei interne software, en staat volledig los van je (interne) netwerk.

Door je loopback adres te gebruiken wordt er inderdaad beveiliging aan de poort omzeild.

[sfranken]

Ieder systeem heeft deze interface met adres 127.0.0.1 en (meestal?) localhost.

De omzetting van 127.0.0.1 -> localhost word op de meeste systemen in /etc/hosts (of de Windows variant daarvan, ik geloof C:\Windows\System32\etc\hosts) gedaan. De enige 'failsafe' manier om die poorten te scannen is met het IP 127.0.0.1, aangezien je zelf localhost uit je hosts file kan verwijderen als je dat wil (maar wat niet aan te raden is...)

[zjorsie]

Klopt, weet echter niet of ieder systeem de 'localhost' entry ook daadwerkelijk toevoegt.

Is (op windows) gehardcoded in de dns zo te zien (dit staat in de hosts file):

# localhost name resolution is handled within DNS itself.

[Reactie gewijzigd door zjorsie op 24 juli 2024 10:10]

[sfranken]

Op Linux standaard ook, aangezien localhost als naam door software gebruikt word met de 'lo' interface. macOS gok ik ook, maar durf ik niet te zeggen met 100% zekerheid

[DefaultError]

Gaat het zo slecht met Ebay zodat ze zich verlagen naar het kunnen verkopen van kwetsbaarheden?

[MiesvanderLippe]

Iedereen draait trackers en alle trackers doen fingerprinting. Om advertenties te verkopen moet je informatie hebben van je doelgroep, een portscan is blijkbaar waardevolle informatie.

[DefaultError]

Iedereen draait trackers en alle trackers doen fingerprinting. Om advertenties te verkopen moet je informatie hebben van je doelgroep, een portscan is blijkbaar waardevolle informatie.

Toch wel okay om er meer van af te weten dat het bestaat, en wat je er tegen kunt doen. Mogelijk dat er browsers zijn dit poortscannen kunnen tegenhouden. "Dadelijk staat eBay bij je huis te posten in een busje en wat je zo allemaal doet en waar je naar toe gaat om vervolgens je vuilnis te controleren en wat je dagelijks nuttigt/gebruikt."

Ik zie de meerwaarde van informatie verzamelen voor met name remote-control niet als een betrouwbare geste. Vragen naar wat mensen willen en ook waar mensen naar zoeken. Gewoon vragen. Privacy is inmiddels bij wet vastgelegd, voor verbetering vatbaar, en steeds belangrijker aan het worden.

Ik zie een terugkerend thema opduiken hier bij Tweakers.

[Remmilou]

Dat denk ik niet. Maar het risico dat die gegevens "lekken" / worden gestolen is er natuurlijk wel...

[Swamswam]

Marktplaats bezoeken vanuit de browser op mijn iPhone doet ook zoiets en dat gebeurt niet op de desktop gek genoeg. Bij ieder bezoek aan de site gaan de alarmbellen in mijn router door allerlei ‘privilege escalations’ en uitgaande verbindingen naar IP’s van een in de VS gevestigde beveiligingsfirma die dit soort scandiensten verkoopt. Heb me suf gezocht naar wat hier loos was op mijn telefoon in de vrees dat er iets geks aan de hand was.

[skatebiker]

Smartphones zijn wat dat betreft een stuk minder veilig, er zit geen firewall op. En tools als ublock origin kun je meestal ook niet installeren.
Niet voor niks zijn smartphones eigenlijk gewoon spionage apparaten voor bedrijven.

[innerchild]

Daarom gebruik ik Netguard. Is een noroot firewall die je gratis kan installeren. Gemaakt door een nederlander. Open source en maakt gebruik van een lokale vpn, waar je in en uit gaand verkeer kan monitoren.

https://play.google.com/s...s?id=eu.faircode.netguard

[skatebiker]

Precies ik heb Adguard dat is ook zoiets, met je lokale Android apparaat als VPN server en je kunt per app internet toegang aan en uit zetten, doet Netguard overigens ook. Werkt uitstekend.

Maar 99+% van de gebruikers weten dit niet en / of voor de gewone gebruiker is dit te ingewikkeld. En dus zijn de meeste smartphones zo lek als een mandje en daar doel ik op.

Zo'n firewall zou standaard in ieder OS moeten zitten.

[Lawrentium]

Welke router/firewall draai je, als ik vragen mag, dat deze je waarschuwt voor dit soort dingen? Draai je er IDS op?
PM mag natuurlijk ook

[Swamswam]

Ik heb een synology RT2600ac met daarop de ‘threat prevention’ en ‘safe browsing’ extensies aan. Nu ben ik maar een veredelde hobbyist en weet ik niet bijzonder veel van de dieper dingen van netwerken, maar het is heel typisch dat deze ‘threat’ melding met de verwijzing naar uitgaande traffic naar de IP’s van de VS securitybedrijf steeds omhoog komen in die threat prevention als ik naar marktplaats ga.