full-disclosure-uk August 2008 archive
Main Archive Page > Month Archives  > full-disclosure-uk archives
full-disclosure-uk: Re: [Full-disclosure] Petko D. Petkov hacked

Re: [Full-disclosure] Petko D. Petkov hacked?

From: Squadron of Justice <internetsuperheros_at_nospam>
Date: Tue Aug 12 2008 - 20:08:18 GMT
To: dgoodin@theregister.com, full-disclosure@lists.grok.org.uk


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 12 Aug 2008 16:31:41 +0200 Dan Goodin <dgoodin@sitpub.com> wrote:
>Hey, thanks for the reply. How do I know you really cracked his
>email
>account? Can you forward me any of the emails I've sent PDP over
>the
>past 18 months? Also, assuming you really did obtain his email,
>how many
>messages were you able to get?

Further requests of proof of our otherworldly abilities, awesomeness and superpowers will be taken as an offense to our creed and mission on Earth. Other, non super powered, less awesome and uglier individuals might compensate their lack of knowledge, manliness and beauty by means of deception. But superheroes aren't deceptive. Our strength is truth. Our weakness is none. Our weapons are digital and volatile. Our enemies are all financially, spiritually and socially bankrupt individuals of these digital realms. We do not siege, attack
nor leave the innocent forsaken in despair. Our duty is to lay great justice with furious vengeance and rebukes upon wickedness and inequity.

Regarding the amount of messages the Squadron of Justice undercover operatives were able to obtain: all of them. No exceptions. Not a single byte was left unsupervised in Petko D. Petkov's wicked email. Their effectiveness and reliability is only paralleled by their unstable minds and a total lack of control of their superpowers, to the detriment of our cause and creed. We refuse to admit it, but the Squadron of Justice might be the last stronghold of great Justice in the universe, and the risk of world wide mayhem and chaos is worth taking when equity, justice, righteousness, awesomeness and manliness
are at stake. And their struggle against evil and wickedness in high places is, indeed, eternal.

Here shall be proof of justice (accept our apologies for showing your private email address and phone number, also, superheroes would recommend you to stop using Pine for reading email, or great justice could ensue):

Delivered-To: pdp.gnucitizen@gmail.com
Received: by 10.67.118.17 with SMTP id v17cs428534ugm;

        Mon, 12 Feb 2007 11:59:07 -0800 (PST) Received: by 10.82.175.2 with SMTP id x2mr10689209bue.1171310346329;

        Mon, 12 Feb 2007 11:59:06 -0800 (PST) Return-Path: <dgoodin@theregister.com>
Received: from md1.psixpress.com (md1.psixpress.com [154.32.105.205])

        by mx.google.com with ESMTP id
o53si31209074nfa.2007.02.12.11.59.06;

        Mon, 12 Feb 2007 11:59:06 -0800 (PST) Received-SPF: neutral (google.com: 154.32.105.205 is neither permitted
nor denied by best guess record for domain of dgoodin@theregister.com)
Received: from [127.0.0.1] ([12.25.211.1]) by md1.psixpress.com (MOS 3.5.6-GR) with ESMTP id EPW28928 (AUTH dgoodin); Mon, 12 Feb 2007 19:58:56 GMT
Message-ID: <45D0C6FF.3090906@theregister.com> Date: Mon, 12 Feb 2007 11:58:55 -0800
From: Dan Goodin <dgoodin@theregister.com> User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0
To: "pdp (architect)" <pdp.gnucitizen@googlemail.com> Subject: Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly
 other browsers)
References: <Pine.LNX.4.58.0702112047050.30989@dione> <6905b1570702111215ie807c52t4b60d74c9c090e0a@mail.gmail.com> <Pine.LNX.4.58.0702112156110.30989@dione> <6905b1570702111304g5f8447ftf27affc6e82a5e39@mail.gmail.com> <6905b1570702111310k4e80aa21v8ca8d635d1668d06@mail.gmail.com> <6905b1570702111319x5eaca5cakc8b0a88a67ab254b@mail.gmail.com> <Pine.LNX.4.58.0702112221270.30989@dione> <6905b1570702111347v283dfbcbse8cb162c9f9bedfd@mail.gmail.com> <45D0B386.60003@theregister.com> <6905b1570702121054j5d8c6172o777e9abdfe0cc764@mail.gmail.com> <6905b1570702121100t66a397edw885ca79a41881e6a@mail.gmail.com> In-Reply-To:
<6905b1570702121100t66a397edw885ca79a41881e6a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit

I just installed Gtalk and have invited you to be on my contact list. My
gmail address is blindedbyspam@gmail.com. Hope to hear from you.

pdp (architect) wrote:
> btw, let me know if that suits you
>
> On 2/12/07, pdp (architect) <pdp.gnucitizen@googlemail.com> wrote:
>> Hi Dan,
>>
>> I am always available on gtalk...
>>
>> On 2/12/07, Dan Goodin <dgoodin@theregister.com> wrote:
>> >
>> > Hi,
>> >
>> > Dan Goodin, a reporter with The Register, here, wondering if
you
>> have time
>> > to explain this Firefox flaw in a little more detail. Are you
>> available by
>> > either phone or IM?
>> >
>> > Kind regards,
>> >
>> > Dan Goodin
>> > AIM: dangoodin001
>> > 415-874-3406
>> >
>> >
>> > pdp (architect) wrote:
>> > Well, :) I cannot see how you can force someone to type / at
least
>> > twice. Even if the targeted user writes a blog entry it is very
>> > unlikely that he/she will use / . I guess this vector works
well on
>> > wikies and other systems that allow you to specify the text
format
>> > through meta-characters.
>> >
>> > The cool think about stealing the address bar focus is that a
confused
>> > user will try to repeat typing the url again and that may give
you
>> > enough slashes and other characters to steal /etc/shadow or
>> > /etc/passwd for example, which means that this attack vector
can work
>> > virtually every where. For example:
>> >
>> > Joe visits eveil.com. He is not interested in the site but
evil.com is
>> > interested in his files. Joe types http://[what ever]. evil.com
>> > hijacks the address bar focus. This is how they get the first
/. Joe
>> > will probably repeat to type stuff in the address bar again.
The rest
>> > of the characters are not obtained.
>> >
>> > Now of course Joe will realise that he is not typing in the
address
>> > bar but he will probably think that either the browser is
screwed up
>> > or that he forgot to select the address bar first (it happens
all the
>> > time).
>> >
>> > So, this is why I think that combination of both issues can
create one
>> > hell of a good attack.
>> >
>> > Here is another idea.
>> >
>> > Joe visits Betty's MySpace private page. The page contains
XSS. On the
>> > page there is an input box and a captcha. The user is asked to
enter
>> > the text in the captcha in order to access the page. The
captcha is:
>> >
>> > pde/t/aswsc
>> >
>> > Joe enters the text but the he receives a complain that his
input is
>> > incorrect. The attacker repeats the process until all required
>> > characters are entered into the FILE INPUT box.
>> >
>> > simple.
>> >
>> > On 2/11/07, Michal Zalewski <lcamtuf@dione.ids.pl> wrote:
>> >
>> >
>> > On Sun, 11 Feb 2007, pdp (architect) wrote:
>> >
>> >
>> >
>> > here is an idea... we can combine both techniques into a
single
>> > attack... the hardest part of your hack is to force the user
to type
>> > :// plus several other /
>> >
>> > Actually, MSIE doesn't require drive specification in the
>> filename, and
>> > will probably accept relative paths as well (so you might not
need \
>> > either when picking files from the desktop or 'my documents'
or
>> whatnot).
>> >
>> > Firefox won't settle for a path without drive specification
(but it
>> will
>> > accept SMB requests ;-). On *nix systems, of course, aiming
>> /etc/passwd is
>> > easier than C:\whatever.
>> >
>> > The problem with intercepting address bar input is that you
can't
>> echo the
>> > entered text back there without unloading the current document
and its
>> > scripts; in my examples, I tried to make sure that it's hard
for
>> the user
>> > to notice that his input is not going where it should (in MSIE
>> example,
>> > this includes simulation of a blinking cursor).
>> >
>> > /mz
>> >
>> >
>> >
>> >
>> >
>>
>>
>> --
>> pdp (architect) | petko d. petkov
>> http://www.gnucitizen.org
>>
>
>

Delivered-To: pdp.gnucitizen@gmail.com
Received: by 10.67.118.17 with SMTP id v17cs422053ugm;

        Mon, 12 Feb 2007 10:35:53 -0800 (PST) Received: by 10.49.13.14 with SMTP id q14mr4857477nfi.1171305353434;

        Mon, 12 Feb 2007 10:35:53 -0800 (PST) Return-Path: <dgoodin@theregister.com>
Received: from md1.psixpress.com (md1.psixpress.com [154.32.105.205])

        by mx.google.com with ESMTP id
p72si24685130nfc.2007.02.12.10.35.53;

        Mon, 12 Feb 2007 10:35:53 -0800 (PST) Received-SPF: neutral (google.com: 154.32.105.205 is neither permitted nor denied by best guess record for domain of dgoodin@theregister.com)
Received: from [127.0.0.1] ([12.25.211.1]) by md1.psixpress.com (MOS 3.5.6-GR) with ESMTP id EPW20850 (AUTH dgoodin); Mon, 12 Feb 2007 18:35:51 GMT
Message-ID: <45D0B386.60003@theregister.com> Date: Mon, 12 Feb 2007 10:35:50 -0800
From: Dan Goodin <dgoodin@theregister.com> User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0
To: "pdp (architect)" <pdp.gnucitizen@googlemail.com> Subject: Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly
 other browsers)
References: <Pine.LNX.4.58.0702112047050.30989@dione> <6905b1570702111215ie807c52t4b60d74c9c090e0a@mail.gmail.com> <Pine.LNX.4.58.0702112156110.30989@dione> <6905b1570702111304g5f8447ftf27affc6e82a5e39@mail.gmail.com> <6905b1570702111310k4e80aa21v8ca8d635d1668d06@mail.gmail.com> <6905b1570702111319x5eaca5cakc8b0a88a67ab254b@mail.gmail.com> <Pine.LNX.4.58.0702112221270.30989@dione> <6905b1570702111347v283dfbcbse8cb162c9f9bedfd@mail.gmail.com> In-Reply-To:
<6905b1570702111347v283dfbcbse8cb162c9f9bedfd@mail.gmail.com> Content-Type: multipart/alternative;
 boundary="------------090302010100080406040701"

This is a multi-part message in MIME format. - --------------090302010100080406040701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit

Hi,

Dan Goodin, a reporter with The Register, here, wondering if you have
time to explain this Firefox flaw in a little more detail. Are you available by either phone or IM?

Kind regards,

Dan Goodin
AIM: dangoodin001
415-874-3406

pdp (architect) wrote:
> Well, :) I cannot see how you can force someone to type / at least
> twice. Even if the targeted user writes a blog entry it is very
> unlikely that he/she will use / . I guess this vector works well
on
> wikies and other systems that allow you to specify the text format
> through meta-characters.
>
> The cool think about stealing the address bar focus is that a
confused
> user will try to repeat typing the url again and that may give you
> enough slashes and other characters to steal /etc/shadow or
> /etc/passwd for example, which means that this attack vector can
work
> virtually every where. For example:
>
> Joe visits eveil.com. He is not interested in the site but
evil.com is
> interested in his files. Joe types http://[what ever]. evil.com
> hijacks the address bar focus. This is how they get the first /.
Joe
> will probably repeat to type stuff in the address bar again. The
rest
> of the characters are not obtained.
>
> Now of course Joe will realise that he is not typing in the
address
> bar but he will probably think that either the browser is screwed
up
> or that he forgot to select the address bar first (it happens all
the
> time).
>
> So, this is why I think that combination of both issues can
create one
> hell of a good attack.
>
> Here is another idea.
>
> Joe visits Betty's MySpace private page. The page contains XSS.
On the
> page there is an input box and a captcha. The user is asked to
enter
> the text in the captcha in order to access the page. The captcha
is:
>
> pde/t/aswsc
>
> Joe enters the text but the he receives a complain that his input
is
> incorrect. The attacker repeats the process until all required
> characters are entered into the FILE INPUT box.
>
> simple.
>
> On 2/11/07, Michal Zalewski <lcamtuf@dione.ids.pl> wrote:
>
>> On Sun, 11 Feb 2007, pdp (architect) wrote:
>>
>>
>>> here is an idea... we can combine both techniques into a single
>>> attack... the hardest part of your hack is to force the user to
type
>>> :// plus several other /
>>>
>> Actually, MSIE doesn't require drive specification in the
filename, and
>> will probably accept relative paths as well (so you might not
need \
>> either when picking files from the desktop or 'my documents' or
whatnot).
>>
>> Firefox won't settle for a path without drive specification (but
it will
>> accept SMB requests ;-). On *nix systems, of course, aiming
/etc/passwd is
>> easier than C:\whatever.
>>
>> The problem with intercepting address bar input is that you
can't echo the
>> entered text back there without unloading the current document
and its
>> scripts; in my examples, I tried to make sure that it's hard for
the user
>> to notice that his input is not going where it should (in MSIE
example,
>> this includes simulation of a blinking cursor).
>>
>> /mz
>>
>>
>
>
>

  • --------------090302010100080406040701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content- Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
Dan Goodin, a reporter with The Register, here, wondering if you have
time to explain this Firefox flaw in a little more detail. Are you available by either phone or IM?<br>
<br>
Kind regards,<br>
<br>
Dan Goodin<br>
AIM: dangoodin001<br>
415-874-3406<br>
<br>
pdp (architect) wrote:
<blockquote
 cite="mid6905b1570702111347v283dfbcbse8cb162c9f9bedfd@mail.gmail.co m"
 type="cite">
  <pre wrap="">Well, :) I cannot see how you can force someone to type / at least
twice. Even if the targeted user writes a blog entry it is very unlikely that he/she will use / . I guess this vector works well on wikies and other systems that allow you to specify the text format through meta-characters.

The cool think about stealing the address bar focus is that a confused
user will try to repeat typing the url again and that may give you enough slashes and other characters to steal /etc/shadow or /etc/passwd for example, which means that this attack vector can work
virtually every where. For example:

Joe visits eveil.com. He is not interested in the site but evil.com is
interested in his files. Joe types <a class="moz-txt-link-freetext" href="http://[what">http://[what</a> ever]. evil.com hijacks the address bar focus. This is how they get the first /. Joe will probably repeat to type stuff in the address bar again. The rest
of the characters are not obtained.

Now of course Joe will realise that he is not typing in the address bar but he will probably think that either the browser is screwed up or that he forgot to select the address bar first (it happens all the
time).

So, this is why I think that combination of both issues can create one
hell of a good attack.

Here is another idea.

Joe visits Betty's MySpace private page. The page contains XSS. On the
page there is an input box and a captcha. The user is asked to enter the text in the captcha in order to access the page. The captcha is:

pde/t/aswsc

Joe enters the text but the he receives a complain that his input is incorrect. The attacker repeats the process until all required characters are entered into the FILE INPUT box.

simple.

On 2/11/07, Michal Zalewski <a class="moz-txt-link-rfc2396E" href="mailto:lcamtuf@dione.ids.pl">&lt;lcamtuf@dione.ids.pl&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">On Sun, 11 Feb 2007, pdp (architect) wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">here is an idea... we can combine both techniques into a single
attack... the hardest part of your hack is to force the user to type :// plus several other /

      </pre>
    </blockquote>
    <pre wrap="">Actually, MSIE doesn't require drive specification in the filename, and
will probably accept relative paths as well (so you might not need \ either when picking files from the desktop or 'my documents' or whatnot).

Firefox won't settle for a path without drive specification (but it will
accept SMB requests ;-). On *nix systems, of course, aiming /etc/passwd is
easier than C:\whatever.

The problem with intercepting address bar input is that you can't echo the
entered text back there without unloading the current document and its
scripts; in my examples, I tried to make sure that it's hard for the user
to notice that his input is not going where it should (in MSIE example,
this includes simulation of a blinking cursor).

/mz

    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre> </blockquote> </body> </html>

  • --------------090302010100080406040701--

Love,
the Great Council of Internet Superheros. "To protect exposure and serve ruin."
"Justice prevails. No exceptions."
-----BEGIN PGP SIGNATURE-----
Charset: UTF8
Version: Hush 3.0
Note: This signature can be verified at https://www.hushtools.com/verify

wpwEAQMCAAYFAkih7bMACgkQ5g5u/REitpafcAP+NlAl+cLaEsCgGVMH3VjI6np/MzSp JHos6n7/GOP4h/z/siurOKbuRBcwMu8UcjwXSTYUAtTJiushlxsjcdNDa5wcD7AO0juL OIhcpOg1prLwjiwGOKoQGmujY/5Nn8zarbTE4JpkfN71lzvmQSqvhrVzxcKxT6/bewzd KusJobw=
=uS5C
-----END PGP SIGNATURE----- -- Explore all of Europe's beauty! Click now for great vacation packages! http://tagline.hushmail.com/fc/Ioyw6h4ePhlSVFZNlrmFYh4y7wPwVXxy0o9gewuEuaGzQasqnF234s/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/