Message-ID: <CA+CewVC0pLgcrfNT7aKR1j9dNaUVsVsXoZMCaBFwGf+uF9K4MQ@mail.gmail.com>
Date: Fri, 14 Mar 2014 05:46:18 +0000
From: "Nicholas Lemonias." <lem.nikolas@...glemail.com>
To: Michal Zalewski <lcamtuf@...edump.cx>,
 Julius Kivimäki <julius.kivimaki@...il.com>, 
 full-disclosure@...ts.grok.org.uk, Pedro Ribeiro <pedrib@...il.com>
Subject: Re: Google vulnerabilities with PoC

Zakewski,

Thank you for your e-mail. I welcome all opinions, that are backed up by
evidences.

I am not just a security researcher, I am also an academic in the field and
lecturer.

However, from an academic perspective, when it comes to certain
security designs the mere existence of unvalidated requests is symptomatic
of deeper code problems. Thus, in academia such definitions are vague,
unless they are either backed-up by original, incisive research, or by
existing subject matter literature which is widely accepted.

In terms of what constitutes a security vulnerability, it is a weakness in
a product or service that may allow an attacker to compromise the (C-I-A)
Confidentiality, Integrity and Availability of that same service, and I bet
you 've heard this many times before. Adequate security requirements entail
properties of 1) confidentiality, 2) integrity, 3) availability
 but also 4) authorization , 5) non-repudiation and 6) authentication.

Integrity: Integrity refers to the trustworthiness of a resource. An
attacker exploits a weakness in a service to modify it silently and without
authorization means is compromising the integrity of that service.

 Example: A weakness that allows an administrator to change the permission
sets on a file , that is not a security vulnerability because an
administrator already has this capability. However if a weakness allowed an
unprivileged user to do the same thing (say to write arbitrary files to a
remote service), that would constitute to a security vulnerability.

Availability*:* Availability refers to the ability to access a resource. An
attacker that exploits a weakness in a service, denying appropriate user
access to it, is thus compromising the availability of that particular
service. In our case a Denial of Service is feasible, because the uploaded
files are persistent and can  lead to resource exhaustion.

Example: A weakness that enables an attacker  to cause a server to fail
would constitute a vulnerability, since the attacker denies resources
pertinent to that service. Resource exhaustion is possible.

Confidentiality: Confidentiality refers to the disclosure of information,
to unauthorised parties. However this is by no means the only property
required for security. In this case just because we haven't accessed some
files, that does not mean that the service is secure.

Authorization: Refers to the process of determining which 'principals' have
access and to which 'objects'. Access control is a type of authorization,
hence its name. In case of the API upload functionality, a script is loaded
and somewhere a write() function is called. The access control was weak
since it was web-based. We could arbitrary write() any file of choice to
the system as a result, something that only an administrator with full
permission sets should be able to do.

admin.youtube.com is the admin login.


On Fri, Mar 14, 2014 at 4:19 AM, Michal Zalewski <lcamtuf@...edump.cx>wrote:

> Nicholas,
>
> I remember my early years in the infosec community - and sadly, so do
> some of the more seasoned readers of this list :-) Back then, I
> thought that the only thing that mattered is the ability to find bugs.
> But after some 18 years in the industry, I now know that there's an
> even more important and elusive skill.
>
> That skill boils down to having a robust mental model of what
> constitutes a security flaw - and being able to explain your thinking
> to others in a precise and internally consistent manner that convinces
> others to act. We need this because the security of a system can't be
> usefully described using abstract terms: even the academic definitions
> ultimately boil down to saying "the system is secure if it doesn't do
> the things we *really* don't want it to do".
>
> In this spirit, the term "vulnerability" is generally reserved for
> behaviors that meet all of the following criteria:
>
> 1) The behavior must have negative consequences for at least one of
> the legitimate stakeholders (users, service owners, etc),
>
> 2) The consequences must be widely seen as unexpected and unacceptable,
>
> 3) There must be a realistic chance of such a negative outcome,
>
> 4) The behavior must introduce substantial new risks that go beyond
> the previously accepted trade-offs.
>
> If we don't have that, we usually don't have a case, no matter how
> clever the bug is.
>
> Cheers (and happy hunting!),
> /mz
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists