Security Basics mailing list archives

RE: How to prevent zero day attacks


From: Jerome Athias <athiasjerome () gmail com>
Date: Tue, 22 May 2012 09:44:00 -0700

try to be aware of them

Envoyé à partir de mon Windows Phone
De : Michał Purzyński
Envoyé : 22/05/2012 17:20
À : sjalex () taidri com
Cc : synja () synfulvisions com; amishra.jsr () gmail com;
listbounce () securityfocus com; security-basics () securityfocus com
Objet : Re: How to prevent zero day attacks
Are we talking about some specific systems or just generic techniques?

If generic - you've got some good answeres already. I would add -
segment your networking. Assume every system will be owned, sooner or
later - and plan for it. Local firewall is nice, but when (not if)
someone will get "root/Administrator" access he will bypass it anyway.
Inwest into good network design, think - what could i do, as the
attacker, after taking this machine? How would i extend my attack?
Don't waste your time & money on yet another "innovative" way of
signature based detection. Are layer 2 attacks possible in your setup,
after one of the machines been taken over? What about access to
another machines in your network - how much easier it will be to
extend the attack?

If we're talking about some speficic systems, enumerate them.

Windows - learn how to use EMET. Btw - i am aware of that "here's
another way to bypass EMET". Most, if not all of them are build up on
a bad assumption - like, the process beeing attacked has full
Administrator/Local System privileges, with write access to debug
registers. If your MSSQL can do that - you aready have a bigger
problem.

Do not trust defaults. Run services into separate accounts and give
them only what they need. Same goes for user applications, as someone
has pointed out already. Get some _kernel_ enforced software that can
whitelist binaries that can be run. Use build-in things in Windows,
like (parts of, at least) MAC and MIC (Mandatory Access Control and
Mandatory Integrity Control, if anyone wonders).

Linux - learn how to use PaX in a right way. How to make your
executables into proper PIE. Learn some MAC system and use it - RSBAC,
for example.  Or Grsec RBAC.

0-days aren't some kind of black magic, that if it's done to your
servers will make them all turn into kitten-killing-zombies. They are
ordinary exploits - made by people who know a lot more than you. Use
exploit mittigation techniques.

After all, there's not much you can do on Linux system, with PaX, with
PIE binaries, NX + full ASLR enforced, with mprotect() restrictions.
Unless you have some information leak in application _before_ it is
exploited, that's it.

On May 22, 2012, at 5:32 PM, Stephanus J Alex Taidri wrote:

Seconded to Rob....

Limit the OS to run with least privilege as possible instead of
granting administrator access to normal user.
This is common for Linux OS, Mac OS and Windows 7 onwards to have apps
running with normal user privilege and required User Access Control
(UAC) to confirmed any changes that required root/admin privilege.

Train the end-users to not simply ignore any UAC pop-up window(s), to
read carefully and understand it well before accepting the action
requested. If in doubt, always train end-users to choose No/Reject as
usually there's less harm to do this.

Kind regards,
SJ Alex Taidri

On Tue, May 22, 2012 at 11:10 PM, <synja () synfulvisions com> wrote:

A layered security model.

If browsers are run as limited users, and you set ACLs on the temp folders
to deny execute permission, etc... You've just prevented most 0day malware.

Compartmentalization of services limits the scope of compromise. You can
limit the priveleges of older software by running their services as
NetworkService or LocalService instead of LocalSystem.

There are thousands of ways, but you need to define a scope and
environment.

Rob

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, 
how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, 
purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for 
set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital 
certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------



------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an
SSL certificate.  We look at how SSL works, how it benefits your
company and how your customers can tell if a site is secure. You will
find out how to test, purchase, install and use a thawte Digital
Certificate on your Apache web server. Throughout, best practices for
set-up are highlighted to help you ensure efficient ongoing management
of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------


Current thread: