OWA Keep-Alive in http, anche se dovrebbe essere forzato https

2

Ieri ho ricevuto un avviso dall'ID di un cliente che è stato rilevato un pacchetto di autorizzazione Base64. Osservando la decodifica ASCII, posso vedere che è per il loro OWA (Outlook Web Access), e infatti, le informazioni di auth erano Base64, facilmente decodificate con il nome utente / password di un utente.

Ciò che è strano è che il server Exchange di questa azienda è configurato per non consentire mai connessioni non crittografate (via HTTP o POP / SMTP). Reindirizzerà sempre http to https prima che sia richiesta l'autenticazione.

Da quando ho ricevuto questo avviso, ho richiesto altri avvisi dello stesso tipo, ma non trovo molto altro ... Sembra un caso limite.

Qualche idea su cosa sta succedendo?

=====Ascii Decode of packet====

GET./.HTTP/1.1
Host:.xxxxxx.com 
User-Agent:.Mozilla/5.0.(iPod;.CPU.iPhone.OS.5_0_1.like.Mac.OS.X).AppleWebKit/534.46.(KHTML,.like.Gecko).Version/5.1.Mobile/9A405.Safari/7534.48.3
Accept:.text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Authorization:.Basic.xxxxxxxxxxxxxxxxx==
Accept-Language:.en-us
Accept-Encoding:.gzip,.deflate
Cookie:.UserContext=ecc88b90b86c483f89db34eb673c259c;.OwaLbe={A907E8ED-3881-4B44-B84E-F036E6485722}
Connection:.keep-alive
    
posta Josh Brower 08.02.2012 - 14:07
fonte

3 risposte

1

Informazioni sul pacchetto di autorizzazione Base64, è correlato a questa discussione nelle comunità di McAffee qui . Questo perché, hanno impostato la modalità di autenticazione di base per OWA.

Il problema è spiegato in dettaglio, alcune delle spiegazioni:

Basic Authentication is a means to send usernames and passwords over the network to log into a device upstream. This form of authentication is inherently insecure because it is sent in plain text over the network, however, it is widely adopted by most clients/servers which still makes it relatively popular, especially in multi-platform environments. We strongly suggest that if you are going to use it, then you should use it over HTTPS (SSL/TLS), to prevent anyone from using a packet sniffer and picking up passwords while in transit.

Basic Authentication is simply a base64 encoded username/password sent across the wire as user_name:password

To base64 encode a username and password: echo -n "valid_user_name:valid_user_password" | openssl base64 -base64

Per quanto riguarda la comunicazione HTTP non crittografata, potrebbe essere un difetto con l'implementazione di ActiveSync su IOS 5.0.1. O in relazione a questo ticket di supporto MS che ha detto:

The new functionality sends HTTP requests even when the client is idle. The client sends a keepalive request (/owa/keepalive.owa), and then the client sends more information about the activity of the user by adding the following path of the published OWA URL: /owa/ev.owa?UA=0

Mi chiedo perché MS non abbia detto di inviare una richiesta HTTPS ??? Più test devono essere fatti. E questo è legato solo alle nuove funzionalità di OWA di Exchange 2010.

    
risposta data 08.02.2012 - 15:04
fonte
1

Solo perché il server richiede SSL non impedisce al client di tentare l'HTTP.

Questa è una perdita comune di credenziali in tutte le applicazioni Web. Il browser Web memorizza le credenziali sul server. L'utente digita l'URL con il link . Il browser invia quindi le credenziali memorizzate nella cache nella porta trasparente 80, a quel punto il server reindirizza alla porta 443.

Inoltre, gli strumenti automatici (come descritto in altre risposte su ActiveSync) sono interrotti e potrebbero provare HTTP quando è previsto l'HTTPS.

L'unico modo per impedire che ciò accada è bloccare la porta 80. L'unico modo per impedire al client di rivelare la password è impedire al client di stabilire una connessione.

Si noti che provare a migliorare l'autenticazione "Base" non sarà di grande aiuto. La maggior parte degli altri metodi di autenticazione che utilizzano challenge-response possono essere violati utilizzando password cracker (come "Cain e Abel").

    
risposta data 08.02.2012 - 18:18
fonte
1

È possibile / concepibile che OWA sia stato precedentemente configurato su HTTP (anche se brevemente) e successivamente passato a HTTPS? Se è stato utilizzato su HTTP in passato e un utente ad esso collegato, il browser potrebbe aver memorizzato le credenziali nella cache. Quindi, quando l'utente rientra in http: // ... url (o utilizza un segnalibro), il browser potrebbe inviare le credenziali memorizzate nella cache alla prima richiesta, che in seguito verrà reindirizzato a HTTPS.

Altrimenti, non credo che un browser decente (in questo caso le intestazioni delle richieste suggeriscono che si tratta di un iPod con iOS 5.0.1 che esegue Safari) invierà l'intestazione di autorizzazione HTTP su un nome host, porta o protocollo diverso da quello usato prima. Detto questo, potresti essere imbattuto in un bug (piuttosto serio). La cosa migliore è testarlo, idealmente con l'iPod utilizzato da questo utente e vedere a cosa è stata impostata la configurazione, se possibile. Se non riesci ad accedere allo stesso dispositivo o la configurazione è cambiata, dovresti forse provare a simulare questa condizione con un dispositivo simile e vedere se riesci a riprodurla.

    
risposta data 09.02.2012 - 18:16
fonte

Leggi altre domande sui tag