just saying !!

security is a process and not a product.

تابع القراءة ←

LFI: beyond /proc/self/environ

Let’s suppose that we have a simple php application. The web app has a login form and a small news system based on txt files.

So a user can simple log into the system

And access the company’s internal board:

After looping through all the pages, one can guess that the web app is loading the content for each section from a plain text file.

Reviewing the code clarifies the question.

So at this point, an evil user could perform some local file inclusion and read files in the remote system.

We all know how to exploit that via the “/proc/self/environ” way and if we don’t, our friend google can help for sure.

So in thist post we’ll see some other ways to inject php code inside various files in the servers remote system.

If the remote system has the apache access.log accesible via web a hacker can inject php code inside.

Php code can be injected via netcat. By trying to browse and invalid page, the GET request will be stored inside the apache log file:

Then the attacker can call the log file and enjoy the remote code execution.

Various pieces of code can be executed.

If the remote box has ssh auth.log accesible, malicious code can be injected via SSH

By trying to log into the system using an invalid username, the name used will be stored inside auth.log. So the hacker can inject code that way.

Other scenario is presented when the remote and LFI vulnerable web application stores – not sanitized –  data inside a session file. Let’s think about some piece of code like the following:

if($user==’admin’ and $password==’admin1234′){
$_SESSION[“auth”] = 1;
foreach ($_POST as $key => $value) {
if ( substr($key, 0, 4) == ‘cms_’ ) {
$_SESSION[$key] = $value;
}
}

At this point, all post variables starting with cms_ will be included inside the session file, so an attacker can use that to inject evil code.

An attacker can use some proxy like PAROS to alter http traffic on the fly:

By altering the traffic, an attacker will be able to inject a third post variable:

So the attacker can include a variable called cms_whatever and inject php code inside:

Using PAROS, the attacker can look for the session ID.

And now he’s able to exploit the LFI and call the php session file

In a real life scenario, the attacker will include an evil file like a backdoor and gain control of the server.

A shell can be obtained using a php, perl, python or whatever reverseshell like this

Files can be transfered to the remote server via an HTTP server and the wget command used along with the shell_exec php function.

Using shell_exec in php will allow us to run system commands on the remote server.

And after running the perl /tmp/ps.pl command, access is gained on the server

be good!

تابع القراءة ←

SQL INJECTION INTRODUCTION

SQL INJECTION INTRODUCTION

SQL INJECTION INTRODUCTION--

• SQL Injection is the most common vulnerability on the internet.
• It is mainly flaw in the web application & not a Database or web server issue.
• most programmer are still not aware of this threat.

What is SQL Injection ????

• Sql injection is a technique used to take advantage of non-validate Input vulnerabilities to pass SQL commands through a web Application for execution by back-end Database.
• In Other words,Sql injection is a basic techniques /attack used to either gain unauthorised access to a database or to retrieve information directly from the Database.

SQL Injection Attacks ----

1.  Authentication Bypass --- Using this attacks, an attacker logs on to an application without providing valid username & password & gain the administrative privileges.
2. Information Disclosure --- Using this attacks, an attacker obtain the sensitive Information that is stored in the database. 
3. Compromised Data Integrity --- An attacker uses this attack to deface a webpage ,insert malicious content into webpages , or alter the content of database. 
4. Compromised Availability of Data --- An attacker use this attack to delete the database information logs or audit information that is contained in database. 
5. Remote code Execution --- It allows an attacker to compromise the Host O.S.

How web Application Works ----

• The above fig. shows how the initial request is triggered by the user through the browser over the Internet to the web application server. 
• The web application accesses the databases servers to perform the requested task updating and retrieving the information lying within the database. 
• The web application then presents the information to the user through the browser.

Web Security Issue ----

• web applications do raise a number of security concerns stemming from improper coding. Serious weaknesses or vulnerabilities, allow hackers to gain direct and public access to databases in order to sensitive data.
• Many of these databases contain valuable information (e.g., personal and financial details) making them a frequent target of hackers
• Websites and related web applications must be available 24 hours a day, 7 days a week, to provide the required service to customers, employees, suppliers and other stakeholders.
• Firewalls and SSL provide no protection against web application hacking, simply because access to the website has to be made public – All modern database systems (e.g. Microsoft SQL Server, Oracle and MySQL) may be accessed through specific ports (e.g., port 80 and 443) and anyone can attempt direct connections to the databases effectively bypassing the security mechanisms used by the operating system. These ports remain open to allow communication with legitimate traffic and therefore constitute a major vulnerability.
• Web applications often have direct access to back-end data such as customer databases and, hence, control valuable data and are much more difficult to secure. Those that do not have access will have some form of script that allows data capture and transmission. If a hacker becomes aware of weaknesses in such a script, he may easily reroute unwitting traffic to another location and illegitimately hive off personal details.
• Most web applications are custom-made and, therefore, involve a lesser degree of testing than off-the-shelf software. Consequently, custom applications are more susceptible to attack.

Types  of SQL Injection ---

There are mainly TWO types of SQL injection ----

1. Simple SQL Injection 

• Union SQL Injection
• Error Based SQL Injection.

2.Blind SQL Injection

تابع القراءة ←