lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAH8yC8=skR_wTonZZRBvhBSpOa4VtmSE00V68B5eQ_a+0GYdRQ@mail.gmail.com>
Date: Thu, 10 Nov 2011 12:17:07 -0500
From: Jeffrey Walton <noloader@...il.com>
To: Sam Johnston <samj@...j.net>
Cc: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: SploitCloud: exploiting cloud brokers for fun
and profit
On Wed, Nov 9, 2011 at 2:25 PM, Sam Johnston <samj@...j.net> wrote:
> Apologies for the HTML — too many inline links.
>
> Sam
> SploitCloud: exploiting cloud brokers for fun and profit<http://samj.net/2011/10/sploitcloud.html>
[SNIP]
> *Update:* If you look at the code you'll see the hourly rate is passed to
> the client as "*cost*" and presumably trusted on return (if not, why is
> it there?). I haven't seen a price manipulation vulnerability<http://www.symantec.com/connect/articles/common-security-vulnerabilities-e-commerce-systems>in over a decade, but I'm not tinkering with it because I don't fancy being
> accused of stealing from them or their providers.
>
> *Update:* While the consumer API <http://dl.enomaly.com/scbuyerapi> now
> uses OAuth, the provider API <http://dl.enomaly.com/scprovider> still
> uses Amazon's vulnerable signatures<http://www.daemonology.net/blog/2008-12-18-AWS-signature-version-1-is-insecure.html>for authentication:
>
> #sorts by key.lowercase(). ie A b c Dee e ffFf
> sorted_keys = sorted(parameters.keys(), key=lambda k: k.lower())
>
> #concatenates key,value pairs. a=1,b=2,C=32 becomes "a1b2C32"
> data = ’’.join(key + parameters[key] for key in sorted_keys)
>
> #Data is now: ecp_usernamespotcloudusernameparamAvalueTimestamp2006-12-08T07:48:03Z
> digest = hmac.new(’spotcloudpassword’, data, sha).digest()
>
>
> This may have been safe over SSL were it not for the fact that client
> libraries (including python) typically don't validate the certificate chain
> by default.
>
> http://bugs.python.org/issue1589
"Unfortunately, hostname matching is one of those ideas that seemed better
when it was thought up than it actually proved to be in practice. I've had
extensive experience with this, and have found it to almost always an
application-specific decision..."
and
"It's more of a missing feature than a security issue in itself..."
Jeff
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