random numbers
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
A similar issue exists in the IPV4 protocol handler and will be fixed
in a subsequent update.
CVE-2007-2453
A couple of issues with random number generation were discovered.
Slightly less random numbers resulted from hashing a subset of the
available entropy. zero-entropy systems were seeded with the same
inputs at boot time, resulting in repeatable series of random numbers.
CVE-2007-2525
is good piece of code to take a look (randnops.c), here some explanation:
* Ignore the “7QZ” and “IQZ”, they cannot be disturbed at
all;
* Calculate the length of decoder, ignoring three bytes, as
mentioned;
* Get random number between 0 and total length available,
this will control how many bytes will be injected;
* Get random number to determine the position of bytes to
inject; this will control the randomized positions bytes will be injected;
* Check if the position is not already in use, if so skip
the position and try again;
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
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
http://www.youtube.com/watch?v=NMhO00bnRzM
It's about abusing PHP's builtin PRNG functions to attack web applications.
It starts where Stefan Esser's wonderful article "mt_srand and not so random numbers" ( http://www.suspekt.org/2008/08/17/mt_srand-and-not-so-random-numbers/ ) ended.
I've made some improvements to his idea. Since mt_srand()/mt_rand() are very slow (~17 hours to try all possible 2^32 seeds on my AMD Phenom 2.6 ghz machine) and lookup tables are huge (at least 32 GB), I implemented rainbow tables. With a chain length of 10000 and 512k rows, the table size is 11MB and average search takes only about 35 min. Rainbow table parameters can be tuned (longer chains = less space, but slower seed crack, shorter chains and more rows = more space, but less time to crack the seed).
Since it's about password reset attacks, time to predict the random string is crucial for the effectiveness of the attack.
The concept of DNS cache poisoning was discussed many times before.
However, this attack was considered impractical for the leading
industrial DNS servers due to the transaction ID mechanism that DNS
servers implement today. The transaction ID is supposed to be a
secure, random number that the attacker must guess in order to poison
the DNS cache. There are 65,536 combinations which make enumeration
impractical in the current network conditions.
I've recently found a weakness in the transaction ID generation
algorithm of BIND 8 (both for USE_POOL and for SHUFFLE_ONLY algorithm
Problem type : remote
Debian-specific: no
CVE Id(s) : CVE-2008-1637
Debian Bug : 490069
Thomas Biege discovered that the upstream fix for the weak random number
generator released in DSA-1544-1 was incomplete: Source port
randomization did still not use difficult-to-predict random numbers.
This is corrected in this security update.
Here is the text of the original advisory:
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
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/
http://www.suspekt.org/2008/08/17/mt_srand-and-not-so-random-numbers/
Overview:
Quote from http://www.wordpress.org
For the talks we have:
Tech Talk: Paco Hope of Cigital is going to present on randomness...
We've seen how to get good random numbers from hardware.
Given that, you would think that shuffling cards, rolling dice, and
random session identifiers would be easy. They're not. Our instincts and
intuition are often wrong. We'll look at shuffling and algorithms gone
wrong, and talk about doing it right. Expect a few surprises.
addresses them for etch (oldstable) aswell:
CVE-2008-2107 / CVE-2008-2108
The GENERATE_SEED macro has several problems that make predicting
generated random numbers easier, facilitating attacks against measures
that use rand() or mt_rand() as part of a protection.
CVE-2008-5557
A buffer overflow in the mbstring extension allows attackers to execute
of cryptographic secrets like random password
reset tokens
Risk: High
Vendor Status: Vendor has released a partially fixed Joomla 1.5.7
Reference: http://www.sektioneins.de/advisories/SE-2008-04.txt
http://www.suspekt.org/2008/08/17/mt_srand-and-not-so-random-numbers/
Overview:
Quote from http://www.joomla.org
downloaded from the Trango website.
To carry out the attack, you would need to find line-of-sight and have
good signal strength (between -40 and -80 dBm) to the target AP, and
have knowledge of an SUID which is already connected, or try random
numbers until you find one which works - most providers have quite a
number of subscribers per AP so this should not be hard. Many providers
will physically mark their SUs with the SUID and APID with a permanant
marker, so if you have physical access to a connected SU, finding this
information is probably trivial.
srand(tv.tv_usec+clock());
return rand() % max;
}
As you can see, every time cli_rndnum() is called, the random number generator
is reinitialized with the microsecond component of the current time and an
"approximation of the processor time used by the program" using the clock()
function. This takes away a lot of randomness from the value returned by
cli_rndnum(): as seed, more or less public information which should be
relatively easy to be guessed by the attacker is used, making it possible to
C:\xampp\tmp (if your XAMPP installation was in C:\xampp\)
The files are named phpXXXX.tmp (where X's charset is 'a'-'z', 'A'-'Z',
'0'-'9'). Example: php1A00.tmp
This 4 char random number is a limitation of PHP on Windows.
PHP on Unix is using 6 chars for its temporary filenames so it doesn't
reach this condition.
12:31 - attack is aborted
12:39 - CPU usage is still 100%, web server is not responsive.
characters inside the escapeshellcmd() function, which is used to
sanitize user input before its usage in shell commands
(CVE-2008-2051).
* Stefan Esser reported that a short-coming in PHP's algorithm of
seeding the random number generator might allow for predictible
random numbers (CVE-2008-2107, CVE-2008-2108).
* The IMAP extension in PHP uses obsolete c-client API calls making
it vulnerable to buffer overflows as no bounds checking can be done
(CVE-2008-2829).
ssh-rand-helper is enabled at configure time when it is
detected that OpenSSL does not have a built-in source of
randomness, and only used at runtime if this condition
remains. Platforms that support /dev/random or otherwise
configure OpenSSL with a random number provider are not
vulnerable.
In particular, *BSD, OS X, Cygwin and Linux are not
affected.
The concept of DNS cache poisoning was discussed many times
before. However, this attack was considered impractical for the
leading industrial DNS servers due to the transaction ID
mechanism that DNS servers implement today. The transaction ID is
supposed to be a secure, random number that the attacker must
guess in order to poison the DNS cache. There are 65,536 possible
transaction ID values which make enumeration impractical in the
current network conditions.
The weakness I found is in the transaction ID generation
00040786 mov ebx, eax
00040788 lea eax, [ebp+Seed]
0004078B push eax ; Seed
0004078C call esi ; RtlRandom(x)
The calls to ntoskrnl.exe!RtlRandom(&seed) generate 3 'random' numbers.
Based on the value of random_number3, random_number1 and random_number2 are
modified:
0004078E test al, 1
00040790 mov ecx, 80000000h
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
that ensures that collisions are discarded. OpenBSD retains history of
the last 32K (IIRC) numbers used, and does not re-use those numbers.
PowerDNS randomizes UDP source ports, so it considerably reduces
http://localhost/torrenttrader109/account-recover.php
Anyone can initiate password reset, only condition is, that target's email
address must be know. Torrenttrader will check email address and after successful
validation new, temporal password will be generated and sent to that email address.
Specific autogenerated password appears to be random number between 10000 and 50000,
so basically there can be only 40000 possible temporal passwords. It's easy to
write bruteforce script, which will try all possible password combinations.
This process can take couple of hours or more, but eventually the password will
be guessed and target account becomes compromised.
|
