Why use a third party software Firewall?

I think that if the malware uses encrypts its traffic, it could pierce through a firewall. Also the fact that if a trusted app gets rooted there is no way to differentiate between traffic it sends and traffic sent on its behalf (if the app is whitelisted).

Doesn't Sandboxie's restrictions block outbound? I know its not meant to be a full fledged firewall but it seems to serve the purpose well. Do you know of any specific limitations of the sandbox internet access?

D1G1T@L wrote:Also the fact that if a trusted app gets rooted there is no way to differentiate between traffic it sends and traffic sent on its behalf (if the app is whitelisted).

That's how I understand it too. But I think wat0114 and some others restrict the whitelisted app to some extent, therefore possibly preventing some malicious outgoing connections.

D1G1T@L wrote:Doesn't Sandboxie's restrictions block outbound? I know its not meant to be a full fledged firewall but it seems to serve the purpose well. Do you know of any specific limitations of the sandbox internet access?

Yes I'm quite sure Sandboxie's internet access restrictions block outbound traffic, on an application level. There are also Port blocking mechanisms too - for example, my Firefox browser has this configuration:
BlockPort=*,80,443,1024-5000
This means that the browser can only make outgoing connections via Port 80, 443, and 1024-5000. In other words, those are the Ports which are whitelisted.

The limitations of Sandboxie's internet access restrictions are mostly related to configurability. For example, there's no way to configure it to restrict specific IP addresses.

ssj100 wrote: But if the keylogger is using the browser to send out the logged keys to the hacker's IP address, wouldn't this defeat the firewall? And if the firewall is restricted "too much", wouldn't this be inconvenient?

For the first question: Maybe, maybe not. If the hacker's ip address resides at, for example, remote port 81 or 82 or 8080 - non-standard http ports, it probably won't succeed in my particular setup because of my remote port restrictions for browsers: 80, 443, 554, 1755, 1935.

For the second question: Yes, if too restricted. The ports I've chosen give me what I need, while still keeping a fairly tight rein on the browsers.

On a side note, I see you restrict remote ports to, amongst others, 1024-5000. This port range is actually used in typical Win XP local ports comms. They are not used in typical browser outbound comms. Unless you have some sort of local loopback restriction where you are restricting the local loopback interface to local and remote ports 1024-5000?

Interestingly HungryMan explained this very topic on his blog just the other day: https://insanitybit.wordpress.com/2012/06/04/why-i-dont-like-antiexecutables/

P.S. I hate outbound firewalls for this reason too. Process A can create a thread in process B (lol windows) and I really don’t know how a firewall that blocks A but allows B is going to do a thing about that. That and user interaction is poor security. Outbound firewalls are also a half decent layer but if the malware is already on your system, potentially with root, you’re quite likely screwed.

If he reads this forum, he's welcome to join and discuss this with us.

Anyway, speaking of resident keyloggers, can they log anything if a sandbox has no processes running?

wat0114 wrote:For the first question: Maybe, maybe not. If the hacker's ip address resides at, for example, remote port 81 or 82 or 8080 - non-standard http ports, it probably won't succeed in my particular setup because of my remote port restrictions for browsers: 80, 443, 554, 1755, 1935.

Yes, interestingly my Sandboxie configuration for browsers also has similar port restrictions.

wat0114 wrote:On a side note, I see you restrict remote ports to, amongst others, 1024-5000. This port range is actually used in typical Win XP local ports comms. They are not used in typical browser outbound comms. Unless you have some sort of local loopback restriction where you are restricting the local loopback interface to local and remote ports 1024-5000?

I haven't looked at this for more than a year now. When I was configuring the port restrictions with Sandboxie, I noticed I needed to open up ports 1024-5000. From memory, this is so inbound traffic is allowed through. With Sandboxie, traffic is blocked both ways if you set up a port restriction.

D1G1T@L wrote:Interestingly HungryMan explained this very topic on his blog just the other day: https://insanitybit.wordpress.com/2012/06/04/why-i-dont-like-antiexecutables/

P.S. I hate outbound firewalls for this reason too. Process A can create a thread in process B (lol windows) and I really don’t know how a firewall that blocks A but allows B is going to do a thing about that. That and user interaction is poor security. Outbound firewalls are also a half decent layer but if the malware is already on your system, potentially with root, you’re quite likely screwed.

If he reads this forum, he's welcome to join and discuss this with us.

Anyway, speaking of resident keyloggers, can they log anything if a sandbox has no processes running?

I mostly agree with HungryMan's blog post (even though most of it is outside the realm of this thread haha), but I'm not sure if he's really cut out to make statements on what a hacker can and can't do if he's also making statements like:

The approach they take, I don’t know...

if they want persistence, they can hop to other processes (apparently quite easy to do)

For me, SRP is already built-in and I had "fun" setting it up and researching it. I even had "fun" "bypassing" it with memory-only POCs and what not. I still think it gives decent enough protection against spontaneous drive-bys. However, I've never had SRP make a noise in the entire time I've had it enabled. Furthermore, SRP (or other anti-executable mechanisms) is useful in the context of an Admin-User environment, where the "Administrator" controls what can be installed (and hopefully knows what he's doing) and the "User" is only allowed to use whatever is installed. This is useful to prevent malware from typical PE executables (eg. that have been maliciously tagged or are malicious to start off). I still believe that for the home user, this is the most common way to get infected.

HungryMan also mentions about usability being non-existent with an anti-executable enabled, which I don't understand. Firstly, all one normally has to do is click about twice to disable their anti-executable. This doesn't sound too inconvenient to me. Secondly, "average" users don't install new software often (maybe never?). I personally haven't installed a new program on my system for what seems like years. I suppose he could be referring to updating software, but again, I disagree that a couple of clicks is inconvenient. Where usability really becomes significantly impaired is in the context of not having eg. Flash or Java installed. This means the user can't watch stuff like YouTube! Crazy haha. With Java, I've actually come across many sites that require it to be installed, and some of these sites are incredibly entertaining. Those who don't have Java installed are simply missing out, but it's their choice.

As for his firewall statements, he seems to be missing the point of the concept of "layered security", even though he alludes to it quite often throughout his post. The way I see it, everything "by itself" can be argued as being a "half decent layer" only. But when you combine them together, you may get a "decent layer".

ssj100 wrote:When I was configuring the port restrictions with Sandboxie, I noticed I needed to open up ports 1024-5000. From memory, this is so inbound traffic is allowed through. With Sandboxie, traffic is blocked both ways if you set up a port restriction.

Okay I see, then that would make perfect sense

Just to reiterate what you've alluded to and what I've more or less said, that a firewall with outbound application control utilized can form a nice part of a layered security approach, but definitely can't be counted on for absolute security. I see it as a kind of governor, or even an Internet traffic cop for Internet-facing apps, especially browsers, forcing thesde trusted apps to connect only the way the user intends for them to connect. It also can potentially deny untrusted apps from connecting out at all, if the situation were to ever arise, due mainly to the initial layer(s) failing for some reason. From my standpoint this is not exactly insignificant in the grand scheme of things. The firewall simply forms part of the equation in securing my machine, even if it's not the most important part of it.

This means the user can't watch stuff like YouTube! Crazy haha. With Java, I've actually come across many sites that require it to be installed, and some of these sites are incredibly entertaining. Those who don't have Java installed are simply missing out, but it's their choice.

You are totally right the approach of security through disabling is a dead end and it really annoys the heck out of anyone who want to use the full functionality of their machines. That's what sandboxing is for am I right?

As for his firewall statements, he seems to be missing the point of the concept of "layered security", even though he alludes to it quite often throughout his post. The way I see it, everything "by itself" can be argued as being a "half decent layer" only. But when you combine them together, you may get a "decent layer".

Security is truly a sum of all parts. Specialized layers are necessary for different paths into a system. The experienced user however is the one who uses the least number required and the most potent of them all.

wat0114 wrote:Just to reiterate what you've alluded to and what I've more or less said, that a firewall with outbound application control utilized can form a nice part of a layered security approach, but definitely can't be counted on for absolute security. I see it as a kind of governor, or even an Internet traffic cop for Internet-facing apps, especially browsers, forcing thesde trusted apps to connect only the way the user intends for them to connect. It also can potentially deny untrusted apps from connecting out at all, if the situation were to ever arise, due mainly to the initial layer(s) failing for some reason. From my standpoint this is not exactly insignificant in the grand scheme of things. The firewall simply forms part of the equation in securing my machine, even if it's not the most important part of it.

I suppose it depends on how many layers you're wanting to go with. For me, the probability of coming across malware (when I'm not purposefully looking for them) appears to be nearly zero (from my experience). So what is the probability of coming across malware that can specifically bypass my security setup (and approach)?

Layered security is a valid concept, but where does one stop? For example, I could argue that your setup could be improved with the addition of:
1. a light virtualisation mechanism (eg. Shadow Defender)
2. a real-time antivirus scanner
3. a Classical HIPS

This is so that if eg. an exploit is discovered in Windows 7 (fast becoming the most targeted OS on the market) which leads to a privilege escalation attack (therefore bypassing AppLocker), you would still be protected. More on privilege escalation exploits here:
https://ssj100.forumotion.com/t226-mis-understandings-about-privilege-escalation-exploits

However, even non-traditional exploits (like the wmf exploit) was stopped cold if eg. SRP was in place. In my opinion, the firewall is pretty much like a Classical HIPS or perhaps something like WinPatrol in that it can alert the user with pop-ups when something is going on (whether that something is legitimate or not often can be hard to work out). Like with most Classical HIPS mechanisms, it often can also be configured to silently block everything that has not been specifically allowed.

However, no matter how one looks at it, if you want to have a "properly configured firewall" in place, you are almost always going to have to perform some form of computer house-work when you come across something that doesn't work. An example is where certain sites can't be accessed because they require different ports to the ones I have allowed through Sandboxie. There is no need for computer house-work with Sandboxie in this situation though - to get past this, I simply open a web-browser in a sandbox that has less (port) restrictions. This is done with a couple of clicks and I can eg. delete the sandbox thereafter. I can imagine that with a system-wide firewall in place, there would be the need to open up the firewall and look for the eg. Chrome or Firefox process and re-configure/disable some rule for the session, and then revert back these changes once the session is finished. But I suppose one way to overcome this is to have a separate dedicated browser that has no port restrictions applied to it.

D1G1T@L wrote:Anyway, speaking of resident keyloggers, can they log anything if a sandbox has no processes running?

Not sure what you mean here. I think if a keylogger is already running, there is always the potential for something to be logged.

Can the keylogger operate if all processes in the infected sandbox are terminated?

Would it be safe to fire up the browser in a trusted sandboxed and do business if the infected sandbox has nothing running if nothing is running in there according to Sandboxie Control?

Sorry if I wasn't clear enough :/

D1G1T@L wrote:Can the keylogger operate if all processes in the infected sandbox are terminated?

Would it be safe to fire up the browser in a trusted sandboxed and do business if the infected sandbox has nothing running if nothing is running in there according to Sandboxie Control?

That's actually how I do things (eg. when I bank online), and something I've advocated for years. Surely the keylogger will be unable to log anything if it's not running? That's what you're effectively doing when you terminate all processes in the sandbox. I suppose deleting (as opposed to only terminating all processes) all sandboxes would appear safer, but I'm not convinced that there would be any difference.

ssj100 wrote:

Layered security is a valid concept, but where does one stop? For example, I could argue that your setup could be improved with the addition of:
1. a light virtualisation mechanism (eg. Shadow Defender)


2. a real-time antivirus scanner
3. a Classical HIPS

Maybe, maybe not, because with the addition of those 3rd party apps, there's the potential, and almost certain, introduction of bugs they will introduce to the system. My security is formed by:

1. LUA account
2. Applocker (with DLL enforcement)
3. Windows 7 firewall
4. EMET

There are also regular system images using the Shadow Protect boot disk. Note that everything is built-in to the O/S except for EMET but it's at least Microsoft designed, so there is no introduction of bugs that could introduce stability and/or security issues.

There is also Waterfox browser running at Low il, with NS plug-in to mitigate the potential attack vector for malicious scripts (I'm also using Chrome sometimes because I like how it now runs the renderer processes as 'untrusted" As for antivirus I will scan the odd file using MBAM free.

wat0114 wrote:Maybe, maybe not, because with the addition of those 3rd party apps, there's the potential, and almost certain, introduction of bugs they will introduce to the system.

I generally agree with this very much. However, I'd be interested to know what "3rd party apps" you're talking about. Are they necessarily security related? Could non-security "3rd party apps" cause conflict with security related mechanisms? For me, I try to minimise the number of "3rd party apps" installed on my system, but it's not just security related apps. For example, I only have 2 web browsers "installed" - one built-in (IE 8 ) and Firefox (13). I note you have at least 3 browsers "installed", including Chrome. Is it possible that having more non security related apps installed could also diminish security by eg. causing conflict?

Furthermore (and assuming non security related apps don't potentially cause diminished security...I don't know if this is true), if they are security related apps, would the ones which don't function at the kernel level be just as unlikely to cause diminished security as non security related apps?

For me, I assume (whether rightly or wrongly...and I'm no programmer of any sort) that the more code one has on a system, the more likely things can go wrong like eg. diminished security. This code could be anything and not just security related. The way Windows works with its "Registry" always seemed messy to me.

One big reason I like Sandboxie is because I can temporarily run "code" in a virtual space and then get rid of it in an instant, including associated "hidden" registry keys etc. I also use on-demand scanning, but I run these scanners within the sandbox. I like VirusTotal because minimal "extra code" is needed to use it, and besides, I always run VirusTotal "sandboxed" (in a web browser) anyway. Thinking about it, I think I mainly use Sandboxie for isolation of "benign" code that could become unintentionally "malicious" haha.

ssj100 wrote: However, I'd be interested to know what "3rd party apps" you're talking about. Are they necessarily security related?

Nothing in particular, but you mentioned antivirus or HIPS, so for me just about any of the popular antivirus programs may introduce some bugs that might weaken a system's inherent level of security. Besides, I have not been a fan of resident antivirus programs for a long time. As for HIPS, again, it could be just about any of the available products out there, one of which I trialed recently in my Win7 vm and I was not impressed with it. It was sluggish in its performance and that immediately set off a red flag for me. I'm very pleased with AppLocker and the level of protection it provides for me without it being an added 3rd party application.

Could non-security "3rd party apps" cause conflict with security related mechanisms? For me, I try to minimise the number of "3rd party apps" installed on my system, but it's not just security related apps. For example, I only have 2 web browsers "installed" - one built-in (IE 8 ) and Firefox (13). I note you have at least 3 browsers "installed", including Chrome. Is it possible that having more non security related apps installed could also diminish security by eg. causing conflict?

Yes, I think you are right on the money here that non-security apps could cause problems as well.

Furthermore (and assuming non security related apps don't potentially cause diminished security...I don't know if this is true), if they are security related apps, would the ones which don't function at the kernel level be just as unlikely to cause diminished security as non security related apps?

I don't know the answer to this, but I'd guess the ones that don't hook the kernel are less likely to diminish security, even if they may not protect as well, as is the case, for example, with Sandboxie for x64 as explained by its developer.

For me, I assume (whether rightly or wrongly...and I'm no programmer of any sort) that the more code one has on a system, the more likely things can go wrong like eg. diminished security. This code could be anything and not just security related. The way Windows works with its "Registry" always seemed messy to me.

Yep, I agree.

One big reason I like Sandboxie is because I can temporarily run "code" in a virtual space and then get rid of it in an instant, including associated "hidden" registry keys etc. I also use on-demand scanning, but I run these scanners within the sandbox. I like VirusTotal because minimal "extra code" is needed to use it, and besides, I always run VirusTotal "sandboxed" (in a web browser) anyway. Thinking about it, I think I mainly use Sandboxie for isolation of "benign" code that could become unintentionally "malicious" haha.

I consider Sandboxie an exception to my view on trying to avoid 3rd party apps, whether security or non-security related. The paid verision is running on an XP computer and a Win7 Home Premium computer in our household. I've often considered running it on my own system, but I just don't see the need for it with the level of security my current setup provides. Why do I feel this way about Sandboxie? Well, I just believe Ronan Tzur (that's his correct name?) to be an exceptional coder, far above average. And based on my mostly pleasant experience with it, as well as overwhelming positive feedback on it from a wide range of users, it's glowing track record basically speaks for itself

Whoops, I shouldn't have said I 'hate' outbound Firewalls. They're alright, though I don't love them.

AE's don't really work with Windows/Linux/OSX and I actually (and coincidentally) just blogged something related to this issue.

Linux and Windows have the same system for process isolation - processes are separated into user groups. If two processes are run by the same user they can access the other process, they can do whatever they want to it.

That's why AE's don't work. If I compromise Pidgin I also compromise Firefox because they're both running in the same User. If I've got an AE running and saying my shellcode in Pidgin isn't allowed to execute payload.exe it's fine, I can still read and write to the disk through Pidgin (or Firefox for that matter) or even to the registry.

Think about how much malware can do with read/write access to the file system and registry. Think about what Firefox and Pidgin can do, that's what your shellcode can do.

I don't really hate outbound Firewalls, I shouldn't have written that. I just don't think they're going to provide much.

There's a big difference between 'layered' security and 'throw everything at the computer'.

(I'm not allowed to post full URLs) scriptjunkie.us/2011/06/bypassing-dep-aslr-in-browser-exploits-with-mcafee-symantec/

Attack surface is an issue. That AE is some complicated code and it's now running with high privileges on your system. It's quite possibly going to allow an attacker to compromise your system.

You have to weigh it out. If you think it's providing something to your system absolutely use it. My issue is that because people don't necessarily know how programs work etc they're going to assume they're safe from everything due to their AE. I see this a lot - I see it claimed over and over that AE is the end all be all of security, that no hacker's getting in because they "have to install first" or "have to run first" etc. I only care about informing people and if there's one thing surrounding this issue that I want to get across it's that the attacker has already started running code on your system, they're in control of code etc.

Anyways, again, sorry to post in an older topic haha hope this post is helpful for some. And thanks for reading the blog.

Hi Hungry Man, nice of you to join and post. Thanks for your insight.

Hungry Man wrote:That's why AE's don't work. If I compromise Pidgin I also compromise Firefox because they're both running in the same User. If I've got an AE running and saying my shellcode in Pidgin isn't allowed to execute payload.exe it's fine, I can still read and write to the disk through Pidgin (or Firefox for that matter) or even to the registry.

I still maintain that AE's do work in the prevention of driveby attacks and in an Admin/User world. I'm not sure if you recall the wmf exploit that surfaced in 2005 - all variants of this exploit eventually automated the downloading and execution of a PE executable. If this PE executable did not run, the user's system would not get infected. I do agree that the AE did not stop the exploit from initiating in the first place, but surely you must agree that the AE did stop the user from being infected?

So in a real-world situation, AE's can certainly prevent a user's system from being infected. Furthermore, I still believe (and I admit I don't have any literature or statistics to back this up) that the vast majority of infected home user systems are due to (manual) execution of a PE executable that happens to be malware or contain malware. This is where an Admin/User environment can be useful, assuming the User is a "noob" and the Admin is more knowledgeable about what's safe and what's not (and the steps needed to verify this).

I also believe in combining sandboxing and AE, with sandboxing being the base protection.

Hungry Man wrote:I don't really hate outbound Firewalls, I shouldn't have written that. I just don't think they're going to provide much.

I also think that way. However, if I was on a Windows version which has its own built-in outbound firewall mechanism, I would most likely utilise it.

I absolutely agree that the AE stopped the user from being infected and that most AE's will stop just about every piece of malware out there.

In terms of determining statistically what the major cause of malware it I would say it's exploit kits. Blackhole is incredibly popular and they make tons of money. In just a short span the Java exploit on OSX led to 700,000 infections. But the only two studies I've seen are completely in contradiction and entirely bias.

If it were due to manual execution I'd say AE's are more useless. If I download a file and double click to run it why would I not then allow my AE to run it? An AE is not a trust based solution, you do not trust it to make decisions. This is in contrast to an antivirus, which is trust based and which you do allow to make decisions for you.

In other words, a user who wants to execute that file will do so regardless of an AE. That is why AE's are more suited to situations where an administrator has locked the user out of their own system and is using an AE to only allow them to install what they want to.

Back to the wmf exploit. Yes, at some point it did download the executable. But that's not to say it needed to, only that the attackers found that to be the simplest route.

In my opinion what an AE really does is prevent persistence for drive by downloads.

If I've infected your Firefox.exe I can do anything a standard user/ medium integrity process is capable of doing. If there's an AE I can still read/write to the disk and registry.

I can even set up a startup entry. But what I can't do is get my payload to startup because the AE will block it.

But I've still compromised the session and the user account. I think that's pretty dangerous.

I like AE more in the context of sandboxing, which is kinda what I was getting at in the last post. When I run a program in Sandboxie and say "only tehse files can execute" I'm doin something very different from a typical AE. I'm creating a managed policy around an application not a user.

I still don't love it because if you're sandboxing them with something like Sandboxie they're trapped anyways. But in terms of preventing run of the mill drive bys it works out alright.

Hungry Man wrote:I absolutely agree that the AE stopped the user from being infected and that most AE's will stop just about every piece of malware out there.

Yes, and that's what I was getting at - in the wild, it appears that AE's are very effective.

Hungry Man wrote:If it were due to manual execution I'd say AE's are more useless. If I download a file and double click to run it why would I not then allow my AE to run it? An AE is not a trust based solution, you do not trust it to make decisions. This is in contrast to an antivirus, which is trust based and which you do allow to make decisions for you.

In other words, a user who wants to execute that file will do so regardless of an AE. That is why AE's are more suited to situations where an administrator has locked the user out of their own system and is using an AE to only allow them to install what they want to.

Yes, AE's are pretty much useless if the "noob" user has the ability to disable it and install whatever he/she wants. However, as you point out, they can be useful in an Admin/User environment.

Hungry Man wrote:If I've infected your Firefox.exe I can do anything a standard user/ medium integrity process is capable of doing. If there's an AE I can still read/write to the disk and registry.

That's interesting - I haven't thought of it like that before. What about in a LUA + SRP setup (which is the only "anti-executable" mechanism I would ever recommend)? Apart from privilege escalation, memory-only attacks, and "flicking the hidden switch to disable it", I struggle to understand how it be can bypassed. The Limited User is unable to write to the registry or to various "system" areas. The Limited User is also unable to run PE executables, since the SRP mechanism is applied to that specific account. I'm not sure how much malicious activity a malware can do in this particular sort of setup?

That's interesting - I haven't thought of it like that before. What about in a LUA + SRP setup (which is the only "anti-executable" mechanism I would ever recommend)?

In terms of an environment where the account is restricted then, naturally, the shell is restricted. It would only be able to write to specific registry areas, areas of the disk, etc. But that's also the case if you didn't have an AE and you executed something in a LUA environment - it would have the same exact rights.

In terms of malicious activity, let's assume I've just hacked your Firefox (well, not 'your') on an account running no security software but with LUA + SRP as well as an AE.

I'm unable to execute any new payloads. We'll assume the AE is set up to whitelist DLLs (if it isn't you're making bypasses a lot easier).

So, I can just read and write to the users disk. I can read/write the address space of processes within my User ID. I can read/write to my own Firefox directories/ install extensions/ whatever I want to those files.

What I can't do is 'install' in the typical sense. I can't get anything in program files without a privilege escalation attack (but I could always use a local exploit).

Let's compare this situation to one without SRP or an AE.

I'm in your Firefox.exe and I can read/write to the users disk. I can actually execute a payload. Let's imagine I execute payload.exe.

Well as payload.exe I can do everything Firefox could do. I'm still only able to read/write to the same files as before.

The one thing I do gain is that I can set payload.exe to start up and without an AE I can gain persistence this way.

But how different are those situations really? Within a single session they are virtually identical in terms of the damage that can be done.

And in terms of gaining persistence there are quite a few clever ways to do so. And the only way to stop those ways (ie: installing a malicious extension, creating a homepage that links to an exploit page, patching an executable fileetc) would be to whitelist literally every file and then update that whitelist every time so much as a config file changed.

If you compare those two scenarios I think you'll see how little an AE changes when an attacker is expecting one.

I suppose what I don't understand is what is meant by "hacked Firefox". Presumably this is from a source within or associated with Firefox itself - eg. Flash, Java etc. However, having no programming experience, I still struggle to understand what harm exactly can be done to the system without the use of a payload. That is, I don't understand how such code can be programmed and linked etc to cause equivalent writing/reading. As I said, I really don't understand this shellcode thingy - it would be nice to see it in action doing significant harm to a system without the use of a payload and without the use of a command prompt etc.

Also, wouldn't an anti-executable mechanism protect against many USB-based malware? We all know malware doesn't just come from internet-facing applications. But I suppose disabling auto-run should solve most of the USB-based malware out there.

By the way (and back more on the topic of this thread haha), did you have an opinion on this?:
https://ssj100.forumotion.com/t498-udp-flood-attacks-etc
Even my own ISP is struggling to come up with an answer about it. What I'm quite sure is that software firewalls will do nothing against it. This form of attack is much more worrying for me than other "attacks" - sandboxing and anti-execution (and a good security approach) addresses those other attacks. However, UDP flood attacks (and other similar attacks) seem to be very easily done. It will be interesting to know what else can be done from the router level. So far, all I've observed is that the only "harm" that can be done is essentially causing annoyance - cutting off one's internet connection. However, this internet connection can be regained by restarting the router.

I can probably find something (or do a video myself if I'm feeling particularly motivated) that shows how you can read/write from shell.

Simply put a program is just address space. That address space is filled with little snippets of code that sometimes get called. When you 'hack' a process you put your own code into that address space, which means you can run commands the same exact way the program is running them. So when you get shell you can do every single thing that the process you've attacked can do.

A payload is just a separate process. If it inherits the integrity of the parent process (which it would) it can do those commands that the shell could do.

The reason payloads are used is because malware is a business. Exploit pages can server hundreds of customers by customizing payloads to their needs.

In terms of USB autoruns it could possibly. Maybe not as much on XP though due to how USB is treated (no ACLs) but yes, it could potentially work to prevent USB infections. That's certainly a fair point though it does seem like a fairly strict policy just to protect from USB infection.

For UDP flooding attacks I would imagine simply using an approach like Fail2Ban would work ie: if you're getting a ton of unsolicited packets the IP gets banned and all packets are dropped without inspection. You could probably set up an IDS outside of your router that would do something like this with pfsense or the like.

Typically the only damage is, as you say, cutting off someone's connection. But unsolicited packets at one point caused a buffer overflow in a windows counter on 64bit systems that allowed remote code execution. And bruteforcing passworded services also will be similar to a UDP flood attack.

Hungry Man wrote:I can probably find something (or do a video myself if I'm feeling particularly motivated) that shows how you can read/write from shell.

That would be really good. A sample that I can test and play around with myself would be great. Just if you get the time though.

Hungry Man wrote:That's certainly a fair point though it does seem like a fairly strict policy just to protect from USB infection.

Perhaps having such strict policies also forces/reminds the user to make sure he/she is running something safe (eg. check valid digital signatures, hashes etc). Also, with real-world situations, it's known to protect against payloads. So we're not talking about just protecting from USB infection.

Hungry Man wrote:For UDP flooding attacks I would imagine simply using an approach like Fail2Ban would work ie: if you're getting a ton of unsolicited packets the IP gets banned and all packets are dropped without inspection. You could probably set up an IDS outside of your router that would do something like this with pfsense or the like.

Typically the only damage is, as you say, cutting off someone's connection. But unsolicited packets at one point caused a buffer overflow in a windows counter on 64bit systems that allowed remote code execution. And bruteforcing passworded services also will be similar to a UDP flood attack.

Interesting - from what I read about Fail2Ban, it doesn't look Windows compatible? Neither is pfsense?

It would be through metasploit. I'm going to see if I can find a video demonstration first as I'm busy today and I haven't set up metasploit.

For a quick demonstration you can skip to 5 minutes in this video to see him gain shell and read a file from a separate virtual machine.

securitytube.net/video/2556

Perhaps having such strict policies also forces/reminds the user to make sure he/she is running something safe (eg. check valid digital signatures, hashes etc). Also, with real-world situations, it's known to protect against payloads. So we're not talking about just protecting from USB infection.

A policy I could get behind is allowing execution to signed software and prompting for unsigned software. This is more for consistency, the same security holes still apply.

Fail2Ban is a linux thing, yeah. I just assume Windows must have something similar but it may not.

pfsense is BSD based - it's an operating system that you would put on hardware and run on your networks perimeter.

Hungry Man wrote:

For a quick demonstration you can skip to 5 minutes in this video to see him gain shell and read a file from a separate virtual machine.

securitytube.net/video/2556

That's a pretty cool demo, although a firewall protecting the victim machine stops the exploit; no ip to scan so no exposed, vulnerable service to exploit.