outpost 3.5 auto rule creation

The new auto rule creation feature which is only an option and can be deactavted. Seemed like a crazy idea to me as soon as i see it, as known process like msn firefox explorer etc are auto allowed access.

How is outpost deciding that this is the real msn or real firefox.exe or real explorer.exe requesting access

With this option enabled outpost fails the Atelier web firewall tester on test 3, auto creating a rule for explorer.exe and allowing a webpage to be retrived.

With the auto rule feature turned off Outpost detects test 3 as explorer.exe being modifed, and the point is awarded to Outpost for blocking the webpage.

I went on to rename a few trojans to explorer.exe and firefox.exe and sure enough auto rules were created for them and they were allowed access as if they were the real deal. .
What were the outpost gods thinking of when they included this feature!!! turn this feature off if u use outpost 3.5 or are thinking of using it

 

Are you using the latest build 3.5.641.458, as the bug with auto rule creation was fixed.

 

yep im using 3.5.641.6214 458 the bug or bugs are obviously still thier

 

Sounds like there's some kind of problem with Component Control. It ought to catch something like that I would think... And the auto rules creation should probably do some sort of checksum on the file in question too, shouldn't it?

 

Not sure about this but

normal component control does not seem to block this test - not tried maximum because PG takes care of this for me

 

I must strongly suggest that you go back to version 3 .0 . The latest build was rushed and is NOT ready for prime time . Agnitum , for whatever reason , wanted this version released , even though the problems were many and they knew about them . They pushed forward anyway . Beta testers had little say in this . Now it is wait and configure and hope it works each time you boot up . 3.5 will continue to be worked on but , 3.0 is your best bet .
Good Luck in your choice

 

I'm a moderator at the Outpost forum and have done quite a bit of testing on this problem. Renaming apps did cause problems in the original public build but this has been sorted out. The problem arose due to an empty checksum field in the auto presets. They have since corrected this in build 641.458 and I can't rename an application without getting the rule dialog box.

I'm quite interested in the specifics of what you did. Although I don't particularly want trojans on my system, can you tell me which ones you renamed?

Have you tried this with a safe application to see if you get the same behavior.

 

I thought this was fixed also in the latest release and am unable to duplicate it. Perhaps this is due to my policy setting on block most instead of rules wizard. Which policy setting are you testing with?

 

i used a modifed bifrost server renamed to explorer.exe outpost was set on block most componet control was set to normal. when i ran the server an auto rule was created for explorer.exe and the trojan connected, when i tried this with auto rules disabled the trojan still bypased outpost but i did see the memory injection waring maybe this will not work with other malware. As its pretty well known bifrost does cause most firewalls including outpost problems as its still able to establish a reverse connection even though outpost detects process memory injection outpost is powerless in stoping bifrost

try the test with atelier then thier is no need for you to run any trojans test 3 on atelier 3.2 explorer.exe an auto rule is created and the webpage is retrived in the test if you allredy have rules for explorer.exe delete them set component control to normal and outpost on rules wizard thats exactly how i did that test and evey time outpost failed scoring 9 points intotal with auto rules on and scoring the full 10 points with auto rules off

http://www.atelierweb.com/awft/index.htm

 

Thanks for the information. By ignoring the memory injection warning you allowed explorer to start. With auto rules on then it makes sense that a rule was made because explorer was attempting a connection.

This is not the auto rule problem which involved renaming executables, as I previously said that issue was repaired. What you now describe arises from allowing a process memory control to go forward.

Do I understand correctly that you believe that you saw different behavior in process memory control that was dependent on whether or not auto rules is turned on? That certainly would be an issue if it can be reproduced.

I'll check atelier when I have a little bit of time.

Thanks for your response.

 

Yes if auto rules are enabled then a rule is added and network access granted, if rules are off then outpost detects the memory process injection used by bifrost and gives a message saying that outpost has blocked network access. However outpost blocked nothing as you can see from the picture bellow, outpost warns but bifrost still establishes a reverse connection to my self. As you can see in the picture the auto live screen shots of my desktop with bifrost, because im conected to myself the screen shots are in a constant loop and give that feedback effect and push cpu to 100% at the same time you can see the component control warning telling me that its blocked explorer.exe. This is a problem that seems to affect almost all firewalls how can it be fixed?

 

Gonna hold tight and keep using 3.0 til those who are more experienced say 3.5 is good. for sure.

 

good idea i switched back after 1 day lol

 

Thanks, I'll check more into this.

This looks like a loopback configuration issue. Outpost blocked the network connection but most likely your global rules allowed a loopback connection to be made and thus that very interesting screenshot. The way around this is to turn off global loopback rules since they can pose a risk and set them up as needed per application. You might be interested in seeing a guide written by Paranoid2000, a frequent poster at this forum. Section D3 of A Guide to Producing a Secure Configuration for Outpost provides details on this. The guide is very informative and extremely useful in really getting a tight configuration in Outpost.

 

This also works remotley i can control my pc with bifrost remotley with outpost on, the memory injection is simply not stoped i have it injecting into defult browser which is opera on my pc, intasks opera is shown as being connected to me, from my remote location i can view connections on both machines as the bifrost process is not hidden just running within my browser or whatever exe you select to inject in

i haven't tried this remotely since before 3.0 so i cant confirm it works with outpost 3.0 and later but the bifrost memory injection still defteats new kerio zonealarm and sygate

wow that is some guide i was exspecting a few tips this is huge lol ill read on hope the size of the guide is not directly proportional to the security holes outpost has?

 

It would be interesting to see if Outpost 3.5 now defeats Bifrost remotely. You said Bifrost beats ALMOST all software firewalls - which ones stop Bifrost?

 

Most AV's detect and stop Bifrost, it is also called Bifrose by NOD and KAV.

 

lol wrong topic!!! This is about firewalls not antivirus btw bifrost is easly undetected using free anticrack anti piricy software or by using programes like antidote!!! Even though bifrost is about 3 years old it is still able to bypass most firewalls with memory injection. The fact that almost all antivirus detect the free 3 year old version of bifrost is irrelevant to its effects on firewalls. So a modified bifrost, 1 website i remember was selling modifed bifrost servers for $5 they became so popular they changed the price to $20 (modifed to avoid av detection) will run on your system without your knowledge unless your using outpost firewall or registry and or start up protection

I say almost all firewalls as i haven't tested them all lol sofar thier is no firewall i have tested that stops the reverse connection. process guard also detects memory injection but didnt stop anything, i havent tested it against appdefend yet which also detects memory injection. kerio, zonealarm, sygate and a few others all fail. outpost being the only firewall i seen that gives a warning. So many firewalls are still only detecting dll injection and not memory injection which most trojans are using now, a trojans main weakness is still start ups and reg entrys so alot of the new trojans i have seen are including built in rootkits

 

The guide has to do with configuring your firewall tightly. It has nothing to do with holes. Configuring your firewall tightly, any firewall, isn't an easy task and does take some work.

 

I finally tried your scenario trojan but I could not reproduce it. With auto rules turned on, network access was blocked due to memory injection.

I don't know how my configuration is different from yours but I have a default configuration with auto rules on. I've been trying it out all week allowing Outpost to create everything. If you would like to analyze this further perhaps you might want to do it at the Outpost forum.

I enjoyed our discussion. Thank you.

 

With auto rules turned on and default config here, I fail tests 1,2 and 5. With component control set to max I fail 2 and 5.

 

Stumbled on a solution, I guess my configuration was bad, maybe not paying attention when answering prompts, went to a new configuration and all is fine now.