Tag Archives: hacking

PHP uniqid() and LCG non-randomness write-up

In twitter conversations with OSVDB the question arose whether the Front Accounting 2.3.13 Predictable File Name and Public Path vulnerability I disclosed yesterday had a connection with a previously reported LCG vulnerability in 2010 since the LCG in PHP apparently uses the uniqid() function.

Although there is a loose connection, the upshot is that they are different. Here’s why.

After checking though the PHP SVN this morning, it seems like the connection is tenuous at best. If we begin with the LCG revisions we notice that in branches 5.2 and 5.3 that we are adding entropy through tv.tv as shown below:

But from our standpoint — determining the connection between LCG and uniqid() — this doesn’t matter much. It’s the fact that it uses the following structure and call:

The call to uniqid() also uses the timeval structure:

Unlike LCG, uniqid() adds it’s randomness in the following way:

Since randomness is added differently, the gettimeofday() function is in fact the only overlap between uniqid.c and lcg.c that concerns us to understand the connection and the difference for this analysis.

For our purposes to answer OSVDB’s initial inquiry the answer comes down to this:

  • Both LCG and the uniqid() function use the same gettimeofday call as the initial seed for randomness, whether through returning a string for uniqid() or as part of PHPSESSIONID
  • LCG and uniqid() are totally separate and use independent calls to fill data structures defined in separate areas of memory
  • the functions do not call one another at all
  • LCG uses the php_combined_lcg() function which does not use uniqid() in any functions below it for session token creation

From an attackers point of view, the key in the LCG attack is the ability to use a function such as uniqid() — which is much more likely to be used by a developer — to get the server’s seed (actual time on the box) and off of which we will base our attack on the PHPSESSIONID since neither offer enough entropy.

Conclusion 1: LCG does not use uniqid() as it’s seed generator. We can see this from the SVN of the committed LCG code linked to earlier: uniqid was neither removed or added. A quick search of the actual LCG code will show that this header or function is not included in the PHPSESSION generating code. The description in NVD and OSVDB is is in fact incorrect for the 2010 attack*.

Conclusion 2: The non-randomness I described in my Front Accounting vuln release is based solely off the uniqid() function and is independent from the LCG functions although both have a similar but not exact non-randomness issue.

I cannot take full credit for this as some of the critical pieces of the LCG attack analysis come from Andreas Bogk in this post at Full-Disclosure.

* The original post of the LCG issue in 2001 shows that PHPLIB session.c called uniqid() but code apparently is for PHP3 and is no longer maintained since 2007. This is most likely where the NVD / OSVBD confusion comes from. Note that the write-up and tool released by samy kamkar for the 2010 disclosure does not mention uniqid(). At no point is uniqid() used in session.c as described in the original 2001 post as of PHP4.

0-Day: Front Accounting 2.3.13 Predictable File Name and Public Path

Front Accounting (FA) had document storage capabilities. Three issues arise:

1) FA stores documents under the server root
2) FA uses a non-random way to generate the report names
3) these reports do not have any authentication, able to be retrieved by anyone

The known file locations are below where X is company number starting at 0 (zero).

http://[server]/company/x/pdf_files/[non-random-string].pdf
http://[server]/company/x/attachments/[non-random-string]

The software uses the uniqid PHP routine which is known for being non-random:
http://php.net/manual/en/function.uniqid.php

Because it is difficult to show, please see the screen print below regarding the non-random name.

I emailed the software company through their website but did not receive a reply. This was also disclosed to securityfocus.com but I believe it was not publicly reported since the email contained the image below as an attachment (or the original email was HTML and not TXT).

frontaccounting-non-random

2000% Increase in Attacks on Israeli Websites

Interesting stats…. (Please do not post political propaganda on my site: it’s about information security not Middle East politics):

An increase of 2000% in attacks on pro-Israel and Israeli government websites was recorded in the first few days after the IDF takeover of the Turkish ship ‘Marmara’ headed for Gaza. Most of the attacks originated from Turkish and Palestinian sources.

Tests conducted by Internet security experts from IBM also found that the attackers managed to breakthrough to 500 Israeli websites and make changes or to plant propaganda on them.

IBM also found that Israeli government sites held up well to the attacks and most of the break-ins were into sites of companies and organizations in the private sector.

Rolling Stone Chronicles Criminal Hackers

Rolling Stone chronicles the lifestyle exploits of Albert Gonzalez, which you can find here in the USA Today article here.  Unfortunately I cannot provide a link to the actual RS article because it is paid only. You can find it at your local newsstand.

Unannounced Ethical Hacking

The French Twitter hacker claimed it was an ethical hack. This defense has rarely been credible in the US since 9/11 due to the uptick in professional services and change in cultural mindset.

… he wanted to reveal just how vulnerable online data systems are to break-ins — and he says he didn’t mean any harm.”I’m a nice hacker,” suspect Francois Cousteix told France 3 television Thursday, a day after he was released from police questioning, adding that his goal was to warn Internet users about data security.

Here is why I no longer report security vulnerabilities I find.