News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Jani Hartikainen:
Library author Don't provide an exploitable interface
September 02, 2013 @ 11:18:05

Jani Hartikainen has shared a recommendations to library authors out there - don't make your library exploitable. That is, don't make it, by default, open to common attacks like SQL injection or cross-site scripting.

SQL injection is a pretty big deal. Its cousin shell injection is also a common issue, demonstrated quite well by a recent post to the PHP reddit. Although some suspect it was a troll, I heard echos from a variety of people who had seen pretty much exactly the same vulnerability in production.

This got me thinking: People writing libraries for doing things like shell commands, SQL, etc., don't actually have to provide an interface that can be easily mis-used. An interface like this could just as easily be based on some other data type besides a plain string, completely side stepping issues caused by concatenation. "What on earth are you talking about?" - Let me explain...

He goes on to talk about more specifically about SQL injection issues (it is still first on the OWASP list after all) and makes a few suggestions to a better API. He points out a lot of it is about little or no education on security-related topics. He also suggests a "SafeSQL" kind of interface that would help prevent some of these common issues using something like Haskell.

0 comments voice your opinion now!
sqlinjection sqli exploit library haskell

Link: http://codeutopia.net/blog/2013/08/31/library-author-dont-provide-an-exploitable-interface/

Greg Freeman:
Steps to Take When you Know your PHP Site has been Hacked
March 07, 2013 @ 09:53:02

Greg Freeman has posted the second part of his "hacked PHP application" series (part one is here). In this new post he looks at the aftermath - what to do and check to do cleanup and fixes so it doesn't happen again.

This is a follow up post from my previous post "How to Tell if Your PHP Site has been Hacked or Compromised". This post will discuss some the first steps you should take when you have identified that your site has been compromised. The first sections discuss a few points that are not relevant to everyone, the later sections will discuss how to fix the exploits.

He includes a list of things to think about including:

  • What kind of hosting you use (and if that contributed)
  • The option to redirect all requests for your site to one page
  • Get a list of all PHP files to locate something malicious
  • Locating "non-PHP PHP files"
  • Finding files with possible malicious content

He also includes a few suggestions to help prevent issues in the future - update to the latest versions, patch your code, rethinking your permissions and monitoring for potential repeat attacks.

0 comments voice your opinion now!
hack compromise steps correction fix upgrade exploit


DevShed:
Hackers Compromise PHP Sites to Launch Attacks
December 18, 2012 @ 12:07:35

According to this new post on DevShed, there have been several targeted attacks against U.S. bank websites (DDoS), some of which involved the compromise of PHP-based applications.

Once the hackers got into the PHP-based websites, they inserted toolkits to turn them into launch pads for their distributed denial-of-service attacks. Hackers then launched the attacks on banks by connecting directly to the compromised PHP-based websites and sending them commands, or took advantage of intermediate servers, proxies or scripts to make the websites do their bidding. InformationWeek lists three attack tools used by the hackers: KamiKaze, AMOS, and the "itsokaynoproblembro" toolkit, also known as Brobot.

Several major banks have been targeted including Bank of America, JP Morgan/Chase, HSBC and Well Fargo. The main problem was out-of-date software running on the site containing known security issues the attackers could exploit to install their own software.

If a hacker can break into a PHP-based website to use it as a staging area for an attack on a different website, they can also use that website to store stolen information. InformationWeek cited the example of the Eurograbber attack campaign, revealed earlier this month. The gang involved in that campaign stole $47 million from more than 30,000 corporate and private banking customers - and used PHP-based websites into which they hacked to store stolen information.
0 comments voice your opinion now!
hacker bank website exploit attack timthumb joomla wordpress


PHP-Security.net:
New PHP-CGI Exploit (CVE-2012-1823)
May 04, 2012 @ 08:24:44

The PHP-Security.net site has two posts related to the recently discovered bug in PHP (hence the new versions) related to the CGI handling in certain server configurations.

In the first they detail more of what the bug is, how it could be exploited and link to the original advisory for the problem. Also included are more details on the issue, including sample avenues of attack.

In the second post they look at the recent PHP release and note that it does not completely rid the language of the problem. They point out that the Rewrite rule that's included in their post (not the one on PHP.net) should be used to prevent this issue from effecting your installations.

0 comments voice your opinion now!
exploit cgi release security rewrite rule modrewrite


PHP.net:
Security Notice (wiki.php.net)
March 23, 2011 @ 10:43:05

On PHP.net there's a quick security advisory for those that didn't see the news - the wiki.php.net machine was compromised but has been wiped and all accounts reset and requiring a password reset.

The wiki.php.net box was compromised and the attackers were able to collect wiki account credentials. No other machines in the php.net infrastructure appear to have been affected. Our biggest concern is, of course, the integrity of our source code. We did an extensive code audit and looked at every commit since 5.3.5 to make sure that no stolen accounts were used to inject anything malicious. Nothing was found. The compromised machine has been wiped and we are forcing a password change for all svn accounts.

The issue was caused by a combination of a problem with the wiki software and a Linux root exploit. The Register has additional comments about the issue and outage.

0 comments voice your opinion now!
security wiki compromised linux root exploit bug svn password


Community News:
PHP Remote Exploit - Floating Point Issue Causes Freeze/Crash
January 06, 2011 @ 08:06:31

As reported by both The Register and Zend, there's a new remote exploit bug that possibly has something to do with the way 32-bit processors handle floating point numbers.

From Zend:

Due to the way the PHP runtime handles internal conversion of floating point numbers, it is possible for a remote attacker to bring down a web application simply by adding a specific parameter to a query string in their web browser.

The bug, found here on bugs.php.net, has been reproduced on Windows and 32-bit linux systems and can cause the server hang and/or crash as a result. The real issue comes from this bug on the x87 FPU design. The bug has already been fixed in the latest SVN versions (including 5.2 that was end-of-life recently). A release to fix the issue should be coming shortly.

0 comments voice your opinion now!
bug crash exploit floating point remote svn


Stefan Esser's Blog:
Some facts about the PHPList vulnerability and the phpbb.com hack
February 06, 2009 @ 08:44:25

Some of you might have heard about the hacking of the phpBB.com website earlier this week. Well, Stefan Esser has posted a bit more about the vulnerability in the PHPList software that lead to the problem.

A few days ago phpbb.com was hacked through a super-globals-overwrite vulnerability in PHPList that was used by an attacker for a local file inclusion exploit. Details about the whole attack, written down by someone who claims to be the attacker, can be read here.

Stefan talks about the superglobal problem PHPList had - allowing the superglobal information to overwrite the variables inside the script without so much as a check. Example code shows how it was possible for the attacker to provide their own configuration file value to be opened via a stream wrapper.

0 comments voice your opinion now!
vulnerability phplist phpbbcom hack exploit superglobal overwrite


GNUCitizen.org:
Reviewing Practical PHP Exploitation Techniques
April 04, 2008 @ 12:09:22

From the GNUCitizen blog, there's a new post about a recent meeting (of the OWASP London Chapter) where several presentations were given on methods for exploiting PHP applications. The three talks given were:

  • Rodrigo Marcos - hacking PHP sockets for fun and profit
  • David Kierznowski - exploitation techniques using real world examples
  • Colin Watson - talk about security badges

There's links to the slides for one the formal presentations, the exploitation techniques - two sets: the remote exploit examples and local exploit examples.

0 comments voice your opinion now!
practical exploit example talk slides owasp


Gareth Heyes' Blog:
Exploiting PHP SELF
January 14, 2008 @ 07:54:00

Gareth Heyes has a new post today talking about one of the vulnerable values in the $_SERVER superglobal - PHP_SELF.

I thought it might be a good idea to gather a few test cases demonstrating the problem. Why PHP allows these URL's is beyond me and it wouldn't take much work to filter out these malicious URL's in the PHP code.

He provides four test cases to show how simple it is to abuse - one using a HTTP header, another pushing XSS through, the third mentions search pages and the fourth a direct code injection.

You can download the code here.

0 comments voice your opinion now!
exploit phpself superglobal inject testcase security exploit phpself superglobal inject testcase security


Gareth Heyes' Blog:
Faking the unexpected
December 04, 2007 @ 08:36:04

Gareth Heyes has an example of yet another way he's seen developers incorrectly handle incoming connections and the information inside. This time, he focuses on the remote IP coming from the client.

Developers place too much trust in everything, they assume that certain data cannot be faked and therefore these pieces of data can be used as a Trojan horse. Lets take the REMOTE IP of a user, it seems a trusted source because of the TCP/IP connection between the user and the server.

He points out the difference between HTTP_X_FORWARDED_FOR and REMOTE_ADDR and how, despite them being the same almost all of the time, shouldn't be trusted since they could be spoofed. He even includes an example script showing how it could be done (and how a bit of Javascript can even be inserted).

0 comments voice your opinion now!
remoteaddr httpxforwardedfor remote ip address exploit remoteaddr httpxforwardedfor remote ip address exploit



Community Events





Don't see your event here?
Let us know!


threedevsandamaybe community series configure list laravel release library api podcast interview language developer code application bugfix introduction symfony wordpress install

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework