A new vulnerability has been exposed by Artisan system, they have since removed this blog posting so I’m reposting it for those curious of the details of the exploit and how to correct the problems themselves, since all Varien is offering for a temporary band-aid over the problem is a simple change of admin URL.
There is in fact some discussion in the community of resolutions to the issue, and also some others offering a solution to fix the exploit until Magento can release a new version to fix the issue in an official release.
Here is the original post from Artisan system detailing the exploit, that has now been removed (possibly temporarily). I am not offering this as means for people to exploit the issue but to better help store owners and their developers fix the issue themselves!
It’s not often that you’ll find me disparaging the work of other developers. I realize the hard work and effort that is put into developing a large scale website. Unfortunately, there is a security vulnerability in Magento Commerce in 1.2.1.1 (and previous versions) that I believe should be fixed before anyone else uses it.
Magento Commerce has been criticized in the past for being too bloated. I agree it is. A single, uncached page load takes as much as 20MB of memory, which is a bit much for a web application. While Magento can be criticized for being too bloated, many other popular apps are bloated, and that bloat can generally be solved by server tuning and hardware. The issue of Magento extends further to a much more important issue: security vulnerabilities in the administration panel.
The problem starts with an attack called a cross site request forgery, or CSRF. The brilliance with this attack is that the person executing it is generally unaware and an authorized user of the website, and thus, the web software has no way to stop the actual actions from occurring.
The attacker will generally use more social engineering than actual coding/cracking. First, I’ll explain how the request forgery works and then how to fix it. The cracker installs Magento on their own system. They configure it properly, set them self up as the administrator, and create a fake order so they receive the layout of the email the administrator receives when a new order is created. Next, the attacker creates a real order on the system they’re looking to attack. With that, they’ll get any modifications to the order email (albeit’s the customer’s email, they’re checking any major color changes, font changes, etc). With this order email, they now have the email address of the administrator of the site.
With this knowledge, the attacker has enough information to execute the attack. The attack lies in the
fact that the administration panel of the Magento installation allows you to execute CRUD (more importantly,
the CUD) – Create, Read, Update, Delete – actions through a GET request rather than a POST request. Using Firebug with their own installation, the attacker can easily find the URL to, for example, duplicate or delete a product.
*** REMOVED TO PREVENT EXPLOITS ***
Copying one of those URL’s and pasting it into another tab will cause the action to execute! This is where the source of the problem lays. Actions such as Create, Update, and Delete should always happen through a POST request, not a GET request. If they must happen through a GET request, an interstitial page is necessary to confirm their actions.
The Attack
The attacker now has everything they need: new order email, administrator email address, and
sample URL’s to attack. Here’s what they do:
- Create a simple HTML page on their website that when accessed, draws a hidden
IFRAME with the SRC attribute being the URL of the attack you want to execute. For example,
if you want to duplicate a product, the page could be as simple as:
-
1
| <iframe src="http://mymagentosite.com/index.php/admin/catalog_product/duplicate/id/1" style="display: none"></iframe> |
- and installed on http://badsite.com/crack_magento.html
- Then, through the use of a phishing attack, sends an email to the administrator
masquerading as a legitimate new order email. If the attacker sends this in the morning,
chances are, the administrator will already be logged into the backend of the website processing legitimate orders, meaning a session
has been authenticated for them. The phishing email looks nearly identical to their emails they
get regularly, and the administrator clicks on the link to go process the “new order”. In reality,
because the email’s are HTML emails, the value of the link is different than the HREF. The administrator
clicks a link they’ve seen hundreds of times before, but instead of going to the website, it goes to the
page on http://badsite.com/crack_magento.html
- Because the administrator is already authenticated, even if this link opens in a new tab or even window,
the action will be allowed to execute! With that, they’ll automatically have a duplicate product on their store!
Deleting a product works in the same way.
- Even more frightening, the attacker could easily update the crack_magento.html page to use a loop
in JavaScript to continually draw a hidden iframe 100 times to create 100 duplicate products. As a result of the
size of Magento, this can do several things:
- Create 100 products that are duplicates and erroneous.
- Cause the server to fail under the load of continual requests.
The Fix
Surprisingly, the fix for this is simple.
- ALL Create, Update, Delete requests must come from a POST request.
- A same domain policy is created to only allow POST requests from the website Magento is installed on.
The checking for this would happen before the rest of the page content is loaded, requiring very little overhead:
-
1
2
3
4
5
6
7
8
| <?php
if ( 'POST' === strtoupper($_SERVER['REQUEST_METHOD']) ) {
$this_domain = get_this_raw_domain(); // Would return something like mymagentosite.com
if ( $this_domain != $config['site_domain'] ) {
exit('Hacking attack!');
}
} |
- Of course, the above code is a proof of concept, but would be fairly simple to implement in Magento (or any site).
- On some forms, a hash value is in a hidden form field and this is checked against the session. This should be updated
to have a random has generated on each page load in a hidden form field. The same value is stored in the session. On each
page load, this hash is recreated. Next, a static hash is created when the administrator logs into the site. On each page
submit, the hash from the form and the hash from the session are checked. If both of these are the same, the request continues.
- Add a secret PIN to the subject of all emails coming from the store to the administrator. For example, if the administrator
set his PIN as 82799, that value would appear in every subject of every email to him from the store. Because he’s the only
one who knows the PIN, he’ll know the email is legitimate.
Conclusion
An obvious question is why would someone exploit this? This is the wrong question to ask. People do amazingly cruel things for no reason whatsoever. The question should be, “what is the attack and how do I fix it?”. Although duplicating a product is something that’s a minor nuisance, my fear lies in that if something as simple as a cross site request forgery attack is not caught, where else are major security vulnerabilities present? It is not my point to discredit or disparage the Magento developers as I believe Magento has a chance to be a great product. However, security vulnerabilities such as these are bound to be exploited. I urge you to speak with the Magento developers to ensure this will be fixed immediately.
Possibly Related Posts:
This fix didn’t work for me after further testing on 1.3.2.4 another recommended fix has however worked. 
Magento – Issue List – eCommerce Software for Growth.
