mehrere Fehler in Kerio 2.1.4 |
||
---|---|---|
#0
| ||
03.05.2003, 08:59
Ehrenmitglied
Beiträge: 2283 |
||
|
||
03.05.2003, 10:08
Moderator
Beiträge: 6466 |
||
|
||
03.05.2003, 10:18
Member
Beiträge: 5291 |
#3
Gibts keine updates // patches // sonstiges für das dingen?
Ist die ver. 2.1.4 eigentlich die neuste? BETA? __________ E-Mail: therion at ninth-art dot de IRC: megatherion @ Freenode |
|
|
||
03.05.2003, 10:28
Moderator
Beiträge: 6466 |
#4
Ich vermute "nein", denn Kerio bastelt ja schon seit längerer Zeit an der 3-er-Version, nicht gerade sehr erfolgreich wie mein Eindruck ist. aber mal sehen.
Wenn es so ist, wie ich vermute, ist lediglich darauf zu achten, dass die DNS-Regel nicht als erste Regel im Rule-Set platziert ist. __________ Durchsuchen --> Aussuchen --> Untersuchen |
|
|
||
03.05.2003, 10:32
Ehrenmitglied
Themenstarter Beiträge: 2283 |
#5
Naja, also DNS sollte schon sehr weit oben sein, denn es ist ja ne Frage der Zeit und DNS Anfragen sind nunmal sehr häufig. Deswegen ist das schon recht kritisch.
Quelle: http://www.securiteam.com/securitynews/5FP0N1P9PI.html Dazu dann noch: http://www.securiteam.com/windowsntfocus/5VP10009PQ.html - Vulnerabilities in Kerio Personal Firewall (Buffer Overflow, Replay) - __________ powered by http://different-thinking.de - Netze, Protokolle, Sicherheit, ... |
|
|
||
03.05.2003, 10:38
Member
Beiträge: 5291 |
#6
Hmm ist eigentlich egal wo die DNS Rule steht und wenn sie am ende steht, die Firewall wird solange suchen bis eine zu trifft.
Ist doch so oder? __________ E-Mail: therion at ninth-art dot de IRC: megatherion @ Freenode |
|
|
||
03.05.2003, 10:55
Ehrenmitglied
Themenstarter Beiträge: 2283 |
#7
Ja ist so, aber du kannst dann weiter oben Regeln definieren, die alles andere dicht machen bzw. soweit wie möglich. Ich denke auch, daß da ein Restrisiko bleibt.
R. __________ powered by http://different-thinking.de - Netze, Protokolle, Sicherheit, ... |
|
|
||
03.05.2003, 14:57
Member
Beiträge: 813 |
#8
Keine Panik - diese "Sicherheitslücke" zeigt nur eins: dass man sich nicht auf Default-Einstellungen verlassen sollte.
Das Problem liegt einfach darin, dass die Default-Regel für "any application" gilt. Muss das sein? Natürlich nicht! Unter NT-basierten Systemen erledigt (im Normalfall) die berüchtigte 'svchost.exe' alle DNS-queries, und unter Win9x machen das die Internet-Programme selber. Also kann man diese Regel problemlos an einzelne Programme 'binden', und so das Problem komplett umgehen. Es geht sogar noch besser: wenn man als 'remote IP' nur die vom ISP zugewiesenen DNS-Server einträgt (bleiben normalerweise gleich), kann erst recht kein Angreifer diese Regel ausnutzen. edit: Mich würd in dem Zusammenhang mal interessieren, wie das bei solchen FWs ist, die nur ganz pauschal "DNS zulassen" oder "verbieten" vorsehen (ZA, Outpost,...). Hier müssen ja ähnlich 'lockere' Freigaben erteilt werden, wie bei den Default-Rules von Kerio, damit es nicht zu Problemen kommt. Nur: bei diesen anderen FWs kann man diese Lücke nicht schließen... oder? __________ "Scheinsicherheit" - wie leicht lassen sich Viren- und Trojanerscanner austricksen? Dieser Beitrag wurde am 03.05.2003 um 15:16 Uhr von forge77 editiert.
|
|
|
||
03.05.2003, 15:15
Member
Beiträge: 3306 |
#9
Und die Adressen der DNS-Server gibt es u. a. hier:
http://www.fli4l.de/german/dns.htm __________ Bitte keine Anfragen per PM, diese werden nicht beantwortet. |
|
|
||
03.05.2003, 16:07
Member
Beiträge: 5291 |
#10
@forge77
Exakt mein Server reagiert auch nur auf 3 Nameserver meines ISPs und auf keine anderen. __________ E-Mail: therion at ninth-art dot de IRC: megatherion @ Freenode |
|
|
||
that is shipped with default rules. Every incoming / outgoing packet is
compared against the default rule-set. As the first rule accepts incoming
packets if remote port is equal to 53 (DNS) the firewall can be easily
bypassed by setting the source port of the attack to 53.
DETAILS
Vulnerable systems:
* Kerio Firewall version 2.1.4
Exploit:
Using the following line will allow you to scan port 1900 on a remote
server:
nmap -v -P0 -sU -p 1900 192.168.0.5 -g 53
---
Replay attack:
A replay attack is possible against the authenticated/encrypted channel for remote administration. A design problem in the authentication mechanism for remote administration allows an attacker to replay captured packets from a valid remote administration session in order to reproduce the administrator's directives to the personal firewall.
For example if the attacker is able to sniff a valid session in which the administrator disabled the firewall capabilities, then the attacker will gain the ability to disable the personal firewall at will at any time in the future.
Buffer overflow:
A remotely exploitable buffer overflow exists in the administrator authentication process.
Solution/Vendor Information/Workaround:
Contact the vendor for a fix.
Workaround:
Disable the remote administration feature.
__________
powered by http://different-thinking.de - Netze, Protokolle, Sicherheit, ...