Nach einem kurzen Blick in die Mozilla Projekt Applikation Seite habe ich eine neue Version von Zimbra für den Desktop entdeckt. Nach kurzem denken an den Zimbra Advisory vor ein paar Monaten kam ich zu dem Entschluss einfach mal drauf los zu testen in einer lokalen Umgebung. Zimbra ermöglicht es auf yahoo, gmail und andere Postfächer zuzugreifen und diese zu verwalten. Die Funktionen die Zimbra bietet wie z.B. schnelle Verwaltung, saubere Archivierung , Kalender & Teilnehmerlisten sind sehr praktisch zu benutzen.

Als erstes gleich vorne in der Login Form eine relativ nervige XSS/CSRF Lücke die sich nur nutzen lässt wenn man die mask restriction umgehen kann. Da er z.B. im Feld für E-Mails eine Mail-Adresse erwartet gucken wir was er erlaubt. Hier bei Zimbra überprüft er nur ob ein @ & .* drin ist. Bedeutet das wir nun anstatt …

>”<iframe src=http://global-evolution.info/home.html>

den folgenden Scriptcode einfügen …

>”<iframe src=http://global-evolution.info/home.html>@global-evolution.info

remove@>”<iframe src=http://global-evolution.info/home.html>.com

Schon haben wir die kleine “restriction”(Begrenzung) umgangen da der Code auf der Seite wieder ausgegeben wird. In diesem Fall haben wir ein IFrame client-seitig eingebunden das zu unserer Seite verlinkt. Da man hier nicht aktualisieren kann oder weiter springen zu einem anderen Formular könnte man es auch als server-seitig ansehen. Aussehen könnte das z.B. so …

Was auch möglich wäre ist  clientseitiges Session stealing wie man im folgenden Bild bei einem GMail test sehen kann.

Nun wechseln wir mal von den clientseitigen XSS zu den serverseitigen input validation errors. Eine habe ich direkt im Kontaktbereich, der Applikation gefunden was man hier ziemlich deutlich sehen kann.

Danach habe ich versucht eine ältere Lücke zu testen die ich bei den früheren ZimbraMail tests genutzt hatte. Was mich erstaunt hatte das neue ZimbraDesktop hat genau diese Lücke gefixt. Im folgenden Auszug kann man es deutlich sehen wie der Angriff vom Exception-Handling abgefangen/aufgezeichnet wird.

Fehler im Netzwerkdienst

method:    SendMsgRequest

msg:    system failure: could not determine message recipients; aborting mail send

code:    service.FAILURE

detail:    soap:Receiver

trace:    btpool0-1:1249533176341:603d502171a6b40c

request:

Body: {

SendMsgRequest: {
_jsns: “urn:zimbraMail”,
m: {
e: [
0: {
a: ">"<iframe src=http://test.de>",
add: 1,
t: "t"
},
1: {
a: "1445@gmail.com",
p: "remove",
t: "f"
}
],
idnt: “70848a07-e2aa-4ffd-8eb2-2eaf2faeccb9″,
mp: [
0: {
content: {
_content: ">"<iframe src=http://test.de>"
},
ct: "text/plain"
}
],
su: {
_content: “>”<iframe src=http://test.de>”
}
},
suid: 1249533176316
}
},
Header: {
context: {
_jsns: “urn:zimbra”,
account: {
_content: “1445@gmail.com”,
by: “name”
},
authToken: “(removed)”,
format: {
type: “js”
},
notify: {
seq: 102
},
sessionId: {
_content: 154,
id: 154
},
userAgent: {
name: “ZimbraWebClient – PRISM (Win)”,
version: “0.0″
}
}
}

Dann gibt es noch eine nicht ordentliche verarbeitetes Exception-handling was die Applikation abstürzen lässt wenn man eine NullPointer Exception auslöst.

Da am Ende alle Tests bei den Anhängen wieder etwas einzubinden fehl schlugen, habe ich versucht in der Applikation(server-seitig) über einen gerade gefunden Validation Error eigene Anwendungen zu starten die Code ausführen. Hier ist ein Angriff möglich da Fehleingaben in Previews gezeigt werden, die dann wenn Scripts eingebunden wurden auch angezeigt werden.

Hier kann ich Zimbra nur empfehlen diese Lücke dringend zu fixen da sie echt potenzial für gezielte Angriffe bietet. Ebenso sollten auch schnellst möglich die XSS Lücken im Loginbereich gefixt werden auch wenn das potenzial hier definitiv kleiner ist als bei den serverseitigen Sicherheitslücken. Das Problem beim Login ist das über den Multi-Login das Abfangen von Sessions noch erleichtert wird.

[Writer: remove]