Tran Bang’s Blog

Recent update

• [PHP] FSOCKOPEN - một bước lên pro
• [CMS] Phân tích các PHP-CMS đang hoạt động
• Zend Http Client Bug/ Improvement
• mt_srand and not so random numbers
• Lần h@ck nhảm nhất
• Thăm dò ý kiến của bạn
• Tấn công mục tiêu bên cạnh
• Local Attack

[CMS] Phân tích các PHP-CMS đang hoạt động

November 28th, 2009 by squallcs12

be updated later!

Posted in Uncategorized | tagged cms | | 0 Comments

mt_srand and not so random numbers

November 17th, 2008 by squallcs12

Vừa được cho phép post bài này nên post lên đây cho bà con xem luôn. Một bài viết khai sáng trí óc:D. Bài post được lấy từ : http://www.suspekt.org/2008/08/17/mt_srand-and-not-so-random-numbers/. Cảm ơn Stefan Esser vì đã viết 1 bài hay như thế này.

PHP comes with two random number generators named rand() and mt_rand(). The first is just a wrapper around the libc rand() function and the second one is an implementation of the Mersenne Twister pseudo random number generator. Both of these algorithms are seeded by a single 32 bit dword when they are first used in a process or one of the seeding functions srand() or mt_srand() is called.

Because of such a short seed it should be obvious to everyone that neither rand() nor mt_rand() are random enough for cryptographic usages. However web application programmers tend to use rand() or mt_rand() to create cryptographic secrets like passwords, activation keys, autologin cookies or session identifiers. In many situations this seems secure enough, because not only a 32 bit seed needs to be guessed but also the amount of previously generated random numbers. Therefore bruteforcing seems impractical.

There are however several situations and conditions that make bruteforcing feasible or not required at all.

The Implementation

When mt_rand() is seeded internally or by a call to mt_srand() PHP 4 and PHP 5 <= 5.2.0 force the lowest bit to 1. Therefore the strength of the seed is only 31 and not 32 bits. In PHP 5.2.1 and above the implementation of the Mersenne Twister was changed and the forced bit removed.

Implementation Bugs

In PHP 4 and PHP <= 5.2.5 the automatic seed of rand() and mt_srand() is buggy. Whenever the lowest 26 bits of the timestamp are zero the internal seed will become zero (or 1 due to the forced bit) on 32 bit systems because of an overflow of the 32 bit register. On 64 bit systems there is a precision loss when the seed is casted from a double to int that results in a seed about 24 bit strong.

Weak seeding

Although PHP 4.2.0 and above internally seeds the random number generators many PHP applications still call srand() and mt_srand() themself to seed the random number generators. Popular seedings look like one of the following examples.

mt_srand(time());
mt_srand((double) microtime() * 100000);

mt_srand((double) microtime() * 1000000);
mt_srand((double) microtime() * 10000000);

These seedings are all bad because

1. time() is not random. It is known by the attacker(). Even a wrongly set clock on the server side does not protect because time leaks through the Date HTTP Header.
2. The first factor is between 0 and 1 and the second factor is 100000. Therefore there are only 100000 possible seeds which is a strength of about 17 bits. On older PHP versions the forced seed bit results in only 16 bit strength. (Due to rounding issues there might be less)
3. The first factor is between 0 and 1 and the second factor is 1000000. Therefore there are only 1000000 possible seeds which is a strength of about 20 bits. On older PHP versions the forced seed bit results in only 19 bit strength. (Due to rounding issues there are less)
4. The first factor is between 0 and 1 and the second factor is 10000000. However because microtime() depends on the current microsecond() there are only 1 million possible results, which again results in a seed with a strength of about 20 bit. (Due to rounding issues there are less)

CGI seeds once per request

Because in a CGI environment every request is handled by a fresh process the random number generators are always freshly seeded. Therefore an attacker only needs to bruteforce 32/31 bits and does not need to guess how many random numbers where already generated. In case of information leaks generated during the same request using the same random number generator it is possible to use precalculated attack tables.

Crashing PHP for fresh random numbers

Whenever a process is reused for random numbers attacking becomes more difficult, because the internal state of the random number generator is unknown. Therefore any crash bug in PHP is welcome. In older PHP versions crashing PHP is just a matter of sending deeply nested arrays in GET, POST or COOKIE variables. Whenever a crashed PHP process is replaced by a fresh one, a new seed is generated and the internal state of the random number generator just depends on the 32 bit seed. Here precalculated tables can also be used in case of information leaks.

Keep-Alive is your friend

When some information is known about the internal state of the random number generator Keep-Alive HTTP request can make exploits very easy. Because follow request during a Keep-Alive HTTP connection are handled by the same process (same random number generator) the state of the random number generator stays the same and random numbers can be precalculated from the outside. While this is always true for mod_php, it is not true for CGI and only sometimes true for fastcgi setups.

Shared Ressource Problem

Both random number generators are a shared ressource, because the state is stored in process memory and future request in the same process will continue with the previous random number state. Because of this in shared hosting environments that do not use a CGI setup a malicious customer on one VHOST can set the random number generators in a known state by calling srand(0) or mt_srand(0). With the help of Keep-Alive requests it is then possible to predict the random numbers used on other VHOSTs. This of course allows the prediction of newly generated passwords, activation keys or session identifiers.

Information Leaks

Sometimes applications initialize the random number generator and at the same time they generate a random number that is then sent to the user. An example is the search function of phpBB2, where the search_id is generated with mt_rand() and then written to the HTML.

mt_srand ((double) microtime() * 1000000);
$search_id = mt_rand();

The problem with this is that in the example above the search function does not only set the random number to a 20 bit wide state but it also leaks the state through the search_id output. In this example there are only 0,003% collisions. Therefore in 99,997% of the calls knowing the search_id means knowing the seed, too. An attacker can simply create a lookup table with one millon entries to determine the seed by search_id. In case one of the collisions is hit (which is quite unlikely) he can just search again.

For PHP versions that force the lowest bit to be 1 like PHP 4 and PHP 5 <= 5.2.0 the numbers above are incorrect. These versions use only 19 bits, which also causes fewer collisions.

The Art of Cross Application Attacks

It is not so obvious why the phpBB2 search_id information leak is a problem, because it is not used in a cryptographic manner. The previous paragraphs however contained enough information to explain why this is a problem after all.

• Initializing the random number generator affects not only the PHP script doing it, but also every other script executed by the same process
• When the state of the random number generator is leaked all future random numbers are predictable
• Several applications create passwords, session identifiers, activation links or other cryptographic tokens with mt_rand()

In addition to that you must stop to consider your application (phpBB 2) to be the only one. In the real world multiple applications that perform different tasks are installed on the same server, most probably even in the same VHOST. Imagine for example a company running a support forum (phpBB 2) and a blog (Wordpress).

In such a situation touching the random number seeding becomes a threat. Especially when the seed leaks. A real world attacks against the combination phpBB2 and Wordpress would look like.

1. Use a Keep-Alive HTTP Request to search in the phpBB2 forum for the string ‘a’
2. The search should return enough results so that multiple pages are returned which leaks the search_id
3. A simple table lookup is performed by the attacker to determine the random number seed
4. The attacker initializes his random number generator and throws away one random number. (the search_id)
5. The attacker then uses the still active Keep-Alive HTTP request to send an admin password reset request to the Wordpress blog.
6. The blog uses mt_rand() to generate the activation link and sends it to the admin by email.
7. The attacker can calculate the activation link because his random number generator has the same state.
8. The exploit triggers the activation link (over the still active Keep-Alive Request) which results in the new admin password beeing sent to the admin.
9. Because the new password is generated by mt_rand() the attacker can also calculate it on his side.
10. After that the attacker knows the admin password of the Wordpress blog an can take it over.

This shows that installing two independent applications that both use PHP’s random number generators can result in new cross application security vulnerablities that are as serious and dangerous as every vulnerability contained in a single application.

In order to fight this class of cross application vulnerabilities in the next days a generic protection will be added to the Suhosin extension that increases the strength of the mt_rand() seed from a single dword to a multi-dword width. In addition to that an option will be added to ignore the mt_srand() which will be activated by default. This closes the problem of the cross application attack without requiring any changes in the applications.

On the other hand it is strongly recommended for the PHP developers to add more secure random number functions to the PHP core and it is strongly recommended for PHP application developers to keep their fingers away from srand() or mt_srand() and to never ever use rand() or mt_rand() for cryptographic secrets.

Posted in Uncategorized | | | Comments Off

Lần h@ck nhảm nhất

November 14th, 2008 by squallcs12

Hồi đó để check mức secu của cái server web đang xài. Kiếm dc 1 cái list website chung server. Check thử trang congtyxxx.com trước. Vì là trang web công ty -> admin lười -> check trước.
Thấy trang web cũnh đẹp, thiết kế độc đáo -> tự viết -> càng dễ có lỗi.
Chuyện đầu tiên là tìm link tới trang admin -> tìm cả website không thấy có -> bị giấu đi rùi.
Thử may mắn dò file nhảm nhỉ congtyxxx.com/robot.txt -> có thiệt -> khỏe.
Đọc file thấy có thư mục aminsd, nghi nghi nên vào thử -> trang admin thiệt.
Vào congtyxxx.com/aminsd -> ko có password -> vào thẳng trang admin luôn ,có chức năng upload file dạng đơn giản(ko check filetype) -> admin lười nên tưởng hem ai bít thư mục admin -> không thèm set pass ?????
Tự nhiên thành công, chả hiểu vì sao.

Posted in Uncategorized | tagged hack | | 8 Comments

Thăm dò ý kiến của bạn

November 11th, 2008 by squallcs12

Thấy mấy bài đã viết hơi chung chung, với lại cũng có người bảo nên viết chi tiết hơn nữa. Bởi vậy nên tui muốn thăm dò xem các bạn nghĩ tiếp theo bài viết của tôi nên như thế nào?
1. Giữ như cũ (cung cấp thông tin dạng chung để người đọc tự tìm hiểu)
2. Giữ như cũ, nhưng kèm giới thiệu tới những bài viết chi tiết hơn có liên quan
3. Chuyển thành bài viết về những vấn đề cụ thể hơn, chi tiết hơn
4. Chuyển thành bài tut chi tiết, có demo, có lời dẫn.
Vote qua comment nha.
Thank all.

Posted in Uncategorized | tagged vote | | 19 Comments

Tấn công mục tiêu bên cạnh

November 9th, 2008 by squallcs12

Tiếp theo bài post trước….

Như đã nói, local attack là tấn công từ user cùng server với nhau. Vậy làm sao có thể sử dụng một user này để tấn công một user khác? Thông thường có 2 cách:

1. Cách này tốn khá nhiều thứ quý giá : tiền. Lấy  tiền mua một cái host trên server đó rồi local -> chắc 100% thành công.
2. Tấn công vào website cùng server có độ bảo mật thấp hơn. Sau đó local.

Thông thường hacker sử dụng cách thứ 2, chắc ai cũng hiểu lý do. Vậy làm sao để tấn công vào những mục tiêu bên cạnh? Có mấy bước sau:

1. Tìm xem trên server có những website nào? Cách hiện tại được dùng nhiều nhất là Reverse IP domain đó. Hiện tại có khá nhiều website cung cấp dịch vụ này.

2. Sau khi tìm được danh sách website, lần lượt check xem website nào có khả năng tấn công thành công và có thể sử dụng local.

3. TIếp theo đó tấn công website đã chọn.

4. Sau khi attack thành công, bắt đầu local attack.

5. Local attack thành công hay thất bại còn là chuyện sau này.

Quan trọng nhất ở 5 bước này là tìm xem website nào có độ bảo mật kém hơn và có thể bị hack. Thường nhưng website như thế là:

1. Những website tự làm, khả năng mắc lỗi thường cao.

2. Những source code phổ thông nhưng version đã lỗi thời.

Nếu tìm thấy trường hợp số 1, từ từ check lỗi và hack.

Nếu tìm thấy trường hợp số 2, có thể check xem version hiện tại có lõi gì không tại trang web milw0rm.com

Từ đó, các bạn có thể thấy ra được khi nào mình xài local. Đó là những website có độ bảo mật cao, không thể tấn công qua lỗi lập trình, đồng thời server config khá an toàn không thể tấn công chiếm root, bắt buộc phải local.. Những website như thế thường là những website được update thường xuyên nếu như là cái source thông dụng hoặc những website với coder pro :D.

Nói từ đầu tới h, chắc các bạn cũng nhận ra dù muốn hay không, nếu không thể chiếm server bằng cách này hay cách khác, hacker vẫn bị bắt buộc phải tấn công trực tiếp thành công một website khác. Nói như vậy, nghĩa là muốn local, hacker phải luyện mấy cái khác trước đã. Vì quan điểm này cho nên trong một số trường hợp, có thể sử dụng local :D.

Nghĩ đến chuyện tấn công trực tiếp một website nào đó với mục đích up shell / local, hacker phải lợi dụng những lỗi/lỗ hổng để can thiệp vào cấu trúc của website. Nếu các bạn đã biết, có những lỗi cực ký cơ bản mà ai tham gia security zone đều biết như:
1.Lỗi Sql Injection
2.Lỗi XSS
3.Lỗi zero-length string (có cả chuyên gia chuyên khai thác lỗi này luôn nè). -> bữa trc Joomla bị lỗi này nè.
4. và còn nhiều nhiều nữa… mà tui hok biết.
Mỗi lỗi có mức độ nguy hiểm , cách kiểm tra, và cả cách phòng chống khác nhau. Còn hacker làm sao biết nên khai thác lỗi nào, câu trả lời chỉ có thể là từ kinh nghiệm -> test các lỗi xem dính cái nào thì làm việc với cái ấy thôi…..

Nhìn chung, muốn tấn công những website dạng như vbb thuần hoặc joomla thuần hay đại loại giống vậy, cách duy nhất là local :D. Có vài hacker tự nhận mình là Hacker Mũ Bạc (đẹp), để thoát ra cái vòng trắng đen nhưng thực chất đó chỉnh là hacker mũ xám hay thậm chí có khi tệ hơn là script kiddies giả danh, sử dụng những chiêu local thế này để nổi danh. Thực chất không đáng nói lắm.

Bài viết này chỉ nhằm dẫn người đọc đến con đường chính đạo mà thôi.

Posted in Uncategorized | tagged hack, local attack | | 4 Comments

Local Attack

November 8th, 2008 by squallcs12

Local  Attack là một trong nhưng phương thức hack không được khuyên dùng vì lý do đạo đức. Tuy nhiên tìm hiểu và đề phòng local attack lại là một chuyện thú vị rất được quan tâm.

Define:

Đối với một web server thông thường.

Khi các bạn host site của mình trên server, thông thường bạn được cấp 1 account trên server đó và một thư mục để quản lý sai của mình. Ví dụ là /user/username1. Tương tự như vậy cũng có 1 thư mục là /user/username2. Giả sử /user/username2 bị hacker chiếm giữ, bằng các script thông thường, hacker có thể truy cập đến các file của bạn ở /user/username1. Các tấn công dựa trên những script ở user này tấn công vào host của user khác trên cùng server gọi là Local Attack.

More:

Thông thường nhất, Local Attack được sử dụng để đọc lấy thông tin config từ victim, sau đó dựa vào thông tin config này để phá hoại website.

Từ phương thức của Local Attack, cách phòng chống Local Attack chủ yếu dựa trên 3 mục:

Config của server: cấu hình server của super admin, tùy vào cách cấu hình mà khả năng tránh local attack sẽ tăng or giảm

Source code của website: thường các website khi chạy trên mạng không dc zend ( encode php ) hoặc mã hóa. Khi đó local attack sẽ dễ  dàng hơn. Ngoài ra tùy vào source của từng website và tùy chỉnh của developer mà có thể hoặc không thể tránh local attack.

Chương trình bảo vệ trên server: những chương trình như NAV hoặc KPS có thể chặn được những scrip độc hại -> disable local attack

Nói sơ qua về cách tấn công: như đã nói trong phương thức, chủ yếu là hacker phải đọc được config của website để tiến hành cách bước tiếp theo ( :”> ). Việc xác định file config nằm ở đâu và làm thế nào để đọc được nó đòi hỏi cả trình độ lẫn kinh nghiệm. Sau khi xác định được file config, hacker sẽ sử dụng các lệnh khác nhau để cố gắng lấy nội dung của file nay. Ở đây đưa một số ví dụ về vài vị trí file config

VBB: <root>/includes/config.php
Joomla <root>/configuration.php
………….

Nói về vài cách mà tôi biết:

Về server: Jail Apache : từ host của user này không thể truy cập tới file ở host của user khác
Về web source code: Zend -> encode source để hacker ko thể đọc được nội dung dù đã tìm ra file, chmod file để ko thể đọc từ bên ngoài …
Về security app: NAV -> tắt dc nhưng script như Shell r57 r59 …

Nhìn chung, đối với tất cả các website thì local attack là ác mộng vì gần như nếu bị local attack thì sẽ die trong nháy mắt. Tuy nhiên những hacker thực sự sẽ không sử dụng cách này trừ khi bị khiêu khích. Cho nên nếu bạn là web master, hãy ngoan ngoãn và đề phòng. Nếu bạn là server admin, phải bảo vệ cho người dùng. Nếu bạn là hacker, làm ơn đừng sử dụng cách này. Còn nếu bạn như tui nghĩ, không cần lo nhiều về nó.

Hy vọng cung cấp nhiều từ khóa để cho các bạn google :D.

Posted in Uncategorized | tagged hack, local attack | | 1 Comments