Send Dailydave mailing list submissions to
dailydave@lists.immunitysec.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.immunitysec.com/mailman/listinfo/dailydave
or, via email, send a message with subject or body 'help' to
dailydave-requ...@lists.immunitysec.com
You can reach the person managing the list at
dailydave-ow...@lists.immunitysec.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dailydave digest..."
Today's Topics:
1. Re: A small fun Python puzzle
(travis+ml-dailyd...@subspacefield.org)
2. Re: A small fun Python puzzle (Adrien Krunch Kunysz)
3. Great bugs! (dave)
4. Re: Great bugs! (Richard Miles)
5. Re: Great bugs! (Jonathan Cran)
6. XSS in viewstate (dave)
7. Re: XSS in viewstate (Chris Weber)
8. Re: XSS in viewstate (Raw Data)
9. Re: XSS in viewstate (David Byrne)
----------------------------------------------------------------------
Message: 1
Date: Tue, 9 Feb 2010 19:13:47 -0800
From: travis+ml-dailyd...@subspacefield.org
Subject: Re: [Dailydave] A small fun Python puzzle
To: ergosum <ergo...@neurosecurity.com>
Cc: dailydave@lists.immunitysec.com
Message-ID: <20100210031347.gc1...@subspacefield.org>
Content-Type: text/plain; charset="us-ascii"
On Tue, Apr 01, 2008 at 04:08:41PM +0200, ergosum wrote:
> Hi all,
> > >>> for l in [100000, 1000000, 5000000, 10000000]:
> > ... print '%10d %f' % (l, test(l))
> > ...
> > 100000 0.006711
> > 1000000 0.764886
> > 5000000 28.554786
> > 10000000 111.738498
> >
> > (wow - so not linear ...)
>
> So if this is true, slicing data[1024:] should be O(M) where M = 100000,
> 1000000, 5000000, 10000000 respectively, while slicing data[i:i+1024] should
> always be O(N) where N = 1024. There is a huge gain here that accounts for
> the more or less homogeneous times of the second algorithm. Nevertheless it
> puzzles me why the slicing operation isn't linear. Anyone with a better
> python internal knowledge can throw some light?
I think the slicing operation /is/ linear (O(M)), assuming malloc/free
as O(1) and no GC overhead.
However, in the first version of the program, it is called in a
loop, which is called ceil(M/1024) times. So as a result, the whole
loop runs in O(M^2) time.
The second, iterative version of the program has a loop called ceil(M/1024)
times, and it uses the array slice operator, which runs in O(1024) time.
So the run time is O(M), which is borne out by the timings.
I can't find the link now, but I saw a similar issue on ha.ckers.org
recently where he was doing something similar with strings in javascript.
There's nothing surprising when you realize that creating a new
string or buffer object takes time O(M) to copy the data, where M is
the size of the new object. You could possibly do zero-copy
operations, where one object points into the buffer used for another,
but then garbage collection and object deallocation becomes trickier.
--
In God We Trust; From Everyone Else, We Need Source Code.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/
If you are a spammer, please email j...@subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url :
http://lists.immunitysec.com/pipermail/dailydave/attachments/20100209/1a032938/attachment-0001.pgp
------------------------------
Message: 2
Date: Wed, 10 Feb 2010 21:45:19 +0000
From: Adrien Krunch Kunysz <adr...@kunysz.be>
Subject: Re: [Dailydave] A small fun Python puzzle
To: ergosum <ergo...@neurosecurity.com>,
dailydave@lists.immunitysec.com
Message-ID: <20100210214519.gc5...@baltika>
Content-Type: text/plain; charset="us-ascii"
On Tue, Feb 09, 2010 at 07:13:47PM -0800, travis+ml-dailyd...@subspacefield.org
wrote:
> On Tue, Apr 01, 2008 at 04:08:41PM +0200, ergosum wrote:
> > Hi all,
> > > >>> for l in [100000, 1000000, 5000000, 10000000]:
> > > ... print '%10d %f' % (l, test(l))
> > > ...
> > > 100000 0.006711
> > > 1000000 0.764886
> > > 5000000 28.554786
> > > 10000000 111.738498
> > >
> > > (wow - so not linear ...)
> >
> > So if this is true, slicing data[1024:] should be O(M) where M = 100000,
> > 1000000, 5000000, 10000000 respectively, while slicing data[i:i+1024]
> > should
> > always be O(N) where N = 1024. There is a huge gain here that accounts for
> > the more or less homogeneous times of the second algorithm. Nevertheless it
> > puzzles me why the slicing operation isn't linear. Anyone with a better
> > python internal knowledge can throw some light?
>
> I think the slicing operation /is/ linear (O(M)), assuming malloc/free
> as O(1) and no GC overhead.
>
> However, in the first version of the program, it is called in a
> loop, which is called ceil(M/1024) times. So as a result, the whole
> loop runs in O(M^2) time.
>
> The second, iterative version of the program has a loop called ceil(M/1024)
> times, and it uses the array slice operator, which runs in O(1024) time.
> So the run time is O(M), which is borne out by the timings.
>
> I can't find the link now, but I saw a similar issue on ha.ckers.org
> recently where he was doing something similar with strings in javascript.
>
> There's nothing surprising when you realize that creating a new
> string or buffer object takes time O(M) to copy the data, where M is
> the size of the new object. You could possibly do zero-copy
> operations, where one object points into the buffer used for another,
> but then garbage collection and object deallocation becomes trickier.
For those who are more familiar with C than with Python and algorithm-speak,
I think it means the program is doing this:
for (len = strlen(data); len > 0; len -= 1024) {
for (i = 1024; i < len; i++)
data[i-1024] = data[i];
}
Which was this in Python:
~ while data!="":
~ data=data[1024:]
Fixing the buffer underrun in the C version is left as an exercise for
the reader.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url :
http://lists.immunitysec.com/pipermail/dailydave/attachments/20100210/1bb3c41b/attachment-0001.pgp
------------------------------
Message: 3
Date: Wed, 17 Feb 2010 16:00:46 -0500
From: dave <d...@immunityinc.com>
Subject: [Dailydave] Great bugs!
To: dailyd...@lists.immunityinc.com
Message-ID: <4b7c58fe.8060...@immunityinc.com>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lately Immunity's been owning a lot of VPNs during consulting gigs.
People never seem to test them, after all, they're security products!
:>
Whoever found THIS bug on the other hand, gets remote access into a lot
of interesting boxes, I'm sure. Although they have to be configured for
NTLMv1 (if that ever happens?).
http://www.cisco.com/warp/public/707/cisco-sa-20100217-asa.shtml
NTLMv1 Authentication Bypass Vulnerability
Cisco ASA 5500 Series Adaptive Security Appliances contain a
vulnerability that could result in authentication bypass when the
affected appliance is configured to authenticate users against Microsoft
Windows servers using the NTLMv1 protocol.
Users can bypass authentication by providing an an invalid, crafted
username during an authentication request. Any services that use a AAA
server group that is configured to use the NTLMv1 authentication
protocol is affected. Affected services include:
* Telnet access to the security appliance
* SSH access to the security appliance
* HTTPS access to the security appliance (including Cisco ASDM access)
* Serial console access
* Privileged (enable) mode access
* Cut-through proxy for network access
* VPN access
This vulnerability is documented in Cisco bug ID CSCte21953 ( registered
customers only) and has been assigned Common Vulnerabilities and
Exposures (CVE) ID CVE-2010-0568.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkt8WP0ACgkQtehAhL0ghepTCACcDi4oLNdtN3AsNaW/f3mnPzpY
P08AniLdAVAAkhb6lKGSe1aE3bWwk0+x
=fDa4
-----END PGP SIGNATURE-----
------------------------------
Message: 4
Date: Wed, 17 Feb 2010 15:30:15 -0600
From: Richard Miles <richard.k.mi...@googlemail.com>
Subject: Re: [Dailydave] Great bugs!
To: dave <d...@immunityinc.com>
Cc: dailyd...@lists.immunityinc.com
Message-ID:
<194e74ff1002171330h8a2f9advca35ce5855670...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Do you have more details?
Also, can you share details of some of your cool VPN compromises
during your engagements?
On Wed, Feb 17, 2010 at 3:00 PM, dave <d...@immunityinc.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lately Immunity's been owning a lot of VPNs during consulting gigs.
> People never seem to test them, after all, they're security products!
> :>
>
> Whoever found THIS bug on the other hand, gets remote access into a lot
> of interesting boxes, I'm sure. Although they have to be configured for
> NTLMv1 (if that ever happens?).
>
> http://www.cisco.com/warp/public/707/cisco-sa-20100217-asa.shtml
>
>
> NTLMv1 Authentication Bypass Vulnerability
>
> Cisco ASA 5500 Series Adaptive Security Appliances contain a
> vulnerability that could result in authentication bypass when the
> affected appliance is configured to authenticate users against Microsoft
> Windows servers using the NTLMv1 protocol.
>
> Users can bypass authentication by providing an an invalid, crafted
> username during an authentication request. Any services that use a AAA
> server group that is configured to use the NTLMv1 authentication
> protocol is affected. Affected services include:
>
> ? ?* Telnet access to the security appliance
> ? ?* SSH access to the security appliance
> ? ?* HTTPS access to the security appliance (including Cisco ASDM access)
> ? ?* Serial console access
> ? ?* Privileged (enable) mode access
> ? ?* Cut-through proxy for network access
> ? ?* VPN access
>
> This vulnerability is documented in Cisco bug ID CSCte21953 ( registered
> customers only) and has been assigned Common Vulnerabilities and
> Exposures (CVE) ID CVE-2010-0568.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt8WP0ACgkQtehAhL0ghepTCACcDi4oLNdtN3AsNaW/f3mnPzpY
> P08AniLdAVAAkhb6lKGSe1aE3bWwk0+x
> =fDa4
> -----END PGP SIGNATURE-----
> _______________________________________________
> Dailydave mailing list
> Dailydave@lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>
------------------------------
Message: 5
Date: Wed, 17 Feb 2010 17:03:02 -0500
From: Jonathan Cran <jc...@0x0e.org>
Subject: Re: [Dailydave] Great bugs!
To: Richard Miles <richard.k.mi...@googlemail.com>
Cc: dailyd...@lists.immunityinc.com, dave <d...@immunityinc.com>
Message-ID:
<40a166ad1002171403j2837822ch6d70a0e292f67...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Feb 17, 2010 at 4:30 PM, Richard Miles
<richard.k.mi...@googlemail.com> wrote:
> Do you have more details?
>
> Also, can you share details of some of your cool VPN compromises
> during your engagements?
Mike Zusman (http://schmoil.blogspot.com/) of the Intrepidus Group has
done some awesome research here. This stuff definitely works.
http://www.blackhat.com/presentations/bh-usa-08/Zusman/BH_US_08_Zusman_SSL_VPN_Abuse.pdf
jcran
--
Jonathan Cran
jc...@0x0e.org
http://www.0x0e.org/
------------------------------
Message: 6
Date: Fri, 19 Feb 2010 09:45:53 -0500
From: dave <d...@immunityinc.com>
Subject: [Dailydave] XSS in viewstate
To: dailyd...@lists.immunityinc.com
Message-ID: <4b7ea421.6030...@immunityinc.com>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf
This, on first glance, looks real to me. Does anyone have any comments
on it? ViewState is pretty complex and fairly opaque. If I understand
properly, MS does not publish the full specs to it? Maybe the Mono team
found them somewhere?
- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkt+pCEACgkQtehAhL0ghepUJQCeMs9I2pnL3z4eYicYF44xaUgd
T4gAnjD/aFU9Z2tWRHge7i4Ch48BS3Ph
=w0qz
-----END PGP SIGNATURE-----
------------------------------
Message: 7
Date: Fri, 19 Feb 2010 09:26:34 -0800
From: "Chris Weber" <ch...@casabasecurity.com>
Subject: Re: [Dailydave] XSS in viewstate
To: "'dave'" <d...@immunityinc.com>, <dailyd...@lists.immunityinc.com>
Message-ID: <00b001cab188$b235cf60$16a16e...@com>
Content-Type: text/plain; charset="UTF-8"
One important thing to note is that VIEWSTATE MAC protection is enabled by
default. It's only when this protection is purposely disabled that tampering
and this XSS vector become possible. You can detect when this protection has
been disabled either through code review, or passively with dynamic testing
which is what we'll be doing with the Watcher tool.
-Chris
-----Original Message-----
From: dailydave-boun...@lists.immunitysec.com
[mailto:dailydave-boun...@lists.immunitysec.com] On Behalf Of dave
Sent: Friday, February 19, 2010 6:46 AM
To: dailyd...@lists.immunityinc.com
Subject: [Dailydave] XSS in viewstate
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf
This, on first glance, looks real to me. Does anyone have any comments
on it? ViewState is pretty complex and fairly opaque. If I understand
properly, MS does not publish the full specs to it? Maybe the Mono team
found them somewhere?
- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkt+pCEACgkQtehAhL0ghepUJQCeMs9I2pnL3z4eYicYF44xaUgd
T4gAnjD/aFU9Z2tWRHge7i4Ch48BS3Ph
=w0qz
-----END PGP SIGNATURE-----
_______________________________________________
Dailydave mailing list
Dailydave@lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
------------------------------
Message: 8
Date: Fri, 19 Feb 2010 18:45:53 +0000
From: Raw Data <rawda...@gmail.com>
Subject: Re: [Dailydave] XSS in viewstate
To: dailyd...@lists.immunityinc.com
Message-ID:
<4ec352d91002191045u69f23d36g87d35e8f8473e...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Dave,
This problem has been hinted by MS since the release of .Net2.0, even
my team was able to reproduce this a while ago, so I was a bit
surprise when this advisory was released, as I thought this was
already known.
>From my point of view the problem here is not the tampering of
non-encrypted/signed Viewstate. The problem lies with applications
that are load-balanced and using signed/encrypted Viewstate.
When Viewstate is used on a single machine, the encryption key/signing
MAC is managed internally and auto-generated. However, when it's being
used on a web farm environment this key has to be shared between all
servers, so it has to be set manually, and here lies the problem. Will
everybody instruct their operations teams to change this on, let's
say, a weekly basis?
Worse even, now that Viewstate is on the spotlight, it's fairly easy
to imagine that someone will write a tool to brute-force it or devise
some easier way to break it. Remember that the MachineKey which is
used to encrypt/sign the Viewstate has other functions besides this
one (Forms authentication tickets and role cookies).
Solutions?
Cheers,
RD
On Fri, Feb 19, 2010 at 2:45 PM, dave <d...@immunityinc.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf
>
> This, on first glance, looks real to me. Does anyone have any comments
> on it? ViewState is pretty complex and fairly opaque. If I understand
> properly, MS does not publish the full specs to it? Maybe the Mono team
> found them somewhere?
>
> - -dave
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt+pCEACgkQtehAhL0ghepUJQCeMs9I2pnL3z4eYicYF44xaUgd
> T4gAnjD/aFU9Z2tWRHge7i4Ch48BS3Ph
> =w0qz
> -----END PGP SIGNATURE-----
> _______________________________________________
> Dailydave mailing list
> Dailydave@lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>
------------------------------
Message: 9
Date: Fri, 19 Feb 2010 13:15:25 -0600
From: David Byrne <dby...@trustwave.com>
Subject: Re: [Dailydave] XSS in viewstate
To: dave <d...@immunityinc.com>, "dailyd...@lists.immunityinc.com"
<dailyd...@lists.immunityinc.com>
Message-ID:
<e64731f3abeb554e8591afd1dc20dee1128ff06...@skyvs1.trustwave.com>
Content-Type: text/plain; charset="us-ascii"
This is very real. The Hacking Lab document is actually an (unattributed) cut
and paste job from a larger advisory that we released earlier in the month. The
topic was discussed in more detail at a BlackHat DC presentation.
https://www.trustwave.com/spiderlabs/advisories/TWSL2010-001.txt
http://www.blackhat.com/html/bh-dc-10/bh-dc-10-archives.html#Byrne
Microsoft doesn't fully document the view state format, but it isn't too hard
to discover using tools like .Net Reflector (http://reflector.red-gate.com).
There are several tools that will decode the view state; my favorite is
ViewStateHacker (http://www.woany.co.uk/viewstatehacker/).
Our advisory is about view state vulnerabilities in three different web app
frameworks. Microsoft comes out pretty good because they secure the view state
by default, but it's not that rare to find ASP.Net web apps with disabled view
state security. The reason is usually lazy administration; load balanced
environments are simpler when the view state security is disabled (what isn't
easier without security). The only framework vulnerability that we could find
in .Net was XSS. Of course, custom applications can have any type of
vulnerability introduced.
Apache MyFaces and Sun Mojarra were more serious. View state security is
disabled by default and few sites use it. In addition to XSS, it's also
possible to upload JSP Expression Language statements to the server. This
allows an attacker to read any request, session, application, or server-scoped
variable defined by the developer. It isn't unusual for sensitive data to be
stored in server-side session variables, so it can be a useful attack.
Thanks,
David Byrne
Senior Security Consultant
Trustwave - SpiderLabs, Application Security
Email: dby...@trustwave.com
Phone (office & cell): 720-279-4123
-----Original Message-----
From: dailydave-boun...@lists.immunitysec.com
[mailto:dailydave-boun...@lists.immunitysec.com] On Behalf Of dave
Sent: Friday, February 19, 2010 7:46 AM
To: dailyd...@lists.immunityinc.com
Subject: [Dailydave] XSS in viewstate
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf
This, on first glance, looks real to me. Does anyone have any comments
on it? ViewState is pretty complex and fairly opaque. If I understand
properly, MS does not publish the full specs to it? Maybe the Mono team
found them somewhere?
- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkt+pCEACgkQtehAhL0ghepUJQCeMs9I2pnL3z4eYicYF44xaUgd
T4gAnjD/aFU9Z2tWRHge7i4Ch48BS3Ph
=w0qz
-----END PGP SIGNATURE-----
_______________________________________________
Dailydave mailing list
Dailydave@lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
------------------------------
_______________________________________________
Dailydave mailing list
Dailydave@lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
End of Dailydave Digest, Vol 55, Issue 4
****************************************
