Next Page >>
randomly
“Exploit creation – The random approach” or “Playing with random to build
exploits”
Sunday, September 21, 2008
By Nelson Brito <nbrito@sekure.org>
-[ Introduction
It is just a matter of time to get things worse on the Internet. We saw
worms getting more and more sophisticated in last decade, and, believe me,
it could be worst. Nowadays we have botnets and a lot of worms and the
SektionEins GmbH
www.sektioneins.de
-= Security Advisory =-
Advisory: MyBB Password Reset Weak Random Numbers Vulnerability
Release Date: 2010/04/13
Last Modified: 2010/04/13
Author: Stefan Esser [stefan.esser[at]sektioneins.de]
Application: MyBB <= 1.4.11
| | |
| | "The issue is the generation of session ids in the |
| | AsteriskGUI HTTP server. |
| | |
| | When using Glibc, the implementation and state of rand() |
| | and random() is |
| | |
| | shared. Asterisk uses random() to issue MD5 digest |
| | authentication |
| | |
| | challenges and rand() bitwise-ORed with a malloc'd |
Last Modified: 2008/09/12
Author: Stefan Esser [stefan.esser[at]sektioneins.de]
Application: Wordpress <= 2.6.1
Severity: MySQL column truncation allows resetting the passwords of
wordpress users to random strings. Combined with weaknesses
in PHP's PRNG this allows determining the admin password.
Risk: High
Vendor Status: Vendor has released Wordpress 2.6.2 which fixes this issue
Reference: http://www.sektioneins.de/advisories/SE-2008-05.txt
http://www.suspekt.org/2008/08/18/mysql-and-sql-column-truncation-vulnerabilities/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-08.11.arc4random Security Advisory
The FreeBSD Project
Topic: arc4random(9) predictable sequence vulnerability
Category: core
www.sektioneins.de
-= Security Advisory =-
Advisory: PHP GENERATE_SEED() Weak Random Number Seed Vulnerability
Release Date: 2008/05/06
Last Modified: 2008/05/06
Author: Stefan Esser [stefan.esser[at]sektioneins.de]
Application: PHP 5 <= 5.2.5
Release Date: 2008/02/20
Last Modified: 2008/02/20
Author: Stefan Esser [stefan.esser[at]sektioneins.de]
Application: PunBB <= 1.2.16
Severity: Weak random numbers lead to a blind password recovery
vulnerability that allows account takeover
Risk: High
Vendor Status: Vendor has released PunBB 1.2.17 which fixes this issue
Reference: http://www.sektioneins.de/advisories/SE-2008-01.txt
the temporary directory. Users of the cli_gentemp() function can specify their
own custom temporary directory. If none is specified, then the content of the
TMPDIR environment variable is used. If the environment variable is unset, then
P_tmpdir resp. "/tmp" are used. The generated format of the file name is
$TMPDIR/clamav-$HASH, where $HASH is generated from a fixed 16 byte "salt" and
32 (more or less) random bytes.
The salt is defined in the following way:
static unsigned char name_salt[16] = { 16, 38, 97, 12, 8, 4, 72, 196,
217, 144, 33, 124, 18, 11, 17, 253 };
> Particularly the following statement is funny, and shows complete lack
> of understanding of the terminology and of the problem space:
>
> 'ISC would like to assure the Internet community that this is much
> less an issue of using "extremely weak crypto" as it has been
> described, than the use of a random number generator that did not
> provide sufficient randomness.'
>
> My understanding is that they used a pseudo random number generator in
> bind9, and when you use a pseudo random number generator (whose
> sequence in this case is predictable after observing about a dozen
Bugzilla is a Web-based bug-tracking system, used by a large number of
software projects.
Bugzilla 3.2.1, 3.0.7, and 3.3.2, when running under mod_perl,
generated insufficiently random numbers, resulting in all random
tokens being the same, all CSRF protection being defeated, and the
new attachment_base functionality being compromised. Only these
releases were affected--earlier releases are not affected.
All affected installations are encouraged to upgrade as soon as
1. The client sends to the server a message containing a set of flags of
features supported/requested to perform authentication.
2. The server responds with a message containing a set of flags
supported/required by the server enabling both ends to agree on the
authentication parameters and, more importantly, an 8-byte random
challenge/nonce.
3. The client uses the random challenge/nonce and the user's
credentials to calculate the response (24 bytes) and sends it to the server.
4. The server determines if the response is correct and allows or
disallows access to the client.
> Not all security-related technology is
> cryptography. For instance, putting per-user limits on resources prevents
> certain kinds of denial-of-service attacks, but it is certainly not "crypto".
>
> Because a lot of techniques in cryptography require good random numbers, it has
> been widely studied by cryptographers. Therefore if you want a good
> pseudo-random number generator, it is probably a good idea to see what the state
> of the art in the cryptography field is. But random number generation is not
> "crypto" any more than using a series of bit shift and XOR operations is crypto.
On Nov 12, 2007, at 11:27 AM, Matt D. Harris wrote:
> However some of these issues can be mitigated without too much
> trouble. For example, one could have a dynamically growing
> dictionary of words to search for based on random words in random
> results pages that it grabs. At the very least, this would kill
> any attempts to filter it out of the data mining system.
That'd be a significantly different approach. Even grabbing data from
the previously browsed cache would also work, as far as seeding
application developers do not carefully test this attack scenario.
An alternative approach to securing these headers can be achieved
through an optional configuration where the CSS places an additional
prefix string on the inserted certificate headers [4]. For instance, a
server administrator could select a random header prefix through a
command such as:
ssl-server <context> http-header prefix "<random_prefix>"
This would cause the new certificate headers to be included with the
http://www.debian.org/security/ Florian Weimer
July 16, 2008 http://www.debian.org/security/faq
- ------------------------------------------------------------------------
Package : pdns-recursor
Vulnerability : insufficient randomness
Problem type : remote
Debian-specific: no
CVE Id(s) : CVE-2008-1637
Debian Bug : 490069
This exploit targets a fairly ubiquitous flaw in DNS implementations
which allow the insertion of malicious DNS records into the cache of the
target nameserver. This exploit caches a single malicious host entry
into the target nameserver. By causing the target nameserver to query
for random hostnames at the target domain, the attacker can spoof a
response to the target server including an answer for the query, an
authority server record, and an additional record for that server,
causing target nameserver to insert the additional record into the
cache.
>
> This exploit targets a fairly ubiquitous flaw in DNS implementations
> which allow the insertion of malicious DNS records into the cache of the
> target nameserver. This exploit caches a single malicious host entry
> into the target nameserver. By causing the target nameserver to query
> for random hostnames at the target domain, the attacker can spoof a
> response to the target server including an answer for the query, an
> authority server record, and an additional record for that server,
> causing target nameserver to insert the additional record into the
> cache.
>
www.sektioneins.de
-= Security Advisory =-
Advisory: Joomla Weak Random Password Reset Token Vulnerability
Release Date: 2008/09/11
Last Modified: 2008/09/11
Author: Stefan Esser [stefan.esser[at]sektioneins.de]
Application: Joomla <= 1.5.7
Problem:
The htpasswd utility uses predictable salts for the salted algoritms
(Unix-style "CRYPT" and MD5). htpasswd uses the standard C rand()
function to generate "random" salts. In order to use rand(), htpasswd
seeds the random number generator with the srand() function. And that's
where the Apache developers made a critical mistake -- htpasswd
merely uses the time of day (seconds since the Epoch, time(NULL)) to
seed the random number generator.
more,its not a java script,looks like a html page[notice the <html>
and <body> tag n the file] there is also a random function,which
generate the random string which is used to store teh files on c drive
and may be for the random url.its trying to play mp3 and other
files.all looks like messed up.may be there is another script which is
getting embeded in pages which infect calling this script?
On Jan 13, 2008 9:31 PM, crazy frog crazy frog <i.m.crazy.frog@gmail.com> wrote:
> Hi,
>
Apologies I should clarify.
In this attack legitimate pages on a site are first populated with
html tags embedding Javascript like so
<script language='JavaScript' type='text/javascript' src='{random
name}.js'></script>
these all point to the page you sent on. All the Mp3, quicktime, etc
stuff are expoits that are launched against the browser of the victim
who browses to the site.
However some of these issues can be mitigated without too much trouble.
For example, one could have a dynamically growing dictionary of words
to search for based on random words in random results pages that it
grabs. At the very least, this would kill any attempts to filter it out
of the data mining system.
If the point of the system is primarily to create plausible deniability
for the end-user, that is, to allow them to say "hayneedle hit the site,
not me, so I am innocent", then I'd say it could be effective in that
regard barring some proviso in the law that allow them to persecute
>
> > If I read the law correctly, it requires retention of "what IP
> > connected to another IP" and "which phone number called where." It
> > doesn't bother retaining the URL called (my German is rusty, so I
may
> > be a little off in my interpretation). Connecting to a random IP on
a
> > random open port (80 and 443, for example) would be a good start to
> > accomplish the goal creating chatter. The issue is that the search
> > terms to find those ports could lead to connecting to a site that
> > increases your profile against general background chatter, even as
Particularly the following statement is funny, and shows complete lack
of understanding of the terminology and of the problem space:
'ISC would like to assure the Internet community that this is much
less an issue of using "extremely weak crypto" as it has been
described, than the use of a random number generator that did not
provide sufficient randomness.'
My understanding is that they used a pseudo random number generator in
bind9, and when you use a pseudo random number generator (whose
sequence in this case is predictable after observing about a dozen
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: Normal
Title: BIND: Weak random number generation
Date: August 18, 2007
Bugs: #186556
ID: 200708-13
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I'm put in an awkward position of having to respond to a message which
wasn't sent to me in the first place. But still...
"This bug was reported over and over again" - I find this statement
confusing. The bug class of "DNS transaction ID not being random enough"
was sure reported for several DNS server, including BIND. My paper
clearly references e.g.
http://www.openbsd.org/advisories/res_random.txt (as reference [7]).
However, I'm not familiar with public reports that outline the
seriousness of the non-randomness of BIND *9*, to the extent my report
Amusing. They pulled the fix from being released in October at the last
minute, quoting memory leaks. I guess they didn't fully address it after
all...
> Even worse, in my large enterprise, this patch caused the exact spoofing that it intended to prevent. Somehow the code to increase the entropy has caused random xid's to cross and spoof randomly, poisioning the cache through normal usage without the use of extracurricular programs. I've reported this to Microsoft and have been working with them in fixing this issue, which to date has not been fixed.
>
Sounds like they just draw a random number each time, regardless of the
history (i.e. of previously drawn numbers), which can cause collisions
(I think that's the phenomenon you describe). BIND 9 has a mechanism
http://www.debian.org/security/ Florian Weimer
May 13, 2008 http://www.debian.org/security/faq
- ------------------------------------------------------------------------
Package : openssl
Vulnerability : predictable random number generator
Problem type : remote
Debian-specific: yes
CVE Id(s) : CVE-2008-0166
Luciano Bello discovered that the random number generator in Debian's
The buffer which contains the data received by the client in the Hello
packet has the following structure (from yassl_imp.hpp):
class ClientHello : public HandShakeBase {
ProtocolVersion client_version_;
Random random_;
uint8 id_len_; // session id length
opaque session_id_[ID_LEN];
uint16 suite_len_; // cipher suite length
opaque cipher_suites_[MAX_SUITE_SZ];
uint8 comp_len_; // compression length
---> figure out why my antivirus randomly popsup?i
The exploit is served first time you load an infected page and then very
infrequently after that (it was originally thought that it is delivered
only ONCE per visiting IP, but some people put this to the test (and
found that the exploit will appear more than once to a single IP/visitor
- however, it will always appear the first time you hit an infected site).
More on this in the theregister.co.uk link - follow the Comments link in
that article and read the comments.
Next Page>>
|
