Site to test HIPS ?

If Virus Total or Jotti deliver a clean report about the uploaded file that doesn´t mean I will trust the file.

1-Upload the files to VirusTotal or Jotti.
*If the report says infected/suspicious, the file is rejected.
*If clean, follow the next step.

2-Open the files in Open Office using Linux.
*If strange behaviors are detected, the file is rejected.
*If clean, follow the next step.

3-Open the files using Open Office / MS Office in VM.
*If strange behaviors are detected, the file is rejected.
*If clean, the file is opened/executed in a virtualized enviroment (GeSWall).

 

Hi Mrk,

See:

Microsoft Security Bulletin MS06-060
http://www.microsoft.com/technet/security/Bulletin/MS06-062.mspx


regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Hi lucas,

Why not just save time and go directly to your step 3?

It sounds like an ideal solution.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Because step 1 is almost always very fast and step 2 and 3 are quickly made (switch between WMs).
Perhaps I´m a little paranoid

 

Well, we've ventured away a little bit from the original topic, and I was going to lead into some other tests and sites, but I see the original poster wants "clean" sites.

One exploit I've searched in vain for is a real MSWord exploit file. Anyone know of one?

All that I've seen is the PoC referenced a while back at sans.org. Has anyone tested that with a HIPS product?

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Maybe it would be for a new thread, with the DSA and Spyware Terminator results included, but it would be interesting if others who run HIPS programs (SSM, Prosecurity, etc) to test against the Spycar, APT and RegTest to see how they do. So far DSA passes all tests in Spycar and APT but performs poorly in the RegTest. Spyware Terminator with Realtime Shield and HIPS activated performs well in the Spycar Autostart tests but poorly in the IE Config Change. Also ST performs exceptionally poor against the diamondcs.com APT but has some success in the Ghost Security RegTest (although Ghost claims it failed).

 

It's somewhat of a truism that if the exe doesn't start it can't do anything.
The assumption however is that you already know the executable is dangerous, this is not always the case.

What I disagree is people who say "My setup is immune to problem X", and their proof is that they click on the exe that tests problem X, HIPS prompts that X is starting and don't even allow the exe to start.

But this is silly, because since you already know it was dangerous, you might as well not click and start the exe in the first place. What does your "test" tell you except that the HIPS function of alerting on unknown processes is working?

But the test was not a test of its ability to evade what Rmus calls anti-executable , so you learn nothing by not even allowing the test to start.

Also in practise you can never know for sure if the exe you allowed to run is really a trojan horse, that's where other aspects of HIPS comes in.

I think most people would disagree with this statement. You (and Rmus I think) seem to think HIPS is simply the function of whitelisting processes and blocking unknown. That's an overly limited view.

You might be happy with just that, but if HIPS was simply that it would be of very limited use to the average person, Who needs someway to determine if something they are running or going to run is likely to be malicious.

 

Excellent point of view. My post #10 more or less concurs with your statements. However, you can be pretty much 100% sure the executable is trusted if you obtain it from a known, trusted source. I would not download, for example, mp10setup.exe from Warez 'R Us, nor would I accept it as an email attachment from anyone. Rather, I would download it from Microsoft. That goes for any and all software I download. I would say those who open email attachments willy-nilly and routinely download and run cracked software are at greatest risk.

 

Hello,

lucas, I see we rather quite agree on methodology ...

Rmus, I'm not worried about exploits in Office per se, because they are many alternatives, I'm talking about general approach to files from people whom you must interact - mainly docs, ppts and pdfs. OO / Linux is a fine approach, especially for one using them already! Skipping over 2 to 3 is viable, but then VM can also be installed on Linux, which makes it even more fun!

Mrk

 

A few years ago I adopted employing multiple task specific computers
the workstation wasnt even hooked full time to my LAN and was a www virgin.

I relied on W2K hardening, policies, AV, HIPS, and Filechecker for my lesser boxes (900MHz > 1.2GHz) as surfboards.

But with virtualization\sandboxes Im rethinking the whole game, its a bit much for those old boxes, but I deflowered my workstation about a year ago and in the last few months have started to employ VMware\Sandboxie.
But its pretty obvious Im not thinking in that groove yet.

Ive also acquired an new standalone 3.06GHz surfboard though it could stand having its RAM upped. Looks like its time to find other duties for the old hardware.

 

1. You download and run the leaktest under the assumption that it simulates malicious actions and therefore premeditate your actions: click "Block" to any and every alert you see. This is not, in any way, representative of a real life situation. There is no guarantee that you'll click "Block" to anything, especially not anything meaningful.

2. Behavior blockers rely entirely on you, your knowledge, and your decisions. This is something that keeps getting overlooked or taken for granted as not applying to anyone here, but is something I think should really be seriously considered. Would you apply for a malware analyst position with your current level of confidence in your ability to pick out malware from legitimate files? Just becuase you know what should be running on your system doesn't mean that a new file isn't legitimate - even if unexpected. With that in mind, the only way to truely "test" the effectiveness of your behavior blocker would be to test your own ability to distinguish legitimate files from malicious ones, and if you can distinguish a malicious action from a legitimate one even when they are exactly the same action being performed by exactly the same process. Also consider the "chicken little effect" - how many false positives do you tolerate before you stop taking those prompts seriously?

3. Such tests perform a single action. An application that takes only one single action that a behavior blocker may or may not monitor is more representative of a legitimate application than a malicious one. These actions are legitimate resources offered by the operating system for legitimate applications. They are mostly documented and supported programming functions available for any and all software to use. Single actions will also give you no way of predicting whether the behavior blocker will block malware, since malware may not utilize monitored actions.

4. Actual malware takes many many many actions to infect a system. Just because a program does not stop a single action does not mean that it's not effective. The software you are using may address the malware problem at a completely different point than what the leaktest (or other test file) is meant to test. In such a case, calling it a "fail" would be not only meaningless but naive to the point of absurdity. An example would be a script filter. If you download pretend malware and say it "fails" [to protect you] because it didn't alert to the intended action, this would be completely missing the point that the program is meant to stop the file from downloading, not what programs do that are already downloaded.

5. Leaktests and test files are mostly made by commercial entities for scare tactic marketing. These tests are specifically made to show off a single (or small number of) feature(s) unique to that vendor's product. Read that again - that file is made specifically to bypass most or all other products as a way of scaring you into thinking that you need to give that vendor your money to be protected. This also goes into number 3. Just because a product doesn't contain a specific feature does not render that product ineffective within it's scope of protection. What is actually more important is to know what that product does, how it does it, how that relates to malware, what kind of malware that relates to, and how prevalent that malware is. Without knowing those things, you will have no way of knowing how that program could protect you, and certainly not how "well" it can protect you in any meaningful way. Also ask yourself whether you really want every product to incorporate every other product's features. Not only would that lead to bloat and a maddening flurry of prompts every time you try to do anything, it would quickly render them all useless as malware writers simply avoid using those techniques, or at least use techniques to evade them.

6. The real tests of those features are not contained in commercially made leaktests and other test files. The real test of those application's functions are performed by security researchers that know programming. I don't recall ever seeing a test file that uses symbolic links, for example, to see if your behavior blocker recognizes them. These are a greater threat, since not everyone on these forums use them as buzzwords. Better to do some reading up.

7. The point of behavior blockers is to block new malware that is unknown to your other security software. How do you calculate the effectiveness of malware using new evasion techniques that haven't been discovered yet? How many people will be infected before the application is updated, or will it even be updated (is the problem within the scope of protection for that application)?

8. Even if you do block each and every action that the behavior blocker monitors, how many other actions would the malware take? No behavior blocker could block 100% of them, so what are you left with? Considering that there's virtually no end to the possibilities, you have to consider that a new technique may be employed to leak your data, so how does the behavior blocker account for that, how much additional damage can be done?

9. Building a defense generally consists of assuming that any given application can and will be bypassed so that you can narrow down the potential damage to an acceptable level, knowing that 100% security is not possible. How will you react if you do end up infected, and what role does the application play?

I've posted most of that before, but there's a few new ones in there I'm sure I could think of more, but hopefully that should be a good enough start. Answering those questions for yourself will give you more answers than test files ever will. Yes, it's much easier to just run a file and receive a prompt that says either "Pass" or "Fail", but for those to be meaningful in any way depends on a whole lot of things and be performed in a meaningful context (which I have never seen). If you don't know and understand what those things are, then you're easy prey for marketing goons- any company can come up with something that will tell you that you're insecure unless you are using their products; they're all over the web by both legitimate and illegitimate vendors. As far as I'm concerned they're all the same since they all want you to see the answer in black and white terms: "pass vs fail" or "secure vs insecure". Even if you use live malware to test, most of the above still applies. You're still running it knowing full well what's going to happen, it's still out of context, there's still additional actions that can be taken, there's still the question of how common that malware's techniques are, there's still the question of yet unknown techniques, etc etc etc. The only way to assess the effectiveness of a behavior blocker is to know the facts.

Knowledge is the only true way to secure your system beyond a strong but basic set of applications. Armed with knowledge, you won't need any more.

 

I was careful to state in my post #5,

 

acr1965: People have tested sites until they are blue in the face, but they still have a lingering feeling that they are missing something.

In your post #31, your results illustrate this. How will you make your decision? I don't envy you.

Notok: very nice write-up.

Regarding 1.and 5. (Leaktests):

Robin Keir, author of Firehole (dll injection using the Win32 function SetWindowsHookEx)
http://keir.net/firehole.html

Two logical questions arise:

1) How do you stop this from "getting onto your system and executing?"

2) What if it does get in?
​

Taking the second question, "What if": I'm reminded of two visitors to a canyon overlook. One observes that the other has climbed over the guard rail to get closer to the edge for a look. Upon climbing back, he asks the first,

"Where is your parachute?"

"Why do I need a parachute?"

"What if you fall over the edge."

"I'm not going to go on the other side of the guard rail."
​

To carry over into the computer world,

"Where is your ______ (fill in the blank) to stop the dll injection?"

"I'm not going to let anything install that would do that."
​

For the first question, How can I prevent that?

There are two common ways firehole (or to update: any current trojan) could install.

1) surreptitiously, via remote code execution (iframe, .wmf file, etc): Easily blocked

Here is a current one

2) piggy-back as part of another program. I realize I'm in a minority here, but being aware of what I install has been my guide.

I'm asked,

"How can you be sure?"

"I'm just sure."
​

It's curious, I've gotten a number of PMs during the past year from people telling me how they downloaded/installed/gotten infected by this or that, -- By PM because they didn't want to discuss how it happened on the forum -- and what if that occurred to me? I respond, that it wasn't something I would ever download/install. So why should I worry?

To quote again my favorite quip,

"Just because Mr. Smith's shoes are too tight, why should my feet hurt?"
​

In every case of a reported malware infection at Wilders and DSLR where I've been able to ascertain how it happened, (not always forthcoming from the victim) it's a situation that could never have happened to me or anyone that I've been involved with in computing.

It's been said on these forums that people need a way to determine if something they are going to run is likely to be malicious.

If this refers to some type of program, then it's a lost cause because there has yet to be developed a reliable, trustworthy application to do that in all cases.

I submit that one's own good sense and careful habits are just as reliable, as I have proven for myself and others over many years. And as some here (in the minority) have also stated.

How? It has to do with your comment about knowledge, which is so pertinent. So, How do you make a computer user "knowledgeable?" And what does this "knowledge" consist of?

Big questions, with no simple answers, because you are dealing with states of mind.

When Bruce Schneier's book, "Beyond Fear," was released in 2003, I made a note from a review:

I no longer recommend security setups without seeing first hand the system and how it is used - the user's computing routine. Because I'm convinced that the first step in a "practical approach to problem-solving" is to understand what the problem is - *problem* being, addressing the user's security needs - beginning with the user's state of mind: fears, anxieties - most of which are influenced by the media.

I love working with the complete beginner: She/he has no bad habits, misconceptions (or fears) to unlearn. I've maintained contact over the years with several home users whom I've helped - who started out as beginners. Ask them what these terms mean: HIPS, rootkit, hook. They would respond, "Huh?"

Are they -- just average home users -- not "with it" because they don't know these terms?

Yet they've never had a virus (that term they *would* recognize, since it's so commonly used in the general media).

I realize that it's difficult to imagine that everyone could have "hands on" help. But as I've advocated in the past, why not "adopt" a user? If not a beginner, one who perhaps has had a bad experience with a virus, and who agrees to listen to you.

There will always be those who will climb over the guard rail, but they should be left to their own devices, search for their parachutes, and reap their own rewards.

I'm more interested in those who really would appreciate some help with the basics. Certainly each person here knows someone like that.

Develop a teaching plan: "introduction to computer security." Where would you start? Make a list of products people should install?

Or thinking through how you would teach someone to be a safe, knowledgeable, and secure computer user, and from that basis, developing a layer of applications that meet her/his needs. (Many ways to approach this, but that's for another discussion)

Just think, that if everyone here "adopted" just one person - how many more knowledgeable computer users there would be. Time consuming - yes, but we can always find time to help someone. It's not only been rewarding in knowing I've helped someone, but I've always learned a lot from the experiences.

How much more useful than jumping on the doomsday wagon, which has already started its forward march into 2007 with its lists ad infinitum of predictions of worst case scenarios.

Take a stand: step out from the crowd and be separate. Help do something about it!

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Hello,
Rmus, nicely said.
Mrk

 

elaboration of the points

no, but then as mentioned I do know which are the legitimate aps and anything new is easily researched, its always been a matter of trust and experimentation, which is why there is a box specifically to try things out. What trips most people up is ignorance of an infection vector and experimenting within thier core systems rather than their disposable installs. Even if you don't run multiple boxes, sandboxes or virtualization its what 6GB for a dual boot? Which likely would break most malware attempting to infect the second install.

reimage to a known secure state \ tripwire
(or at least a state with a high confidence level)

 

Hello,

(emphasis is mine).

This word "mostly" is the key word here. Personally I'm not talking about leaktests to scare people, as it's written in my website FAQ, but instead to help everyone testing and adjust it's security (often "failing" a leaktest is simply a matter of incorrect software or OS configuration).

I try to do my best to highlight the fact that leaktests are meant (from my point of view) to help you securing your computer and see by yourself that none product can protect against everything. Leaktests are often associated to evil marketing scare tactic, I'd like to say otherwise as they are also used with good intent in mind.

That being said, I woud like to recall one page I've done to help people securing their computer, as well as a PDF document to secure Windows :
http://www.firewallleaktester.com/advices.htm
http://www.firewallleaktester.com/docs/Securing Windows.pdf

I cannot prevent you to still hate leaktests or people creating them, but at least I can show you good things coming from them

While I'm here, happy new year

Regards,
gkweb.

 

1. I generally supply a list of classes of applications with examples

2. Generally refer them to this tutorial

well one way allows you to make a lot of money and manipulate society
the other allows you address the problem. and of course isnt limited to computer security

of course when the problem is itself ignorance, it may be the first step towards a solution. It does however require a transition from the sky is falling to rational assessment. But when the sky is falling message is repeated again and again its the boy that cried wolf, and looses all legitimacy

 

Hello,

Very well said, gkweb.

... Do not rely exclusively on your software firewall for protection from these kinds of vulnerabilies.. Try to catch the threats before they hurt ...


And one more thing that I personally love:

... There are also software-based NAT routers like Microsoft's Internet Connection Sharing and Sygate's SHN that do the same thing if installed on a home computer that serves as a gateway to a small number of other PCs on a home LAN ...

Cheers,
Mrk

 

Indeed, and your site is actually one that I consider to be in proper context with leaktests, which I had forgotten about while writing my post... that is as long as they read the other stuff, which you have now taken steps to ensure they do So no disrespect to your efforts in any way, what I don't like is people judging the effectiveness of behavior blockers with various demo trojans, mostly made by other commercial entities, without consideration for what the program actually does.

Ice_Czar: Indeed, and thanks

Rmus: Hehe, the example is a good one. I definitely agree with your points.

 

But you don't 'prove' that part of your HIPS is working okay, by clicking on some random exe and clicking no.....

If you want to argue that leak tests or test demos are pointless, you could argue as Notok as argued that you wouldn't know it's malicious so you wouldn't block it.

The irony is, this argument is actually the same one that can be used against people who think they are safe because they click no to a program starting when they wouldn't necessarily know it's malicious in real life.

Depends on what you mean by reliable and trustworthy. If you mean 'perfect', no such beast exists. But surely no one is asking for that.

I find it interesting that while Notok and Rmus unite in declaring the uselessness of test demos, leak tests whatever, you two seem to have quite different reasons for doing so.

Rmus I think believes that there is no reliable way to determine if a certain software is malicious if you choose to run it and hence it is a matter of trusting the right sources to download from, common sense etc.

Notok the representative of Prevx1 obviously feels otherwise, because that is after all what Prevx1 is about. Notok is more about failure of knowledge to responding to prompts hence the need for Prevx intelligent design making heuristics or something.

Or have I misrepresente the positions of either of you?

 

Where? You have to point them out for me. Seems like the same old arguments.

Aren't you arguing above that nobody except for bona-fided malware analysts (which would presumably exclude even you), would have a chance of figuring out things? Does that mean everyone is easy prey?

Definitely the result isn't as important as knowing what is happening.

What facts? You already made a big point of showing that probably nobody knows any facts e,g how common the technique is etc See #7

symbolic links? I'm sure i mentioned that before.....

 

Hello,

Determining what an application does? It's not difficult but it can take a lot of time. And people do not wish to spend hours trying to reverse engineer an application. They want it plug and play.

In this regard, the best approach is probably combined:

1. If you do not trust the source - don't run it.
2. If you supposedly trust or must use a file - a work colleague, for example - then you can try simulated behavior, like VM or test computer or external forensics via live CD to try to gauge the symptoms.

But if there's a doubt, there's no doubt.

Mrk

 

Let's think about these statements for a bit...

Is it realistic to assume that even a small fraction of folks frequenting this site could reverse engineer an application? Let's say they get their hands on a disassembler - will they actually know what to do or look for? Look at the basic unit operations of a good application versus a malicious application - do they really differ to a level that is diagnostic? In some cases, perhaps, but in most instances I'd say no.

The unit operations of malicious applications are not that unique. They differ in objective (measures taken to preserve the infected state via autostart entries and multiple processes monitoring/restarting each other) and degree (dominating CPU and I/O), but not really kind. For most users the only signs of an issue are indirect - say a slowly responding machine or abnormal spikes or levels in traffic. That can be enough to aid in assessment, but at that point it is a post-mortem, not an a priori diagnosis

As for some of the comments above such as:

isn't the answer transparently obvious, even for advanced users, at least with respect to a direct assessment?

Blue

 

Hello,

Blue, I take my statement back. I should have been more clear. Reverse engineering - behavior like rather than low-level hacking, which could also be quite illegal. Observing an application through a series of nets and filters, including disk operations (read, write), including Windows-specific tasks like autostart entries, registry etc, memory operations (read, write, execute), process injection, and so forth. Then comes the network analysis, using in-system and external diagnosis (from another computer or through a firewalled gateway). This requires quite a bit of tools, including registry, file, disk monitors, packet analyzers, most likely virtual or sandboxed environment.

For the average Joe, even if he were given all the applications needed to do all the forensics, 99.99999999999% would refrain from doing so and simply trash the suspect. It just isn't worth it. Hell, it's dirty and boring and long. No one would do that just to decide if he should run a simple browser.

It's definitely doable but far from practical. Most people will use behavioral, indirect indications - as you mentioned - rather than go by brute force code line-by-line examination. As to the behavior, skill and knowledge really hold sway.

Finally, the issue of probability. For most purposes, good advice and use of trusted source is enough, like DA said.

Mrk