Latest News

Bash-Bug Penetration Testing - Anatomy of Shelllock

A new security vulnerability known as the Bash or Shellshock bug could spell disaster for major digital companies, small-scale Web hosts and even Internet-connected devices.

The quarter-century-old security flaw allows malicious code execution within the bash shell (commonly accessed through Command Prompt on PC or Mac's Terminal application) to take over an operating system and access confidential information.

A post from open-source software company Red Hat warned that "it is common for a lot of programs to run Bash shell in the background," and the bug is "triggered" when extra code is added within the lines of Bash code.

Security expert Robert Graham has warned that the Bash bug is bigger than Heartbleed because "the bug interacts with other software in unexpected ways" and because an "enormous percentage" of software interacts with the shell.

"We'll never be able to catalogue all the software out there that is vulnerable to the Bash bug," Graham said. "While the known systems (like your Web server) are patched, unknown systems remain unpatched. We see that with the Heartbleed bug: six months later, hundreds of thousands of systems remain vulnerable."


Indepth Code Execution in PHP: Part Two

This is a continued post from Code Execution in PHP; you can read the first post here, so if you haven't read that before please go ahead and read it first or else you would have problem understanding the second part.

“…It’s no secret that PHP is an easy language to which anyone with amateur coding skills could work with and as a rule with poor knowledge of basic security concepts, this factor alone often lead to new poorly written web-applications; Thus compromising their hosts and extraction of sensitive information. Recently, I was on a pentest for a project to which I was working on and went noticing unusual type of code execution. I decided to write about Code Execution Indepth because the developers need to focus on their poorly written web applications in PHP. This article will try covering code execution flaws in places which are less predictable and detail on snippets of code which might look secure while providing possibilities for ‘code injection’...”

In the earlier article, I tried covering practical examples which could potentially lead to Remote Command Execution (RCE) in PHP. Now let’s discuss about some other methods/mistakes which a PHP developer might just had done in writing his/her web application.

Curly Braces:

They say curly syntax is meant to separate code from strings.  In contrast to this view, what it actually does is, ‘embed’ it. As in PHP manual pages written, it means that it would allow to use complex expressions (too complex but let’s just stick with minimal complexity for the sake of the demonstration).

Imagine Curly braces being used this way:

    $finalizae="My birthday is 19{'year}.";
    print $finalize

The code used is supposed to ‘echo’ out the year variable (97) embedded inside “My birthday is 19xx” so an user had to submit ‘12’ to the ‘year’ as an input, it code would print out or ‘echo’, “My birthday is 1912”

Maliciously submitting an input such as ‘dir’ would end up listing files and folders of current directory when $finalize is called in the realm of PHP. This in turn would provide vivid information to a web attacker. Other commands are possible, I had just used ‘dir’, to be reliably simple enough!

Let’s imagine cases like:

     $brief="I was here until ${`dir`} appeared here";

From the aforementioned code, ‘dir’, the system command would get executed. Wow. Why did that happen? Well, the code between curly braces will be evaluated and result will replace {`dir`} thus ending up creating a variable. That is the absolute reason why if this one PHP will be complaining about undefined PHP variable. What happened is fairly similar to:


“$breif” is a result of the “dir” command as a string, similar malicious case for an web attacker to execute commands and ex-filtrate information would be:


If the above example for example stored name as the username and our username submitted was ‘phpinfo’, what happened as per the malicious request submitted as a payload leads to command execution revealing sensitive information disclosure.

Other Cases:

There are functions such as assert() which could be equally exploited but is rarely known to the web developers, it is often found on CTF challenges, same thing as the eval function.


Assert is designed to help with debugging and not evaluation, thus, leading to command execution. So if you use assert in a user supplied input which you think is trustable, probability is your code might just be vulnerable to Remote Code Execution (RCE) using malicious payloads by users of the application you trust.

Developers can use array functions to apply some list of properties to data or reverse. In most cases applying functions are predefined, and these types of vulnerabilities are not ‘almost’ known to the public or is limited by knowledge.

Anyway, These are the array functions I had been dealing with which could lead to RCE:

    array_intersect_uassoc(), usort(), uksort(), array_filter(),
    array_diff_uassoc(), array_diff_ukey(), array_reduce(),
    array_udiff(), array_udiff_assoc(), array_udiff_uassoc(),
    array_intersect_assoc(), array_uintersect(), array_uintersect_assoc(),
    array_uintersect_uassoc(), array_walk(), array_walk_recursive() ,
    uasort(), array_map()

In short, don’t use those with a user supplied input unless sanitized properly in PHP. The formula for an almost secure web application is to never trust input from users!

Let’s take the last function for an example (array_map) and exploit it:

    $evil =$_GET['name'];

Honestly, this is a rare snippet of code but just to prove the point behind mysterious remote code execution attacks, grab me an opportunity to explain what it does! It receives a parameter called ‘name’ via GET request and use this parameter to map it into an array called ‘$some_array’. But the function is also designed to execute call backs to functions. Developers using insecure coding practices do not realize this, thus leading to RCE exploitation with exploits like the following demonstrated:


The payload ‘phpinfo’ will be executed and the resultant would be a remote code execution bug which persists due to insecure coding practices. This theory is practical but there is a limitation. The limitation being, only we can call already written functions like phpinfo() or uname() but can’t write a code to be executed other than call functions.

These other functions are using callbacks, but they are not array based like previous once. They can however be used to create situations like demonstrated before in this article, so do not use them in user supplied input.

    stream_filter_register(), set_error_handler()
    register_shutdown_function(), register_tick_function()

And some other XML functions by default enabled in php:
  • ·xml_set_character_data_handler()
  • ·xml_set_element_handler()
  • ·xml_set_end_namespace_decl_handler()
  • ·xml_set_external_entity_ref_handler()
  • ·xml_set_notation_decl_handler()
  • ·xml_set_default_handler()

 or pretty much, xml_set_*_*()

Remember: function call backs/functions using them are good! However in certain cases they are very bad for the logic of the application to behave as we had witnessed in this article. Most of the issues covered weren’t vulnerabilities. Infact, they were features of PHP. But, from improper usages of these *features*, the worse can happen and could lead to existence of potential vulnerabilities tossing up an opportunity for a web attacker to compromise the security of an application. Please be wise and read the manual of a (new) function before implementing in on a practical code and running them on production servers.

Happy Hacking!

About the Author 

This following article is a guest post by Paulos Yibelo. Yibelo is the newest member of RHA family. He is a full time PHP coder and most of his research is involved with application security. In his free time he loves writing articles related to application security

Call For Papers for nullcon Goa 2015

Dear Security Gurus,

We are excited to announce Call For Papers for nullcon Goa 2015. Time to tickle your gray cells and submit your research.

6th year | CFP opened on 6th Aug 2014 | conference on 6th Feb 2015.

CFP Details:- 

Training: 4th-5th Feb 2015

Conference: 6th-7th Feb 2015

Our motto - "The neXt security thing" drives the objective of the conference i.e. to discuss and showcase the future of information security, next-generation of offensive and defensive security technology, zero day vulnerabilities and unknown threats. 

Get ready to Goa!

Forceful Sale of Stove by HP (Hindustan Petroleum) Bhogpur Gas Service in Dalli, Bhogpur, Jalandhar, Punjab

This is regarding the forceful sale of stove by HP (Hindustan Petroleum) Bhogpur Gas Service in Bhogpur, Jalandhar, Punjab

The above news has been published in No. 1 Punjabi Newspaper AJIT on 1st September 2014 on page number 8.

Complaint against Distributor : BHOGPUR GAS SERVICE (13896100) 
From HP side communication done by Mr.ASHISH SINGH (192249) 

I had booked for a new HP gas connection and was called on Saturday (02/08/2014) as the connection was available. When I visited the company, I was told to buy stove along with other accessories. I humbly mentioned that I already have a stove manufactured as per the industry standards and I would need only the gas connection.

The manager over there informed me that I would get connection only if I buy the stove. When I asked the formal route of getting a connection without stove, they said without verification they will not provide the connection. Here I’ve seen a strange practice of forcing the customers to buy the stove and then making them sign the document mentioning that they were not forced to buy.

If we denied buying the stove, they will not give us the GAS connection & return back all the documents by saying that without verification they cannot provide the gas connection.


I also noticed the Rude behavior of owner/manager of the agency.

Through the MRTPC notification, HP has clearly mentioned that it is not obligatory to purchase the stove from dealers/distributors. But this is not being followed in Bhogpur Gas Service in Bhogpur, Jalandhar. Such activities are spoiling the name and fame of Hindustan Petroleum Corporation Limited.

For all other facing similar problem, you may please visit below website to log your complaint against any HP distributor across India. Once the complaint has been logged, response is mandatory from HP representative.

#HPCL #HindustanPetroleum #Bhogpur #AjitNewspaper #PunjabiNews #Dalli #Complaint #ForcefulSaleofStove #ForcefulSale

Contact Us

24x7 online , we happy to answer you , ,
skype: greeenchip


This Blog and its TUT's are intended for educational purposes only, no-one involved in the creation of this TuT may be held responsible for any illegal acts brought about by this Blog or TuT.

Featured Post

Custom Domains And HTTPS Redirection Code