MalZilla

[Orac]

Downloaded the update yesterday, all seems to be working as intended.

Just used the FTP (on the three RFI links i posted earlier today) and it works perfectly.

Havnt got any new HTTPS links to test (yet), will report back on this aspect when i get one 

[Orac]

Possible bug

This link http://baptiste-bugnon.ch/help/ix.dat is a copy of Defacing Tool, the link to "//The Rules" want passed to the Links parser, neither was the link "<!-- saved from url=" at the top of the script.

[bobby]

No, it is not a bug, it is a feature
Malzilla does just what every webspider does - follow the HREF links.
It does not search for every link in the file. Links from textual part of file, links from comments and the links from scripts are not on the list in Link Parser.

I will now explain why is this done this way.
I DO have code that will catch every single URL, even from binary files, but this is far from perfect for HTML files.
Namely, most of the links in HTML files are relative paths (eg. "/images/image.gif")
Those would be missed by my other code that I have.
The current code in Malzilla is searching for every HREF, see if it is relative or absolute path. If it is relative, it search for Base tag (not necessary present in every HTML document). If Base is found, then the absolute paths are calculated relative to this basis. If Base tag is not present, the current URL (from URL box on Download tab) is taken as basis for calculating. See Link Parser tab, "URI base" field. If there stays "URI base (detected)", it means that the HTML contains Base tag. If stays "URI base (not detected)", it means that the URL from Download tab>URL box is used for calculation.

As an example, save any HTML page that does not contain Base tag in HTML header, and where some relative URLs are existing in the document.
Now open a new Download tab and load this document. Take a look at LinkParser - you will not have complete URLs anymore because Malzilla does not know the basis URL.
A solution is to save pages as 'Malzilla projects' (see Settings tab). This way extra info is added to every saved HTML page (does not destroy the page as the info is added in the form of comments). At loading such HTML in Malzilla next time, Malzilla will know the base URL, UserAgent and referrer used.

Now, I can add extra list in LinkParser that will contain all the links detected by a regular expression. That will catch every ABSOLUTE URL (relative URLs can't be found with such function), no matter if the URL is in comment or anywhere else in the document.

More info on Base tag:
http://www.w3schools.com/TAGS/tag_base.asp

[Orac]

Thanks for the explanation Bobby, iam surprised i hadnt noticed it before.

I can only assume this must have been the first time weve seen this particular exploit where the rules file hasnt been a HREF link, and as such the skiddie has in fact borked the script, which is meant to load that file as an add on to the scripts defacing abilities.

The particular link in this script has in fact been 404 for a couple of years now, which allways gives me a laugh, you would have thought they would check its availabilty before attempting to use the script for a RFI lol.

[sowhat-x]

Small glitch I've noticed in latest beta,not really important though...

1)Get the latest 'officially' released zip from sourceforge (0.9.3pre5) and extract it...
2)Extract latest devel/test build of malzilla.exe (overwriting the older one),
run it,then simply press the "Mini Html View" button...
"Cannot create file "C:\path-to-malzilla-dir\Cache\tempview".The system cannot find blah-blah..."

Maybe it should automatically create the "Cache" folder upon startup or something...

[bobby]

Indeed, Cache folder is created when you do the first download.
I'll correct this bug.

Thanks

[tjs]

ISC is reporting on some new javascript trickery:
http://isc.sans.org/diary.html?storyid=4724

Thanks,
TJS

[tjs]

Bug & Suggestions:

I think there's a bug in the latest beta build involving the Hex (%) decoder. The bug doesn't exist in older variants, and I was able to repro the issue on several machines.

Issue: hex encoded strings are not decoded properly.
Example: <script src=http://%7A%73%68%61%63%6B%2E%63%6E> decodes to:
<script src=http:?zshack.c6E>

This is incorrect. %7A%73%68%61%63%6B%2E%63%6E should resolve as zshack.cn.

---

Next, some suggestions for the decoder section-- i've started seeing some malware sites using various IP encoding schemes to obfuscate their payload addresses. They are simple to reverse, but it would be nice to have one built into malzilla. Here are some examples:

hex IP encoding
Octal IP encoding
DWord IP encoding
Hybrid encoding (have fun!)

Here are some examples:

http://207.46.197.32
---------------------
http://0xCF.0x2E.0xC5.0x20
http://0317.056.0305.040
http://00317.0056.00305.0040
http://3475948832
http://7770916128
http://12065883424
http://16360850720
http://0xCF2EC520

I can help you with the calculations if you aren't familiar with this stuff...

Great resouce: http://www.searchlores.org/obscure.htm (not malware)


Thanks!!
TJS

[bobby]

Thanks for reporting the bug. It is indeed a BUG.
If you use Decode hex button - you see the bug.
If you use right-click menu > Run script (internal) > decode hex - it works like it should.
I'll take a look what I did wrong.

I'll also take a look at that IP encoding. Thanks for mentioning this, I have forgot about such IP encoding. I saw that kind of obfuscation only once, a couple of years ago, and I forgot about it.

[tjs]

My pleasure, friend.

[bobby]

After a lot of time...
http://malzilla.sourceforge.net/builds/

Please download updated files from this folder (you do not need to download the DLL files if you already have them, these are not updated).

Changelog:

Bugfixes:
- Misc Decoders rewrite
- Cookies tab (in Download tab) fixed. It does not mix cookies from various tabs anymore
- Hex vies (in Download tab) fixed. Does not show wrong data (from wrong tab) anymore
- improvements in Mini HTML view
- other that I already forgot

Additions:
- new tool on Tools tab - IP converter (see TJS' post)
- decoder Templates

Decoder Templates are code snippets to be added to script before decoding. Some of the variables from snippets will be automatically replaced with values from Malzilla. See Docs folder, there is a list of variables that would be replaced in templates with values from Malzilla (e.g. malzilla.location.href will be replaced with the content of URL filed on Download tab).
This should help a bit at deobfuscating scripts that are using non-trivial DOM objects.
More templates to come.
All the templates need to be in Templates folder if you want them to appear on the list of templates.


So, if everything goes fine, this will be Malzilla 1.0

Things that are not implemented (and probably will not be implemented because of complexity):
- downloading from FTP on Clipboard Monitor tab
- multi-language interface (we have started this once, but it takes a lot of time that I do not have)

[MysteryFCM]

Nice one dude

[MysteryFCM]

Bobby,
Malzilla doesn't seem to detect the iFrame SRC's for the links or iFrames tab for the following;

http://www.sanseng.com/eng/Product.asp

/edit

My bad, forgot to click to send to links parser hehe

[tjs]

The 'IP converter' tool is excellent!! I really like the UI. I'll do some deep testing later on and let you know what I find.

TJS

[CM_MWR]

Reply #178 on: August 12, 2008, 12:53:41 PM »

I'll do some deep testing later on and let you know what I find.

Spec tjs got into some pretty deep shit,eh?