6 Antworten in diesem Thema

[sub0]

Hey Leute, ich würde gerne von euch hören, welche Protokolle eure Favoriten sind oder mit welche ihr gute/schlechte Erfahrungen ihr gemacht habt.
 
Ich persönlich liebe HTTP(S). Ich Liste hier einige Punkte auf und bin offen für eure Kritik und alternative Methoden.
 
Vorteile

• Es ist ein Klartext Protokoll
• Es ist auf dem TCP/IP Layer aufgebaut (Keine eigene Socket Programmierung nötig)
• (Fast) Jede Programmsprache hat ein HTTP Client Library
• Es ist sehr leicht zu bedienen und selbst zu implementieren (falls keine Libs zur Verfügung stehen)
• Sollte via Reverse Conncetion ohne Probleme durch jede Firewall durchkommen
• Den Server Part können, vorhande Webserver übernehmen. (z.B. NGINX, Apache, etc)
• Durch TLS/SSL-Zertifikate ist die Verbindung mit dem Webserver (C2) verschlüsselt (Cert-Pinning bzw. Fingerprint Verifizierung implementieren nicht vergessen!)
• Mit Reverses-Proxies (nginx) und Redirector (z.B. socat) kann man den Haupt C2 Standort verschleiern

Nachteile

• Webserver kann nicht "pushen" der Client muss nach neuen Befehlen "requesten"
• Bidirektionale Verbindungen sind nicht so ohne weiteres möglich (Abhilfe vielleicht mit Websockets oder HTTP/2 ?)
• Dadurch dass HTTP/1.x ein Klartext Protokoll ist, entsteht oft sehr viel unnötiger und wiederholter Traffic

Alternativen

• HTTP/2 und SPDY
• MQTT oder ZMQ
• XMPP

 

Jetzt seid ihr dran. Postet eure Meinung/Kritik und eure Favoriten und bitte mit Begründung, damit wir alle mitlernen.

[samimedoaff]

Würde da eindeutig auf HTTPS setzen. Die negativ-behaftete Bidirektionalität kannst du mit Websockets implementieren. Wiederholter Traffic lässt sich über einen Round-Robin vermeiden, kannst da theoretisch auch neuere Methoden nutzen, C2 Kommunikation via:

 

- Google Translator:

Please Login HERE or Register HERE to see this link!

- Github:

Please Login HERE or Register HERE to see this link!

 

Da geht dein malicious Traffic "dann unter".

Zu den Alternativen:

 

- HTTP/2 => Leider noch etwas holprig und kaum Standart, würde daher eher auffallen, selbiges für SPDY/MQTT/ZMQ und Jabber

[im_nobody]

Vorteil:

- HTTPS  ist im Vergleich zu anderen Protokollarten recht unauffällig

 

Nachteil:

- Botnetze deren C&C Server auf einem Webserver laufen und auf das DNS angewiesen sind, sind sehr anfällig für DNS Sinkholing

- Ip/Domain könnte in einem Firewall Filter aufgenommen werden (z.B. von Spamfilter), somit sind diese Bots "tot".

- IP/Domain vom C&C kann leicht ermittelt werden

 

 

Durch TLS/SSL-Zertifikate ist die Verbindung mit dem Webserver (C2) verschlüsselt (Cert-Pinning bzw. Fingerprint Verifizierung implementieren nicht vergessen!)

 

Viele Firewalls bieten eine DPI Funktion an und können zumindest Teile des Traffics mitlesen!

 

P2P Botnetze:

Vorteile:

- Dezentral

- Bots können als Proxys agieren und somit dazu beitragen die Identität des C&C Servers zu verschleiern.

 

Nachteile:

- Fehler in der Verschlüsselung der Kommunikation oder in der Authentifizierung ermöglicht es Angreifern eigene Befehle an die Bots zu versenden

 

Man könnte für die Kommunikation auch das DNS-Protokoll verwenden

[IRET]

Man sollte immer praktisch denken bei sowas.

 

Websockets sind etwas anstrengender als HTTP zu implementieren. Indem man das Timeout beim HTTP setzt kann man 1 Verbindung offen lassen für Push-Nachrichten, während diverse Anfragen zum C&C über einen weiteren Request gesendet werden.

 

Bei HTTPS sollte man aber beachten dass URLs nicht vercshlüsselt werden. Also GET-Parameter werde im Klartext übertragen. Außerdem sind lokal installierte CAs mit Interceptors da ein Problem wenn Traffic nicht mitgelesen werden soll.

 

 

Die Protokolle bestimmt man dann aber eh je nach Anwendungsgebiet und da gehört die Malware-Szene jetzt nicht zu den Inventoren. P2P-Botnetze sind unrealisitisch für den kleinen Mann. Die meisten Router haben mittlerweile standardmäßig UPnP aus und Malware die auf Server aus ist ist sowieso entweder ein Reinfall (HF Booter zB) oder was für große Projekte.

 

DNS-Protokoll für die Kommunikation dürfte ich was verpasst haben. Ich kenne da nur DNS-Cache-Bruteforce (wenn Antwort schneller kommt, wurde die von wen anderen vorher angefragt).

Was mir da einfällt ist aber NTP mit dem monlist Command. Da werden bis zu 600 Hosts gelistet die zuletzt mit dem NTP-Server kommuniziert haben. Ist aber wegen der Nutzung von NTP Amplification Floods weniger geworden (aber gibt es noch).

[sub0]

Bei HTTPS sollte man aber beachten dass URLs nicht vercshlüsselt werden. Also GET-Parameter werde im Klartext übertragen. Außerdem sind lokal installierte CAs mit Interceptors da ein Problem wenn Traffic nicht mitgelesen werden soll.

Da muss ich dir widersprechen. DNS Anfragen zu einer Domain werden nicht verschlüsselt. Alles andere was mit HTTP(S) zu tun hat, ist TLS/SSL-Verschlüsselt. Ich lasse mich aber gerne belehren in der Hinsicht.

 

Die Protokolle bestimmt man dann aber eh je nach Anwendungsgebiet und da gehört die Malware-Szene jetzt nicht zu den Inventoren. P2P-Botnetze sind unrealisitisch für den kleinen Mann. Die meisten Router haben mittlerweile standardmäßig UPnP aus und Malware die auf Server aus ist ist sowieso entweder ein Reinfall (HF Booter zB) oder was für große Projekte.

Ja, da stimme ich dir zu. Je nach Anwendung sollte die Malware/Spyware programmiert werden, außer natürlich man will etwas generisches programmieren.
 

DNS-Protokoll für die Kommunikation dürfte ich was verpasst haben. Ich kenne da nur DNS-Cache-Bruteforce (wenn Antwort schneller kommt, wurde die von wen anderen vorher angefragt).

Ja, doch nennt sich DNS Exfiltration, DNS Tunneling, etc. Google mal danach, sehr interessantes Thema.

[samimedoaff]

 

 Bei HTTPS sollte man aber beachten dass URLs nicht vercshlüsselt werden. Also GET-Parameter werde im Klartext übertragen

 

Das ist leider nicht korrekt. "HTTPS" requests sind "HTTP requests" über eine verschlüsselte (SSL/TLS) TCP Verbindung. "URLs" oder "GET-Parameter" sind Bestandteile vom HTTP Header (Location) und somit verschlüsselt.

 

 

- Botnetze deren C&C Server auf einem Webserver laufen und auf das DNS angewiesen sind, sind sehr anfällig für DNS Sinkholing

 

DGA Generation könnte da Abhilfe schaffen, beschrieben z.B. hier:

Please Login HERE or Register HERE to see this link!

[sup3ria]

Kann dir HTTP/2  gRPC streams mit protobuf empfehlen.

 

Verwende Ich in produktion seit einigen jahren fuer IoT wo man auch keine Firewall usw auschalten kann.

 

 

Bei HTTPS sollte man aber beachten dass URLs nicht vercshlüsselt werden. Also GET-Parameter werde im Klartext übertragen.

Die Parameter werden bei GET sehrwohl verschluesselt nur nicht der Host.

Bearbeitet von sup3ria, 03 December 2019 - 22:17 Uhr.