Mittlerweile gibt es einige aufwändigere Applikationen (RIAs) und sogar
x86-Emulatoren in Java und jede Menge Spielerein diesbezüglich auf
Webseiten im Browser.
Jede Webseite mit Java die man besucht KANN einen 'Tunnel' oder Gateway
ins eigene Heimnetz für den Webseiten-Betreiber oder Server
bereitstellen....
1
let socket = new WebSocket("http://localhost/");
2
3
let socket = new WebSocket("http://fritz.box/internet/internet_settings.lua");
Beispielsweise konnte eine Webseite mein Heimnetz abscannen (Portrange)
und aktive Nodes anzeigen, oder die AVM-Seite feststellen welchen
FritzBox-Type (7490) ich besitze. Jede Menge Heimgeräte, vor allem weil
man sie ja "Zuhaue im Heimnetz" ungeschützt(er) lassen kann (so dachte
ich), finde ich von solchen Aktionen bedroht, das hatte ich -fixiert auf
die WAN-Hardware-Firewall- noch gar nicht wirklich bedacht! Jeder
Client, auch das Handy kann da Gateway werden. Gewisse "Aktionen" gehen
auch über Seitenaufrufe hinweg, und laufen dann einfach (für einen
längeren Zeitraum) weiter "durch". Jeder Seitencode und Werbebanner
"darf" das.
Ich weiß nicht, wie weit sich mit Browser und Java "Pakete" manuell
erzeugen lassen, sodass 'jeder' neben HTTP auch FTP oder gar SNMP u. SMB
etc. im Heimnetz 'bruteforcen' könnte. Und dann ist es bis zu einem
"richtigen" VPN-Tunnel auch nicht mehr weit.
Das ist eine heftige Lücke, sobald das "Feedback" wieder irgendwo per
Java Ajax Timer etc hochgeladen wird.
Kann ich "Cross-Content" Aktionen von externen Webseiten in das Heimnetz
vom Browser oder Java irgendwie verhindern? Beispielsweise so, dass das
FritzBox-Java-Gui trotzdem noch im Browser funktioniert!? Nur eben die
"Fremd-Domains" der besuchten Seite erst mal ausgeschlossen werden?
Zumindest meine Heim-Domain? Als "Kastrierter Browser" kann mich das
dann nicht mehr so leicht und schnell fic**n.
"Firefox-ESR" in
Debian 10
Android
und FreeBsd
Gruß, tsx.
Mario M. schrieb:> Java-Applets dürfen nur zu dem Rechner, von dem sie geladen worden> sind, Netzwerkverbindungen herstellen."
Ja eben, das dachte ich auch!
Und sorry: Javascript(?) meinte ich damit hauptsächlich! Also das, was
bei "ganz normalen" Webseiten -wie hier- läuft. (Nicht mehr die alten
Applets)
OT: Bei Flash /im Flashplayer war es so.
Es musste von allen beteiligten Servern erlaubt werden - ähnlich wie bei
robots.txt. Da konnte man nicht einfach ins Heimnetz!
Aber das hier ist ja ein "Free-Runner". Praktisch alle Webseiten laden
ihren Content irgendwo anders her. Ist also normal? Ich würde es gerne
Einschränken!
Joggel E. schrieb:> zB NoScript als firefox add-on
Es war schon irgendwo klar, das das wieder kommt...
Und es ist ja schon drauf. Damit ist gleich "alles" still gelegt. Das
"restliche" oder andere Scripts der Seite oder des Servers sollen aber
ggf noch weiter laufen können!
Trotzdem Danke. ;-)
So ein Dialog oder eine Meldung wie beim "Passwort-Speichern" wäre
super:
1
http://google.de möchte auf ihr Netzwerk (192.168.178.1:80) zugreifen. Erlauben?
2
[ ] Ja [x] Nein
Dann kann man in Zukunft immer gleich einen Bogen um solche Sites
machen.
Ich würde diesen Fall (externe Webseite-> internes Heimnetz) gerne immer
unterbinden u. verbieten. Auch für die Seiten wo man Script im Blocker
in der Regel zulassen muss - eben die RIAs usw.
Hat da jemand eine Idee?
Mario M. schrieb:> Wie kommst Du darauf?> "Java-Applets dürfen nur zu dem Rechner, von dem sie geladen worden> sind, Netzwerkverbindungen herstellen.">> https://www.bsi.bund.de/DE/Themen/StandardsKriterien/ISi-Reihe/ISi-Web-Server/aktive_inhalte/definitionen/definitionen_java_node.html
Er kann Java und JavaScript nicht auseinander halte.
@TS:
Kannst du belegen, dass dieser Angriff funktioniert? Gibt es ein PoC
dafür? Ich halte es für eher unwahrscheinlich, dass das, was du
beschreibst, nicht irgendwie unterbunden wird.
Andernfalls könntest du natürlich ein PoC veröffentlchen und der Ruhm
wär dir sicher.
Tim S. schrieb:> So ein Dialog oder eine Meldung wie beim "Passwort-Speichern" wäre> super:http://google.de möchte auf ihr Netzwerk (192.168.178.1:80)> zugreifen. Erlauben?> [ ] Ja [x] NeinDann kann man in Zukunft immer gleich einen Bogen um> solche Sites> machen.>> Ich würde diesen Fall (externe Webseite-> internes Heimnetz) gerne immer> unterbinden u. verbieten.
Gibts es Anhaltspunkte, dass dies möglich wäre?
Javascript ausschalten ist wohl die einzige "Lösung" !
Mittlerweile bin auf Debian und weiß es noch nicht 100%ig.
Habe auch zur Vorsicht gefragt (und passiv mitgeteilt).
Sorry das vorhin war noch auf Windows 7 mit Firefox wo das
PrivatNetz-durchsuchen definitiv möglich war.
1
Which browsers and operating systems are affected?
2
3
I've tested this and found it to work on the following systems:
Wer ne FritzBox hat:
http://avm.de/nc/service/zack-der-speedtest-fuer-ihre-breitbandverbindung/
Scheinbar ließt die Seite Fritz-Modell und, OS-Version sowie die
Ausgehandelte Bandbreite vom Modem über Javascript vom Gerät im Heimnetz
raus. Die Werte stehen direkt auf der Seite.
Und: Wie soll das auch sonnst funktionieren? Wenn der Server (avm.de)
sich das übers WAN auslesen traut wäre das (ein anderes Thema, aber) ja
noch heftiger! /Auch heftig.
1
Ihre FRITZ!Box
2
FRITZ!OS
3
Aktuelle Datenrate
Und ja, das macht es auch auf Debian10 Firefox.
Gruß
Tim S. schrieb:> https://defuse.ca/in-browser-port-scanning
Das Javascript hat aber keinen Zugriff auf das Netzwerk. Es veranlasst
den Browser etwas zu laden und an der Dauer des Ladevorganges kann es
erkennen, ob dort etwas ist. Es hat keinen Zugriff auf die geladenen
Inhalte.
Für die Seite mit der Fritzbox gilt das gleiche.
Also ist es "normal", dass ein Speedtest verraten kann wie schnell dein
Modem Synchronisiert ist, wie das Modell samt Firmwareversion heißt -
und das alles bevor überhaupt "Datentraffic zum Speed-Messen" angefallen
ist!?
Nee das wird schon "irgendwie" ausgelesen! Und erst wesentlich später
(nach dem Test) erhält man die "realen Speed-Werte". Das kenne ich auch
wirklich nur von dieser Seite so. Hast du das selber versucht?
Mario M. schrieb:> und an der Dauer des Ladevorganges kann es> erkennen, ob dort etwas ist. Es hat keinen Zugriff auf die geladenen> Inhalte.
Ich kenne die Scripte die so sind und aufs "Timeout" reagieren. Naja man
kann im Falle einer vorhandenen Antwort eben schon das XML oder JSON bzw
ein ByteArray(?) per Javascript am Browser/Client auswerten u.
weiterverarbeiten sowie anhand dessen Werte z.B. Bilder und neue Texte
darstellen und Quer Up- u. Downloaden - auch mit Timern und Events im
Hintergrund, ohne eine Aktion selber machen zu müssen. So funktioniert
der Ajax-Kram und so läd z.B. GoogleAds ein neues Bild in den Banner
rein. Ganz genaues weiß ich aber auch nicht.
Was nicht geht ist, dass es automatisch diese "Login-Phase"
überschreitet - Und dann mit Benutzerauthentifizierung "arbeitet" - z.B.
wenn man sein Passwort für eine Seite oder Gerät (oder 'htaccess' mäßig)
gespeichert hat! Das "darf" der Browser nicht.
Eine Software-Firewall an den Clients, so dass der Browser gar nicht in
private Netze darf, ist zwar möglich aber für mich leider gar nicht
praktisch. Und das auf jeder Plattform einrichten usw neee. So ein
Dialog bzw. Meldung beim Privatnetz-Zugriff aus fremden Seiten kam mir
daher als erstes in den Sinn. Irgendwo fehlt mir dieses "Feature" im
Browser:
-> Den "Cross-Content" von lokaler bzw. privater Domain o. Netz-Bereich
erst manuell zulassen und erlauben!
1
http://google.de möchte auf ihr Netzwerk (192.168.178.1:80) zugreifen. Erlauben?
2
[ ] Ja [x] Nein
Und einen 'Haken' für "Seite immer erlauben". Sieht doch richtig schön
abschreckend aus.
Da wird gar nichts ausgelesen. Es werden Informationen, die die Fritzbox
unter "fritz.box" sowieso loginfrei zur Verfügung stellt, vom Browser
eingebunden. Die Javascripte kommen aber an diese Daten nicht heran. Im
Gegensatz zu den Werten die der Browser liefert, wie
Bildschirmauflösung, Browserversion und Betriebssystem. Da sehe ich die
einzige Lücke im System, weil diese Daten an die Webseite zum Tracking
weitergegeben werden können.
Mario M. schrieb:> Da wird gar nichts ausgelesen. Es werden Informationen, die die Fritzbox> unter "fritz.box" sowieso loginfrei zur Verfügung stellt, vom Browser> eingebunden.
Bist du dir da ganz sicher??
http://fritz.box:49000/igddesc.xml (OK)
http://fritz.box:49000/jason_boxinfo.xml (N/A, timeout)
x = [...].responseXML.getElementsByTagName("BoxInfo");
> Die Javascripte kommen aber an diese Daten nicht heran.
Da läuft ein kleiner Script-Batzen auf der Seite. Der Browser und
Javascript holen sich die "Happen" aus dem XML - einzeln in Variablen
heraus. Die Stammen aus dem Heimnetz.
> Im Gegensatz zu den Werten die der Browser liefert, wie> Bildschirmauflösung, Browserversion und Betriebssystem.
Das sendet der Browser bei jedem HTTP Request. Das kann ich aber
komplett selbst beeinflussen, und ich bin froh, eine entsprechend
angepasste Seite für mein System zu erhalten. Und ausserdem: Schön das
noch jemand weiß, dass ich auf Linux ohne FullHD im Firefox surfe. Es
dient, damit ich es selber nicht vergesse!!? Aber das sind Daten mit
denen kann eigentlich überhaupt niemand etwas anfangen. Würdest du dafür
Zahlen wollen oder Geld ausgeben um zu erfahren was denn nun bei den
paar Werten "heraus gekommen" ist? Ist das so geheim? Gääähn. Im
Vergleich zu den Cross-Domain-Möglichkeiten ins Privatnetz ist das
einfach nur ein Witz und der ist schon soooo UHRALT!
> Da sehe ich die> einzige Lücke im System, weil diese Daten an die Webseite zum Tracking> weitergegeben werden können.
Achso.
Mario M. schrieb:> Da wird gar nichts ausgelesen. ...> Die Javascripte kommen aber an diese Daten nicht heran.
Die Werte der FritzBox XML-Datei sind im Scriptverlauf in einzelnen
Variablen festgehalten worden! Kann Javascript seine eigenen Daten wohl
nicht verarbeiten?? Was willst du mir da erklähren? Wie meinst du das?
Das Script hat die Werte. Die werden auf der Webseite verarbeitet
dargestellt - ja auch eingebunden - und am Schluss wird es sogar noch zu
AVM übermittelt. Nichts anderes hatte mich beunruhigt. Denn das
"Verfahren" kann man ja praktisch immer im Hintergrund ausführen!
Jemand könnte z.B. auch am XBMC/Kodi OSMC Webinterface herumschrauben,
da es noch (Standardmässig) ohne Passwort und unverschlüsselt per HTTP
errichbar ist. Oder die IP-Cams und das IoT-Zeuch - alles muss man
double-Checken. [Und ein ISP-NAT Router mit Firewall wird immer
überflüssiger...]
OK alles per Passwort dicht machen und Javascript ausschalten ist erst
mal die einzige Lösung!
Tim S. schrieb:> Da läuft ein kleiner Script-Batzen auf der Seite. Der Browser und> Javascript holen sich die "Happen" aus dem XML - einzeln in Variablen> heraus. Die Stammen aus dem Heimnetz.
Ok. Du hast Recht, das Script liest wirklich Daten direkt aus der
Fritzbox. Das geht aber nur, weil die Fritzbox dem Browser explizit
erlaubt, diese Daten weiterzugeben. Stichwort: CORS. Also ist es ein
erwünschtes Verhalten und keine Sicherheitslücke.
Tim S. schrieb:> Jemand könnte z.B. auch am XBMC/Kodi OSMC Webinterface herumschrauben,> da es noch (Standardmässig) ohne Passwort und unverschlüsselt per HTTP> errichbar ist. Oder die IP-Cams und das IoT-Zeuch - alles muss man> double-Checken.
Nein, außer deren Programmierer machen auch so einen Frickelkram wie die
AVM-Programmierer.
Mario M. schrieb:> Stichwort: CORS. Also ist es ein> erwünschtes Verhalten und keine Sicherheitslücke.
Okay das wusste ich vorher noch nicht.
Allgemein hat mich "diese Prozedur" etwas erschrocken!
'Einfach so' durch die privaten LANs der Clients laufen :-) LöL
Das ist anscheinend schon ca 23 Jahre so "geblockt" und definiert.
Durch CORS (und den Header) kann es dann also nicht jeder auslesen.
Danke für die Aufklärung!
Gruß tsx
Tim S. schrieb:> Und ausserdem: Schön das> noch jemand weiß, dass ich auf Linux ohne FullHD im Firefox surfe. Es> dient, damit ich es selber nicht vergesse!!? Aber das sind Daten mit> denen kann eigentlich überhaupt niemand etwas anfangen.
Falsch; mit diesen Daten vom Header lassen sich Benutzer zu einem sehr
hohen Wahrscheinlichkeitsgrad wiedererkennen und zuordnen. Denn welche
zwei Personen benutzen schon das exakt gleiche Betriebssystem, gleichen
Browser, gleiche Browserversion, gleiche Bildschirmauflösung, etc.
Und das wird auch schon viele Jahre lang so verwendet.
Hier mehr Infos dazu:
https://www.chromium.org/Home/chromium-security/client-identification-mechanisms#TOC-Browser-level-fingerprints
Ich benutze ublock im Expertenmodus.
Damit kann man sehr genau steuern, Woche Webseite von wo Inhalte laden
darf und welche man Global aktiviert.
Ist natürlich wir noscript auch, teilweise relativ fummelig,
herauszufinden, welche Sachen der aktuellen, neuen Seite freigeschaltet
werden müssen, damit sie vernünftig funktioniert
Mario M. schrieb:> Es hat keinen Zugriff auf die geladenen> Inhalte.
Darf eine externe Webseite ein Javascript von einem Gerät im Privatnetz
"einbinden" (?), und dieses Script wiederum an dem Gerät "herumpfuschen"
- von der externen Webseite gesteuert? Man kann ja mehrere Scripte auf
der Seite "zusammenführen" - könnten die Scripts ihre "Variablen
austauschen und sehen"?
Oder geht kein Cross-Domain Scripting!?
Muss das Script seine "Root-Domain" im Browser und Adresszeile bzw. CORS
Header sehen?
Thread beobachten
Seitenaufteilung abschalten