Miva, Miva Script, Miva Empresa, Miva Mia amd Miva Merchant are registered trademarks of the Miva Corporation
 
Ivo Truxa - truXoft control systems: advanced programming and custom IT solutions home / about / webdesign / Miva / automation / contact

http://mivo.truxoft.com
MIVO!
miva beyond limits

 

MIVA®  SECURITY: Insecure Miva Templates #1

by Ivo Truxa, 03/12/2000

Form macro attack / URL macro attack / MvCALL DoS attack

Miva templates were developed long time ago and probably never redesigned with an eye to their security. I did not have time to look at them closely, but in a very quick check I found many vulnerabilities.

Generally, scripts of all of us contain such vulnerabilities. It is difficult to write secure code, but it is rather easy to find some hole in almost any script. As far as nobody can see the sources, there is not too high risk. In the monent you want to publish your script, you have to crosscheck it perfectly!

Many v-domains have the templates available online. And of course, anybody can access almost any Miva developer who runs Mia without a firewall on his/her machine and very probably did not bother to remove the templates.

I know that I will receive angry letters telling me that I publish instructions for hackers. Well, me too, I hesitated long time before doing so, but more and more I see how carefree newcomers to Miva are. They need to be warned. If they do not see how easy it is to break in, they will never understand. In the days I write the article, Miva Co. works on fixes and I hope for an alert being sent in the very few next days, before I publish this article.

Here is the first example:

Form Macro Attack
in the dissectsite.mv and analyzelinks.mv scripts

The design of this script template is in variance with Miva's own instructions: Security issues with macros.

A visitor can open the dissectsite.mv or the analyzelinks.mv template and enter the following line instead of a URL in the form:
<MvEVAL EXPR="{mivaversion}"><MvEXIT>
Getting back the engine version number? OK, it works!

He could easily inject any other code, inclusive SMTP, POP, file system or any other Miva functions! The best to do for everybody's sake would be:
<MvEVAL EXPR="{schmod('path/dissectsite.mv',777) $ sdelete('path/dissectsite.mv')}">
Just need to guess the right path from the URL.

Maybe this one would be even better:
<MvEVAL EXPR="{schmod('/cgi-bin/miva',777) $ sdelete('/cgi-bin/miva')}">
I did not test it, but I suppose it would work on many systems. Afterwards, if the server does not return a 500 error code, everybody could grab all Miva scripts in clear text.

And better: a simple Miva script to upload the original Miva binary with a Trojan horse attached. The code would not take more then few lines. I did neither try this one but I believe it would work as well.

An intruder can replace victim's htaccess or htpasswd files, redirect his URLs to other ones, use POP and SMTP to relay e-mail, read or delete or replace databases. No limits for fantasy!


Take Care!


top

   

Miva and some other terms used on this page are registerd trademarks of the Miva Corporation
copyright  truXoft  © 1997-2008