Naja ... So einfach ist das auch nicht

[hgerstung]

Das ist sicher eine veritable Sicherheitslücke, aber warum man sich dabei an NTP aufhängt, verstehe ich nicht so ganz. Damit ein Angreifer die Attacke auch ausführen kann, muß eine dem Delorean Tool ähnliche Software auf dem Zielrechner oder auf einem Router zwischen Zielrechner und NTP Server laufen, das die NTP Pakete manipuliert. Letzteres kann man wirksam dadurch bekämpfen, dass man mehrere Server konfiguriert die über möglichst unterschiedliche Routen erreichbar sind.

Wenn der Angreifer aber eine solche Software auf dem Zielrechner installieren kann, die den Netzwerkverkehr kapert, dann kann er auch gleich direkt die Zeit verstellen. Hat nix mit NTP zu tun.

Auch das Time Skimming ist relativ lachhaft. Daß jemand nicht merkt, wie seine Systemzeit rasend schnell wegläuft halte ich für unwahrscheinlich.

Wer übrigens ntpd benutzt (www.ntp.org), der kann die Gefahr im Bezug auf eine Manipulation von NTP minimieren. Die Funktionsweise von ntpd hat den sogenannten Panic Threshold (default auf 1000 Sekunden) und wenn die Zeit plötzlich im laufenden Betrieb um mehr als diese 1000 Sekunden springt, beendet sich ntpd selbst und stellt die Systemzeit nicht. Das ist nur beim Starten von ntpd erlaubt.

Auch wer seine eigenen NTP Server betreibt und z.B. symmetrische Keys verwendet, verhindert eine MITM Attacke auf NTP.

Ich erkenne an, daß das Zeitlimit für HSTS ein Problem darstellt, aber dass das was mit NTP zu tun hat, halte ich für weit hergeholt.

[hjp]

hgerstung schrieb:
--------------------------------------------------------------------------------
> Das ist sicher eine veritable Sicherheitslücke, aber warum man sich dabei
> an NTP aufhängt, verstehe ich nicht so ganz.

Weil es eine Attacke gegen NTP ist. Dass man die solcherart verstellte
Zeit auch gegen HSTS verwenden kann (genauso wie gegen zig andere
Protokolle), dient wohl nur dazu, das ganze als irgendwie neu
darzustellen.

> Damit ein Angreifer die Attacke auch ausführen kann, muß eine dem
> Delorean Tool ähnliche Software auf dem Zielrechner oder auf einem
> Router zwischen Zielrechner und NTP Server laufen, das die NTP Pakete
> manipuliert. Letzteres kann man wirksam dadurch bekämpfen, dass man
> mehrere Server konfiguriert die über möglichst unterschiedliche Routen
> erreichbar sind.

Bis zum eigenen ISP dürften diese Routen aber ziemlich identisch sein,
und dort ist der wahrscheinlichste Ort für eine MITM-Attacke.


> Wenn der Angreifer aber eine solche Software auf dem Zielrechner
> installieren kann, die den Netzwerkverkehr kapert, dann kann er auch gleich
> direkt die Zeit verstellen. Hat nix mit NTP zu tun.

Auf dem Zielrechner muss er nichts installieren. Es handelt sich um eine
MITM-Attacke. Wenn man annimmt, dass jemand eine MITM-Attacke gegen HTTP
fahren kann, muss man auch annehmen, dass er eine gegen NTP fahren kann.

> Wer übrigens ntpd benutzt (www.ntp.org), der kann die Gefahr im Bezug auf
> eine Manipulation von NTP minimieren. Die Funktionsweise von ntpd hat den
> sogenannten Panic Threshold (default auf 1000 Sekunden) und wenn die Zeit
> plötzlich im laufenden Betrieb um mehr als diese 1000 Sekunden springt,
> beendet sich ntpd selbst und stellt die Systemzeit nicht. Das ist nur beim
> Starten von ntpd erlaubt.

Gerade das könnte aber ein Problem sein: Denn wenn der ntpd nicht (mehr)
läuft, dann kann die Zeit mittels ntpdate gestellt werden, was z.B.
unter Debian/Ubuntu passiert, wenn ein Interface online geht.


> Auch wer seine eigenen NTP Server betreibt und z.B. symmetrische Keys
> verwendet, verhindert eine MITM Attacke auf NTP.

Sofern es Stratum-1-Server sind ...


> Ich erkenne an, daß das Zeitlimit für HSTS ein Problem darstellt, aber dass
> das was mit NTP zu tun hat, halte ich für weit hergeholt.

Im Gegenteil, es hat nur mit NTP zu tun, nichts speziell mit HSTS. Die
Systemzeit ist eine Resource, die ein Betriebssystem zur Verfügung
stellt, und eine Applikation muss sich darauf verlassen können - gerade
im Security-Bereich spielt die Zeit eine große Rolle. Wenn ein OS die
falsche Zeit liefert, kann man das dem Protokoll genausowenig ankreiden
wie wenn es z.B. schlechte Zufallszahlen liefert.