[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADYtyv+Lfhuvowh2Hpc4AOe5AR+SLV7042RZi_AZnUdq3diScw@mail.gmail.com>
Date: Fri, 13 Jul 2012 12:57:27 -0400
From: Григорий Братислава <musntlive@...il.com>
To: Tim <tim-security@...tinelchicken.org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Predefined Post Authentication Session ID
Vulnerability
On 7/13/2012 12:07 PM, Tim wrote:
> Suppose an application runs solely over HTTPS and assigns cookies
> with the secure flag. However, user sessions are assigned before
> login and they don't refresh their session cookies upon user login.
> In this case, users are still vulnerable to MitM:
This nonsense you waste your time is write is not a cause for concern.
Simply because of is use of the word "suppose." Suppose is aliens
visited us. Suppose is Elvis was alive. Suppose is the tooth fairy
visited you. Too many is variables to deal with.
> 1. An attacker gains access to view and modify unencrypted traffic
> between a user and the application.
In is most cases of malware and trojans a) bad-executables is tend to
install keyloggers anyway so is credentials are stolen b) MITM is too
complex and is time consumer of attack for financialisly related
organized crime groups. You think they is patient?. Why bother MITM
when keystroke loggers work fine. c) MITM is pointless when is
screenshots accompany keystroke logging d) Storing information is to
decrypt later takes up more space than necessary. More is space is
raise likelihood of detection.
MusntLiv is deleted 2,3,4 nonsense you is write: TL;DR;TMN (Too Much Nonsense)
> 5. Upon attempting to access the HTTP version of the vulnerable
> application (which of course doesn't exist), the attacker again
> intercepts this and replaces the HTTP response. In this response, a
> Set-Cookie header is included which provides the victim's browser with
> the application session that the attacker retrieved in step 2.
Malware organizations is re-use tried, and true methods that work
over, and is over. Your's whole message to this list is based on
theory.
Deleting 7, 8 TL;DR;TMN
> This is complicated, but it's not that much more complicated than what
> existing MitM tools, such as sslstrip, already do.
You is have been reading too many documents on InfoSecInstitute. I
suggest you is go analyze the top 20 crimepacks and you is will see
that is easier for criminals to get data without is using MITM
attacks.
MITM is now become poster boy hacker talk meant to prop FUD. "OMG you
could be the potential victim of a possible MITM attack. This is why
http://writingdead.com/wp-content/uploads/2011/03/chaos-math-pic.gif"
> Note that another variant of this attack is possible if the victim's
> browser silently accepts third-party cookies (which most do by
> default) and is able to convince a user to visit any malicious site.
> In this case, no MitM is necessary.
Note for is yourself - 'anything is possible, this is life'
> Using HTTP cookies for session authentication is, and always has been,
> a bad idea. They are simply not designed for this application. We
> need something better.
Why worry is about cookies? MusntLive solve this for you right now:
http://tinyurl.com/MITM-cookie-solution
_______________________________________________
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