Hi Chris,
cevans@xxxxxxxxxx wrote:
> Hi Vicente,
>
> As was explained by my colleague Neel Mehta in his reply, this is not
> a vulnerability.
I must express my disagreement. I consider that if someone can automate
the process of password cracking, exist a security problem. I have
programmed a Python script that implements the process that I explain in
the proof of concept paragraph, and it has allowed me to run thousands
of automated requests and obtain the password of one of my test accounts.
> Gmail has all sorts of additional limits on password brute forcing.
> The confusion here is the difference between "login incorrect" (due to
> bad password) and "login incorrect" (due to excessive login attempts).
> This protection kicks in after a small number of failed attempts,
> after which even correct credentials will not be accepted. You can't
> tell the difference in the UI you are using, so it's understandable to
> have missed these extra limits.
>
A malicious user can abuse the feature "Check for mail using POP3" for
realize the automatic process of password cracking.
As you comment, using this feature exist a lock (for 2 hours) for
authentication attempts, and beyond this limit (100 requests) the
message returned by the application does not allow to known if the
analyzed password is correct or not. However, every 2 hours an attacker
could make 100 authentication attempts.
To overcome this limit (100 authentication attempts), it is sufficient
that the attacker has other Gmail accounts. Each account allows the
malicious user to make 100 new auhtentication attempts within 2 hours of
the blockade. If the attacker wants to make an authentication attempt by
second and to avoid the blockage then will need to make 3600 requests
per hour. This requires that the malicious user dispose of 3600/100 = 36
Gmail accounts. As there is a blockage of 2 hours, with 72 Gmail
accounts the attacker can reuse the initial account (eg
"account01@xxxxxxxxx") after finishing the 100 authentication attempts
with the last Gmail account (eg "account72@xxxxxxxxx).
I hope that I have clarified the matter.
Best regards,
--
_________________________________
Vicente Aguilera Díaz
Director Auditoría
CISA, CISSP, ITIL
CEH Instructor, ECSP Instructor, CSSLP, OPSA, OPST
OWASP Spain Chapter Leader
vaguilera@xxxxxxxxxxxxxxxx
Internet Security Auditors
www.isecauditors.com
c. Santander, 101. Edif. A. 2º
E-08030 Barcelona (Spain)
Tel: +34 93 305 13 18
Fax: +34 93 278 22 48
Pº. de la Castellana, 164-166. Entlo. 1ª
E-28046 Madrid (Spain)
Tel: +34 91 788 57 78
Fax: +34 91 788 57 01
____________________________________
Este mensaje y los documentos que, en su caso lleve anexos, pueden
contener información CONFIDENCIAL. Por ello, se informa al destinatario
que la información contenida en el mismo es reservada y su uso no
autorizado, publicación o difusión, entera o parcialmente, tanto en
formato o medio físico como electrónico, sin el previo consentimiento de
Internet Security Auditors, está prohibida legalmente.
Si ha recibido este correo por error, le rogamos que nos lo comunique
por la misma vía o por teléfono (93 305 13 18), se abstenga de realizar
copias del mensaje o remitirlo o entregarlo a otra persona y proceda a
borrarlo de inmediato.
En cumplimiento de la Ley Orgánica 15/1999 de 13 de diciembre de
protección de datos de carácter personal, Internet Security Auditors
S.L., le informa de que sus datos personales se han incluido en ficheros
informatizados titularidad de Internet Security Auditors S.L., que será
el único destinatario de dichos datos, y cuya finalidad exclusiva es la
gestión de clientes y acciones de comunicación comercial, y de que tiene
la posibilidad de ejercer los derechos de acceso, rectificación,
cancelación y oposición previstos en la ley mediante carta dirigida a
Internet Security Auditors, c. Santander, 101. Edif. A. 2º 1ª, 08030
Barcelona, o vía e-mail a la siguiente dirección de correo:
legal@xxxxxxxxxxxxxxxx
>
> On Fri, Jul 17, 2009 at 2:48 PM, ISecAuditors Security
> Advisories<advisories@xxxxxxxxxxxxxxxx> wrote:
>> =============================================
>> INTERNET SECURITY AUDITORS ALERT 2009-NNN
>> - Original release date: July 7th, 2009
>> - Last revised: July 17th, 2009
>> - Discovered by: Vicente Aguilera Diaz
>> - Severity: 4.5/10 (CVSS Base Score)
>> =============================================
>>
>> I. VULNERABILITY
>> -------------------------
>> Gmail vulnerable to automated password cracking.
>>
>> II. BACKGROUND
>> -------------------------
>> Gmail is Google's free webmail service. It comes with built-in Google
>> search technology and over 7,300 megabytes of storage (and growing
>> every day). You can keep all your important messages, files and
>> pictures forever, use search to quickly and easily find anything
>> you're looking for, and make sense of it all with a new way of viewing
>> messages as part of conversations.
>>
>> III. DESCRIPTION
>> -------------------------
>> An existing abuse of functionality in the "Check for mail using POP3"
>> capability permits automated attacks to the password data of the
>> accounts of the Gmail users evading the security measures adopted by
>> Google.
>>
>> Gmail implements a great number of security controls and, most of them
>> are not revealed until an attack is conducted or a malicious use of
>> the account is done. For example:
>> - Use of catpcha for avoiding automated processes (e.g., in the users
>> authentication or in the new users sign up).
>> - Temporary IP locking in case of detecting unusual application
>> activities (e.g., multiple new account creation requests)
>> - Temporary account locking in case of detecting unusual use of the
>> user account (e.g., when doing multiple consecutive request to the
>> same resource).
>> - Detection of concurrent access to the account from different
>> geolocated IP addresses added to the number of these accesses.
>> - Etc.
>>
>> Anyway, is it possible to abuse the "Check for mail using POP3"
>> capability to do attacks to the passwords of the users in an automated
>> way, evading all referred security restrictions and controls and doing
>> a transparent and not noticeable attack to the user that its account
>> is being password cracked as:
>> - There's no need for required action from the victim.
>> - There's no modification in the password of the victim.
>> - There's no locking in the victim account.
>> - There's no security notification to the victim.
>>
>> The vulnerability is aggravated due Gmail allows weak passwords to be
>> used by the users. So, Gmail accepts password using only one character
>> (e.g. "aaaaaaaa") or dictionary words (e.g. "pentagon" or "computer").
>>
>> The abuse of this functionality permits an attacker to do thousands of
>> authentication requests during a day over one user account, so if the
>> user is using a weak password is a matter of time to guess to have
>> access to the mail account.
>>
>> IV. PROOF OF CONCEPT
>> -------------------------
>> As only requirement, the attacker needs a real Gmail account, but
>> that's not a real limitation as service is for free.
>>
>> After being authenticated, the attacker access to the option "Accounts
>> and import". From this tab access to "Add POP3 mail account". To add a
>> new account the attacker news to fill:
>> -User name: will be the victim email address, including "@gmail.com"
>> (e.g. victim@xxxxxxxxx).
>> -Password: will be the password related to the previously informed user.
>> -POP3 server and port: could be simply "pop.gmail.com" and the 995 port.
>>
>> When asking for the new email account to be added some different
>> scenarios can happen:
>> 1. The application returns the message "The server has denied the
>> POP3 access to this username and password". This possibility happens
>> when the username do not exists or the password is incorrect.
>>
>> 2. The application returns the message "Now you can recover the
>> messages of this account". This other possibility happens when the
>> authentication has succeeded. So, the attacker informed correctly the
>> password to this user.
>>
>> 3. The application returns the message "You have reached the maximum
>> number of accounts allowed". This situation appears after adding more
>> than 5 email accounts or after doing 100 requests (successfully or
>> not) for adding a new account. Is important to notice that, after the
>> 100 attempts, the user must wait for 2 hours.
>>
>> Using this, an attacker is able to do 100 attempts of authentication
>> each 2 hours (so 1.200 attempts each day).
>>
>> Is very important to retain that those requests do not require any
>> kind of catpcha and can be done automatically knowing only the key
>> parameters of the request:
>>
>> -ik: alphanumeric id associated to the user and transmitted through
>> GET request.
>> -GMAIL_AT: is an alphanumeric value associated to the user and
>> transmitted in the cookie. It is only known after authentication
>> and starts with characters "xn3j3".
>> -GX: alphanumeric value associated to the user and transmitted in
>> the cookie. It is only known after authentication.
>> -ui: numeric value. Can be fixed to value "2" (default value) and is
>> transmitted via GET.
>> -view: string value. Can be fixed to string "ma" (default value) and
>> is transmitted via GET.
>> -map: numeric value. Can be fixed to value "2" (default value) and
>> is transmitted via POST.
>> -ma_email: email address of the account to be added. Would match to
>> the victim email address and is transmitted via POST.
>> -mapc: boolean value. Can be fixed to value "true" (default value)
>> and is transmitted via POST.
>> -mapp: numeric value. Can be fixed to value "1" (default value) and
>> is transmitted via POST.
>> -mabb: this parameter can be nul (default value) and is transmitted
>> via POST.
>> -at: is the alphanumeric value associated to the user that must
>> match with be value of the variable GMAIL_AT previously explained.
>> This value is transmitted via POST.
>> -ma_user: email address of the account from which the new email
>> address wanted be added. Is the attacker email address and is
>> transmitted via POST.
>> -ma_pwd: password to be used for the victim account. Is transmitted
>> via POST.
>> -ma_host: IP address of the POP3 server. Can be fixed to value
>> "pop.gmail.com" and is transmitted via POST.
>> -ma_host_sel: IP address of the POP3 server. Can be fixed to value
>> "pop.gmail.com" and is transmitted via POST.
>> -ma_port: is the value of the port of the POP3 server. Can be fixed
>> to value "995" (defalt value) and is transmitted via POST.
>> -ma_ssl: can be fixed to string "on" (default value) and is
>> transmitted via POST.
>> -ma_lbl: is the name of the label that will be used for labelling
>> incoming emails. Can be fixed to the victim email address (default
>> value) and is transmitted via POST.
>>
>> Summarizing, the POST request for the authentication attack would be
>> like this:
>>
>> POST http://mail.google.com/mail/?ui=2&ik=<ik_value>&view=ma HTTP/1.1
>> Cookie: GX=<GX_value>; GMAIL_AT=<GMAIL_AT_value>
>> map=2&ma_email=<victim_email>&mapc=true&mapp=1&mabb=&at=<at_value>&ma_user=<attacker_email>&ma_pwd=<victim_pwd>&ma_host=pop.gmail.com&ma_host_sel=pop.gmail.com&ma_port=995&ma_ssl=on&ma_lbl=<email_victim>
>>
>> To bypass the limitation of 1.200 requests per day it is only
>> necessary to have different Gmail accounts. Each new account means 100
>> new possible requests. If the attacker wants to do a request each
>> second, means 7.200 attempts each two hours, the only need is to have
>> 72 accounts. This would mean 86.400 request/day. More requests only
>> need more accounts.
>>
>> As the Gmail account creation is a manual process as it needs to pass
>> the captcha. Another limitation is that Google only permits the
>> creation of 10 new accounts creation per day from the same IP address,
>> but using proxies or Tor network would bypass this limitation. Anyway,
>> although the creation of N accounts, those could be used anytime for
>> password cracking accounts.
>>
>> V. BUSINESS IMPACT
>> -------------------------
>> Capability of unlimited password cracking Gmail user accounts.
>> Selective DoS on users of the Gmail service (changing user password).
>>
>> VI. SYSTEMS AFFECTED
>> -------------------------
>> Gmail service.
>>
>> VII. SOLUTION
>> -------------------------
>> Implement better and homogeneous anti password cracking controls.
>> No solution addopted by vendor.
>> So, use strong passwords.
>>
>> VIII. REFERENCES
>> -------------------------
>> http://mail.google.com
>> http://www.isecauditors.com
>>
>> IX. CREDITS
>> -------------------------
>> This vulnerability has been discovered
>> by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
>>
>> X. REVISION HISTORY
>> -------------------------
>> July 07, 2009: Initial release.
>> July 13, 2009: Minor revision.
>> July 17, 2009: Last update.
>>
>> XI. DISCLOSURE TIMELINE
>> -------------------------
>> July 05, 2009: Discovered by Internet Security Auditors.
>> July 13, 2009: Gmail security team contacted.
>> July 15, 2009: Request for confirmation of reception and analysis.
>> July 17, 2009: Answer from Google telling 100 attemp control limit is
>> enough robust, although the advisory poc shows how to
>> evade this weak security control.
>> Publication of the advisory in the lists.
>>
>> XII. LEGAL NOTICES
>> -------------------------
>> The information contained within this advisory is supplied "as-is"
>> with no warranties or guarantees of fitness of use or otherwise.
>> Internet Security Auditors accepts no responsibility for any damage
>> caused by the use or misuse of this information.
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
