Nytro

Am scos, postati aici daca mai au si altii.

NU e Apache, e AppServ ala, ce-o mai fi si el. Am redenumit topicul.

Hidden Rootkit Process Detection [TABLE] [TR] [TD=class: page_subheader]Contents [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Introduction to Rootkits Userland Rootkit & their Hidden Operations Hidden Userland Rootkit Process Detection Methods Direct NT System Call Implemenation HPD using PIDB (Process ID Bruteforce) method HPD with CSRSS Process Handle Enumeration [*] Other Methods of Detecting Hidden Processes [*] References [/TD] [/TR] [TR] [TD] [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: page_subheader]Introduction to Rootkits [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Rootkits are one of the advanced species in today's every changing technical world. They are known for their sophisticated techniques to hide their presence often evading their detection from top notch Antiviruses and detection tools. Antivirus solutions often hit the wall when it comes to Rootkit detection and there is a greater need for dedicated Anti-Rootkit tools. Rootkits use combination of user land and kernel level techniques to evade their detection. In this article we will throw light on how userland Rootkits work under the hood and different techniques which can be used to detect such Rootkits. Though these methods are effective only against user land Rootkits, in some cases they can even detect kernel based Rootkits unless they haven't taken proper care to remove all those traces. [/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader]Userland Rootkits & their Hidden Operations [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Userland Rootkits use different techniques to hide their process and to prevent its termination. One such method is to hook the NtOpenProcess function (OpenProcess API internally calls NtOpenProcess) and return negative result whenever Anti-Rootkit application try to open such process. As a result Rootkit process will remain hidden from any process viewer tools. This is just one of the method and often you will find more such internal functions such as NtQuerySystemInformation being hooked to filter out their process from the list. [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Hidden Userland Rootkit Process Detection Methods [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Detection of hidden process is equally challenging as Rootkit can employ one or more methods to cover its presence. Here are some of the very effective methods to detect such userland Rootkit processes. All these detection methods work on common approach. First they get the list of all running processes using standard API functions such as EnumProcesses or Process32First. Then one or more special methods mentioned below are used to enumerate the processes. Finally this new process list is compared with previously obtained list and any new process found in this new list is detected as hidden rootkit process. [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]HPD using Direct NT System Call Implemenation [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] This is very effective method to detect any hidden userland rootkit processes. One of the lesser-known methods of enumerating the processes is to use NtQuerySystemInformation function by passing first parameter as SystemProcessesAndThreadsInformation. The drawback of this method is that it can be easily circumvented by hooking the NtQuerySystemInformation function and then by tampering with the results. The NtQuerySystemInformation is basically stub having few lines of code to transition from user to kernel land. It finally calls the NtQuerySystemInformation function within the kernel. So the trick here is to implement the NtQuerySystemInformation without directly calling the function. Here is the sample code that shows how one can directly implement NtQuerySystemInformation on various platforms. On Windows2000, INT 2E and from XP onwards 'sysenter' instruction is used to transition from user to kernel. [/TD] [/TR] [/TABLE] __declspec(naked) NTSTATUS __stdcall DirectNTQuerySystemInformation (ULONG SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength) { //For Windows 2000 if( OSMajorVersion == 5 && OSMinorVersion == 0 ) { __asm { mov eax, 0x97 lea edx, DWORD PTR ss:[esp+4] INT 0x2E ret 0x10 } } //For Windows XP if( OSMajorVersion == 5 && OSMinorVersion == 1 ) { __asm { mov eax, 0xAD call SystemCall_XP ret 0x10 SystemCall_XP: mov edx, esp sysenter } } //For Windows Vista & Longhorn if( OSMajorVersion == 6 && OSMinorVersion == 0 ) { __asm { mov eax, 0xF8 call SystemCall_VISTA ret 0x10 SystemCall_VISTA: mov edx, esp sysenter } } //For Windows 7 if( OSMajorVersion == 6 && OSMinorVersion == 1 ) { __asm { mov eax, 0x105 call SystemCall_WIN7 ret 0x10 SystemCall_WIN7: mov edx, esp sysenter } } } } [TABLE] [TR] [TD]This technique can discover any userland rootkit process and only way for rootkit process to defeat against this technique is to move into kernel. However, due to low-level implementation, there is slight risk in using this method in production code.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]HPD using PIDB (Process ID Bruteforce) method [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] This method was first used by BlackLight and it turned out to be very effective yet simple. Here, it enumerates through process id from 0 to 0x41DC and then check if that process exist by calling OpenProcess function. Then this list of discovered processes are compared with normal process list got using standard enumeration functions (such as Process32First, EnumProcesses functions). During the testing, it is found that some process id on server machines were more than magic number 0x41DC. So in order to be effective the magic number is doubled to take care of all possible running processes on latest operating systems. Here is the sample code that implements PIDB method: [/TD] [/TR] [/TABLE] for(int i=0; i < 0x83B8; i+=4) { //These are system idle and system processes if( i == 0 || i==4 ) { continue; } hprocess = OpenProcess (PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, i); if( hprocess == NULL ) { if( GetLastError() != ERROR_INVALID_PARAMETER) { // If the error code is other than // ERROR_INVALID_PARAMETER that means this // process exists but we are not able to open. //check if this process is already discovered //using standard API functions. if( IsHiddenProcess(i) ) { printf("\n Hidden process found %d", i); } } continue; } dwExitCode = 0; GetExitCodeProcess(hprocess, &dwExitCode); // check if this is active process... // only active process will return error // code as ERROR_NO_MORE_ITEMS if( dwExitCode == ERROR_NO_MORE_ITEMS ) { //check if this process is already discovered if( IsHiddenProcess(i) ) { printf("\n Hidden process found %d", i); } } CloseHandle(hprocess); } [TABLE] [TR] [TD]Though this is very effective method, rootkit can easily defeat this technique by hooking OpenProcess or its native version NTOpenProcess function and then returning NULL with error code as ERROR_INVALID_PARAMETER. To defend against such tricks anti-rootkit softwares can call NtOpenProcess using direct system call method as shown in "Detection of Hidden Process using Direct NT System Call Implemenation".[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]HPD with CSRSS Process Handle Enumeration [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Any windows process when run will have lot of open handles realted to process, thread, named objects, file, port, registry, etc. that can be used to detect hidden process. One can use the native API function. The effective way to enumerate handles is to use NtQuerySystemInformation with first parameter as SystemHandleInformation. It lists the handles from all running processes in the system. For each enumerated handle, it provides information such as handle, handle type and process id of the owning process. Hence, by enumerating through all the handles and then using the associated process id, one can detect all possible hidden processes that are not revealed through standard API functions. There is one interesting system process called CSRSS.EXE, which holds the handles to all running processes. So instead of going through all the different handles, one can just scroll through the process handles of CSRSS.EXE process. Interestingly this method can, not only detect userland hidden processes but also some of the rootkit processes which have used kernel land techniques without taking care of hiding process handles within CSRSS.EXE process. Here is the code snippet, which can demonstrate this method: [/TD] [/TR] [/TABLE] PVOID bufHandleTable = malloc(dwSize); status = NtQuerySystemInformation (SystemHandleInformation, bufHandleTable, dwSize, 0); SYSTEM_HANDLE_INFORMATION *HandleInfo = (SYSTEM_HANDLE_INFORMATION *) bufHandleTable; // Process handles within CSRSS will not have handle // to following processes system idle process, system // process, smss.exe, csrss.exe. for(int i=0; i< HandleInfo->NumberOfHandles; i++) { int pid = HandleInfo->Handles[i].UniqueProcessId; // For XP & 2K3 : HANDLE_TYPE_PROCESS = 0x5 // For Vista & Longhorn : HANDLE_TYPE_PROCESS = 0x6 if( HandleInfo->Handles[i].ObjectTypeIndex == HANDLE_TYPE_PROCESS) { //check if this process id is that of CSRSS.EXE process. if( IsCSRSSProcess(pid) ) { hprocess = OpenProcess(PROCESS_DUP_HANDLE, false, pid); if( hprocess ) { if( DuplicateHandle(hprocess, (HANDLE)HandleInfo->Handles[i].Handle, GetCurrentProcess(), &tprocess, PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, 0)) { targetPid = GetProcessId(tprocess); //check if this is hidden process if( IsHiddenProcess(targetPid) ) { printf("\n Found hidden process %d", targetPid); } } }// End of if( hprocess ) } // End of if( IsCSRSSProcess(pid) ) } // End of if } // End of for-loop [TABLE] [TR] [TD]Since the CSRSS.EXE is not first process started when Windows boots, it does not contains handles to already started processes such as system idle process(pid=0), system process (pid=4), smss.exe and its process itself. On Windows Vista system it is possible to more than one CSRSS.EXE process in case of multiple users logged in. Same situation arises on XP system, when more than one user is operating through 'Switch User' mechanism. In such case, one has to check if the enumerated process belongs to any of these CSRSS process ids. The function IsCSRSSProcess() above does exactly the same by comparing the discovered process id with list of all running CSRSS.EXE processes. One more way is to enumerate all thread handles within CSRSS process instead of process handles, as most rootkits are aware of this technique. The CSRSS process not only has process handles but also thread handles for every running processes. Once the thread handle is known, one can use GetProcessIdOfThread function to get process id associated with that thread after duplicating it. Though any rootkit process can defeat this technique by hooking NtQuerySystemInformation or NtOpenProcess function, it can easily be circumvented by using direct implementation of these native API functions as described in the "Detection of Hidden Process using Direct NT System Call Implemenation". [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Other Methods of Detecting Hidden Processes [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] There exists several other userland methods to detect hidden rootkit processes, but they are not as effective as the ones described above. However they can be used on need basis and often to target specific rootkit. One such method is to enumerate through all the open Windows created by the processes within the system using EnumWindows API function and then calling the GetWindowThreadProcessId function to get the process id associated with that Window. Here is the sample code that does the same... [/TD] [/TR] [/TABLE] //Setup the callback function to enumerate through windows EnumWindows(EnumWindowsProc, NULL); //This is callback function to enumerate windows BOOL CALLBACK EnumWindowsProc(HWND hwnd, PARAM lParam) { DWORD procId; GetWindowThreadProcessId(hwnd, &procId); if( IsHiddenProcess(procId) ) { printf("Found hidden process %d", procId); } } There exist several other ways to detect the hidden processes in user land and new ways are being discovered everyday. Though these detection techniques can be easily defeated from kernel land, they present simple and less risky mechanism to uncover the userland rootkits. [TABLE] [TR] [TD=class: page_subheader]References [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]1. Detection of Hidden Processes 2. Hiding Rootkit process from CSRSS Handle Enumeration Method[/TD] [/TR] [TR] [TD] [/TD] [/TR] [/TABLE] Sursa: Hidden Rootkit Process Detection - www.SecurityXploded.com

Hidden Registry Detection [TABLE] [TR] [TD=class: page_subheader]Contents[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Introduction to Registry Rootkit & Reason to Hide Registry Art of Detecting Hidden Registry Keys Hidden Registry Detection using Direct NT System Call Method Hidden Registry Detection by Directly Reading Registry Hives Conclusion References [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: page_subheader]Introduction to Registry [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Registry is the large database where Windows stores all the system, security and software specific settings. It is a tree like structure, which can be viewed or modified using the standard windows utilities such as Regedit.exe (start->run-> regedit) . [/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD] In addition to all system settings, Registry also contains various startup entries for processes and services that are automatically started when Windows starts. For example, all Windows services are stored under the following Registry key, [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD="class: page_code"]'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services'. [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD]Similarly some of the startup process entries can be found in the following Registry locations, [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD="class: page_code"]HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, [B] HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\explorer\Run[/B] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Rootkit & Reason to Hide Registry [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]Rootkits generally modifies these entry points to start their own processes, services or drivers. So it's important for the Rootkit to hide these registry entries to prevent its detection from various system-monitoring tools such as Autoruns, HijackThis, etc.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] Rootkits use various methods to hide their registry infiltration. One of the most commonly used techniques is hooking the registry API functions such as RegOpenKey, RegEnumKey, RegEnumValue etc. All of these top level API functions in turn will call low level NT functions such as NTOpenKey, NtEnumerateKey and NtEnumerateValueKey etc. So in order to be more effective, Rootkits typically hook NT version of these functions. As a result whenever any application calls these registry functions, Hooked Rootkit function will return the filtered results there by hiding its presence.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Art of Detecting Hidden Registry Keys [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Most common detection mechanism used in these cases is the cross-view comparison method. In this method initially, high level registry API functions (such as RegEnumKey, RegEnumValue) are used to enumerate the keys and values. Next some of the advanced techniques are used to enumerate the same registry keys. Then the both results are compared to find out the hidden Rootkit entries. Many such lower level techniques are present to detect hidden registry keys. Here we will discuss about two such prominent methods in detail. [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader]Hidden Registry Detection using Direct NT System Call Method [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] As mentioned previously, Rootkits hide their registry entries by hooking the lower level NT functions. In order to effectively detect these entries, one can directly invoke those NT functions rather than using API functions. Every NT function in Windows is uniquely identified through its service number (For NtEnumerateKey its 0x47). So instead of calling these NT functions, one can directly call these functions by using INT 2E (for Windows 2K) or Sysenter (Windows XP onwards) instruction by passing the respective service number. Here is the direct implementation of NtEnumerateKey and NtEnumerateValueKey function, which can be directly called to bypass any API level hooks put by the Rootkits. [/TD] [/TR] [/TABLE] //For Windows XP, for other platforms only service number will differ _declspec(naked) NTSTATUS __stdcall DirectNtEnumerateKey( IN HANDLE KeyHandle, IN ULONG Index, IN KEY_INFORMATION_CLASS KeyInformationClass, OUT PVOID KeyInformation, IN ULONG KeyInformationLength, OUT PULONG ResultLength ) { __asm { mov eax, 0x47 call DirectCall_XP ret 0x18 DirectCall_XP: mov edx, esp sysenter } } //For Windows XP, for other platforms only service number will differ _declspec(naked) NTSTATUS __stdcall DirectNtEnumerateValueKey( IN HANDLE KeyHandle, IN ULONG Index, IN KEY_VALUE_INFORMATION_CLASS KeyValueInformationClass, OUT PVOID KeyValueInformation, IN ULONG KeyValueInformationLength, OUT PULONG ResultLength ) { __asm { mov eax, 0x49 call DirectCall_XP ret 0x18 DirectCall_XP: mov edx, esp sysenter } } Rootkits may also hook the NtOpenKey function to prevent any hidden key from being opened. So it will become useless even if one is able to discover the key name. In such case, one can use direct NtOpenKey function as shown below... //Note that this code is written for Windows XP. For other platforms only service number will differ _declspec(naked) NTSTATUS __stdcall DirectNtOpenKey( OUT PHANDLE KeyHandle, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes ) { __asm { mov eax, 0x77 call DirectCall_XP ret 0x0C DirectCall_XP: mov edx, esp sysenter } } [TABLE] [TR] [TD]Though Rootkits can bypass this technique by hooking the above-mentioned NT functions in the kernel, it presents simple but very effective mechanism to detect any hidden Rootkit registry entries in user land.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Hidden Registry Detection by Directly Reading Registry Hives [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] Windows stores the entire registry contents into the different files called Hives in a standard format. A different portion of registry is stored in respective hive files such as SYSTEM, SOFTWARE, SECURITY, SAM, etc. in the 'C:\Windows\System32\Config' folder. Here is the table showing the mapping between the registry section and corresponding registry hive file. [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [TABLE=class: page_code_reg_table, width: 550] [TR] [TD=class: page_cell_reg_table_header]Registry Key Name[/TD] [TD=class: page_cell_reg_table_header]Hive Filename[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_CURRENT_USER[/TD] [TD=class: page_cell_reg_table_border]NTuser.dat[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_LOCAL_MACHINE\SAM[/TD] [TD=class: page_cell_reg_table_border]SAM[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_LOCAL_MACHINE\SECURITY[/TD] [TD=class: page_cell_reg_table_border]SECURITY[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_LOCAL_MACHINE\SOFTWARE[/TD] [TD=class: page_cell_reg_table_border]SOFTWARE[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_LOCAL_MACHINE\SYSTEM[/TD] [TD=class: page_cell_reg_table_border]SYSTEM[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border]HKEY_USERS\DEFAULT[/TD] [TD=class: page_cell_reg_table_border]DEFAULT[/TD] [/TR] [TR] [TD=class: page_cell_reg_table_border][/TD] [TD=class: page_cell_reg_table_border] [/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] Though the internal format of these registry hive file is undocumented, lot of code samples and good amount of documentation can be found on the net. These hive files are generally locked while Windows is running and hence remains inaccessible. However if you like to understand internal storage structure of these hive files, you can use the API function such as RegSaveKey (or equivalent NT function NtSaveKey) to save any registry section to the chosen file. Then you can manually traverse through this hive file to decipher the low level of registry entries. Detailed code sample to traverse the hive file can be found in the article [1] 'How to avoid the detection of hidden regkey by hooking RegSaveKeyA' written by EiNSTeiN_. Also the whitepaper [2] 'Detection of Rootkits in Windows registry' by miel-labs explains in detail the complete structure of registry hive file. In this detection method, all registry entries are retrieved by traversing through these hive files. Then this list is compared against the high level list obtained through normal registry API functions such as RegEnumKey, RegEnumValue etc. At the end any additional entries discovered will be marked as Hidden Rootkit registry entries. Though this method involves using undocumented registry hive traversal method, it is very effective method in detecting the registry entries hidden through even the Kernel level hooks (such as SSDT hooks). [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]Conclusion [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]This article shows why Rootkits hide their registry entries and some of the methods which can be used to detect such hidden entries to reveal the traces of Rootkits. Though some of these techniques can be bypassed by Rootkits operating in Kernel land, these methods present very simple and powerful methods to detect any registry entries hidden by userland Rootkits.[/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD=class: page_subheader]References [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]1. How to avoid the detection of hidden regkey by hooking RegSaveKeyA 2. Detection of Rootkits in Windows registry 3. How to become unseen on Windows NT by HxDef[/TD] [/TR] [TR] [TD] [/TD] [/TR] [/TABLE] Sursa: Hidden Registry Detection - www.SecurityXploded.com

Am vazut ca incepe cu dork-uri, nu stau sa citesc pentru ca sunt sigur ca e o porcarie. Nu cauti "orice" site, vulnerabil sa fie, ori ai un motiv, ori iti vezi de treburile tale, nu ataci site-uri la intamplare de dragul de a incerca sa pari 1337.

[h=2]Protectie SMS[/h]Published on septembrie 9th, 2012 by Bogdan Alecu in Android, Securitate, SMS ?i s-a întâmplat vreodat? s? prime?ti un SMS de la un num?r care nu exist?? Ai primit mesaje de la diverse campanii electorale ce p?reau a veni din partea operatorului de telefonie? Dar mesaje cu un expeditor modificat? Sunt convins c? o parte vor r?spunde cu DA la cel pu?in una din aceste întreb?ri. Din p?cate în cazul SMS-urilor nu avem cum ?ti dac? ele vin din partea operatorului, din partea b?ncii, etc. S? ne imagin?m urm?torul scenariu: utilizatorul prime?te un mesaj venind din partea serviciului clien?i, în care este anun?at c? a câ?tigat o ma?in?. Totodat? utilizatorului i se spune s? sune la un anumit num?r pentru a confirma premiul. Num?rul poate fi cu supratax? sau nu. Sunt convins c? mul?i ar c?dea prad? acestor tipuri de mesaje. Astfel mul?i ar suna ?i ar pl?ti 2 EUR / min sau ?i-ar da datele personale întrucât, nu-i a?a, expeditorul e Serviciul Clien?i. Sau ?i mai bine hai s? ne imagin?m c? mesajul vine din partea b?ncii. Sunt nepl?cute aceste situa?ii ?i nu avem cum s? ne protej?m de ele. Ei bine, acum exist? ?i solu?ia. SMS Protect – o aplica?ie ce te anun?? în momentul primirii mesajului dac? acesta este legitim sau nu. Destul de interesant, nu? Întrucât este în varianta pre-beta ?i sunt convins c? nu va func?ia chiar perfect pe toate telefoanele a?a cum trebuie, o pute?i desc?rca ?i folosi gratuit. Disponibil? doar pe Android, versiunile de la 2.2 în sus. Cum func?ioneaz? aplica?ia? Se instaleaz? pe telefon (aten?ie c? trebuiesc acordate mai întâi permisiuni de a instala aplica?ii ce nu vin din Google Play) ?i asta e tot. În momentul în care ve?i primi un SMS, aplica?ia va afi?a în partea de jos o informare asupra acestui SMS primit – dac? e unul real sau unul fals. A?a cum spuneam, e într-o variant? simplist?, iar dac? ave?i telefonul în stand-by (ecranul oprit) ?i nu v? uita?i pe ecran imediat ce a?i primit mesajul, nu ve?i putea ?ti dac? mesajul e unul real sau nu întrucât acel tooltip de informare nu st? decât vreo 2 secunde pe ecran. Repet – asta e varianta actual?. SMS Protect func?ioneaz? pentru toate tipurile de mesaje primite: normale, WAP Push, flash, etc. Iat? ?i cum func?ioneaz? (da?i pe 720p) ATEN?IE! Aplica?ia nu con?ine niciun fel de malware. E posibil ca anumite solu?ii de protec?ie s? o raporteze ca troian, îns? nu este cazul. Am raportat deja ca fiind false positive. A?a cum a?i v?zut ?i în film, solu?ia BitDefender spune c? aplica?ia e curat?. Am de gând s? o dezvolt ?i s? ofere loguri pentru a vedea exact cine ?i când v-a trimis un mesaj fals. Cel mai probabil va fi o variant? pl?tit?, disponibil? pe Google Play. A?tept reac?iile privind SMS Protect pentru o prim? aplica?ie dezvoltat? de mine personal,?inând cont c? nu ?tiu programare, e prima dat? când fac a?a ceva iar timpul de lucru cu instalarea de la zero a masinilor de test, mediului de dezvoltare, etc a fost de aproximativ 5 ore. Sursa: Technology Blog - Protectie SMS Felicitari...

[h=2]La ce sunt bune jocurile violente pe calculator[/h]9 septembrie 2012, 11:37 | Autor: C?t?lina Mihu | 553 afi??ri De?i îndelung criticate pentru violen?a grafic? excesiv?, jocurile sângeroase pe calculator aduc ?i beneficii, conform unui studiu re recent al Universit??ii Keele, din Marea Britanie. Avantajul descoperit de cercet?torii britanici este acela c? „gamerii” care împu?c? du?mani virtuali, în jocuri, au o toleran?? la durere cu pân? la 65% mai ridicat? decât persoanele care nu au acest hobby, informeaz? Daily Mail. Cei 40 de voluntari care au participat la experimentul f?cut de Universitatea Keele au putut îndura durerea fizic? cu pân? la 65% mai mult dup? jocuri „first person shooter” (cu împu?c?turi, din perspectiva juc?torului), în compara?ie cu cei care jucaser? golf pe calculator. Participan?ii au jucat timp de 10 minute atât un joc violent, cât ?i unul pa?nic, în dou? ocazii diferite, ca parte a experimentului. Ulterior, ?i-au introdus o mân? în ap? rece ca ghea?a pentru a li se testa reac?ia la durere. În medie, voluntarii au reu?it s?-?i ?in? mâna în apa înghe?at? cu 65% mai mult dup? ce jucaser? un joc violent, „shooter”. Un alt efect înregistrat de cercet?tori a fost pulsul ridicat al acestor participan?i. Cercet?torii sugereaz?, în urma acestui experiment, c? toleran?a ridicat? la durere ?i pulsul ridicat pot fi atribuite r?spunsului natural al organismului la stress: creierul activeaz? inhibitori ai durerii. „Acest studiu ?i-a propus s? testeze presupunerea conform c?reia cre?terea nivelului agresiunii, printr-un joc video violent, va cre?te toleran?a la durere. Rezultatul confirm? presupunerile noastre c? aceste jocuri video cresc sentimentele de agresivitate ?i toleran?a la durere”, spunea Richard Stephens, doctor în psihologie ?i lector la Universitatea Keele. „Cercet?torii în domeniu au explorat deja utilizarea realit??ii virtuale pentru a ajuta oamenii s? tolereze mai u?or durerea fizic?”, cel pu?in pe termen scurt, a ad?ugat Stephens. Studiul este o continuare a unuia în acela?i domeniu, în care aceea?i echip? de cercet?tori demonstra c? înjur?turile cresc toleran?a oamenilor la durere. Sursa: La ce sunt bune jocurile violente pe calculator

[h=1]Adev?ratul "Big Brother". FBI a dezvoltat un sistem performant de identificare care te poate g?si oriunde[/h] FBI-ul a început s? ruleze oficial noul program de recunoa?tere facial? (NGI), pe care a început s?-l dezvolte în 2005 ?i în care a investit miliarde de dolari. Sistemul vine ca o completare a programului de identificare a amprentelor care ruleaz? la nivel na?ional ?i va fi instalat în toate statele pân? la finalul anului 2014, scrie rt.com. "Rolul programului NGi este de a reduce rata criminalit??ii ?i terorismul prin accesul autorit??ilor din toat? ?ara la o baz? de date cu cât mai multe informa?ii biometrice", scrie într-un comunicat FBI Oficialii FBI au declarat c? în urma testelor pe care le-au f?cut în acest an, în statul Michigan, dintr-o baz? de date de 1,6 milioane de fotografii programul a identificat corect o persoan? în 92% din cazuri. Baza de date NGI va include peste 14 milioane de fotografii în urm?torii doi ani, iar pentru o identificare cât mai exact?, programul va folosi ?i datele publice de pe re?elele sociale Facebook ?i Google. Lansarea programului NGI a stârnit ?i reac?ii negative, unii politicieni fiind de p?rere c? încalc? flagrant dreptul la intimitate: "Când cineva are amprenta ta facial?, î?i poate afla numele, î?i poate g?si conturile de pe re?elele sociale ?i poate afla în orice moment pe ce strad? e?ti sau când cineva posteaz? o fotografie cu tine online. Asta poate înc?lca dreptul la via?? privat?", a declarat senatorul american Al Franken Sursa: Adev?ratul "Big Brother". FBI a dezvoltat un sistem performant de identificare care te poate g?si oriunde - Gandul

Da, face o treaba excelenta Vivek.

uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu

zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

Test

Majoritatea a decis.

Pentru ca nu o sa fie pe RST, in banner, poza cu cine stie ce boschetar de pe aici.

[h=2]DLL Injection and Windows 8[/h]By Nagareshwar Talekar on Sep 7 2012 Recently while working on new version of RemoteDLL, I discovered interesting changes around DLL injection on Windows 8. Before I actually talk about new changes, here is little background story. CreateRemoteThread is most common method used for DLL injection. It used to work flawlessly till Windows XP. However since Vista, it changed the colors, mainly it could no more inject DLL across sessions. This was attributed to new ‘Session Separation’ feature introduced in Vista. To beat that limitation, we discovered new undocumented method NTCreateThread which could inject DLL across session boundaries on Vista/Win7. Now while testing RemoteDLL on Windows 8, I tried (halfheartedly) injecting DLL into process running in Session 0. And to my utter surprise it worked just like magic in old days. I tried again to make sure that I am not dreaming So it looks like M$ has put things back in order. The question arises whether CreateRemoteThread changes in Vista was done intently or accidentally. Because we could still use NTCreateThread with little risk. Quick analysis point us to other direction. CreateRemoteThread actually calls NTCreateThread somewhere down the layer. May be some extra checking code that was added in Vista actually caused CreateRemoteThread to exit. So it is possible that this extra code was for something else but it adversely blocked injection across sessions. Now Microsoft may have realized the problem and must have fixed it to work normally. On the other hand, CreateRemoteThread have legitimate uses and certainly some of its big customers may have made the noise To conclude, now CreateRemoteThread works well in Windows 8 across sessions (tested with consumer edition). However we still have to rely on NTCreateThread on Vista/Win7 for injection beyond session boundaries. Another notable change that I have observed is w.r.t Reference Count or Load Count for DLLs. Few years back, we have written research article ‘The covert way to find the Reference Count of DLL’ explaining about hidden/undocumented Load Count field in LDR_MODULE structure. struct _LDR_MODULE { LIST_ENTRY InLoadOrderModuleList; LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList; PVOID BaseAddress; PVOID EntryPoint; ULONG SizeOfImage; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; ULONG Flags; USHORT LoadCount; USHORT TlsIndex; LIST_ENTRY HashTableEntry; ULONG TimeDateStamp; } LDR_MODULE, *PLDR_MODULE; PEB within each process stores information on all Loaded DLLs in an linked list. Each dll in this list is represented by LDR_MODULE structure. One of the important but undocumented field here is ‘LoadCount’ (reference count of dll). This ‘Load Count’ plays an important role in deciding when the DLL has to be completely unloaded from the process. It is also useful in Removing Injected DLL from the running process. Even our tools, RemoteDLL and SpyDLLRemover use it while removing Malware DLLs from process. Here is the screenshot of RemoteDLL showing Load Count for all DLLs in selected process. As you see LoadCount for static DLL is set to -1 as usual but for dynamically loaded DLLs it is set to 6. So where the hell it has gone? It has to be somewhere as every process needs it. It is possible that LDR_MODULE structure may have changed or some of its fields may have altered or it is moved somewhere else altogether. We have to dig further. This is just the tip of iceberg, more reversing will reveal the real truths. And as I discover more, I will put it here. Meanwhile if you find any interesting things around it do share ! Sursa: DLL Injection and Windows 8 | SecurityXploded Blog

E updated acum, votati, va dati acolo cu parerea.

Votul nu este neaparat decisiv, nu stim inca ce vom face cu headerul, dar vrem sa vedem care va plac mai mult. Poate le punem aleator, nu stim inca. Votati-le pe TOATE care va plac, nu unul singur. Votati bannerele preferate: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

Cica luam virusi din filme, asa a zis un nene in filmulet

[h=1]New Attack Uses SSL/TLS Information Leak to Hijack HTTPS Sessions[/h]September 5, 2012, 1:27PM by Dennis Fisher There is a feature supported by the SSL/TLS encryption standard and used by most of the major browsers that leaks enough information about encrypted sessions to enable attackers decrypt users' supposedly protected cookies and hijack their sessions. The researchers who developed the attack that exploits this weakness say that all versions of TLS are affected, including TLS 1.2, and that the cipher suite used in the encrypted session makes no difference in the success of the attack. The attack was developed by researchers Juliano Rizzo and Thai Duong, the same pair who last year released details of a similar attack on SSL/TLS and wrote a tool called BEAST, which also gave them the ability to decrypt users' cookies and hijack sessions with sensitive sites such as e-commerce or online banking sites. That attack targeted a specific problem with the AES (Advanced Encryption Standard) algorithm as it was implemented in TLS 1.0 and SSL 3.0 and were able to use the BEAST tool to grab encrypted cookies from active user sessions that were supposedly protected by SSL/TLS. Once they had the cookie, Rizzo and Duong could return to whatever site the user was visiting and log in using her credentials. The attack caused quite a stir in the security and cryptography communities and browser vendors were forced to issue fixes. One of the workarounds that defeated BEAST (Browser Exploit Against SSL/TLS) was to switch from TLS 1.0 to TLS 1.2 or to switch from AES to the RC4 cipher suite. However, Rizzo said that defense won't work against their new attack, which they've dubbed CRIME. The researchers plan to present their findings at the Ekoparty conference in Argentina later this month and are not revealing exactly which feature of SSL/TLS is providing the information leak, but they said that the new attack works much like the BEAST attack. Once they have a man-in-the-middle position on a given network, they can sniff HTTPS traffic and launch the attack. "By running JavaScript code in the browser of the victim and sniffing HTTPS traffic, we can decrypt session cookies. We don't need to use any browser plug-in and we use JavaScript to make the attack faster but in theory we could do it with static HTML," Rizzo said. Right now, Rizzo said, both Mozilla Firefox and Google Chrome are vulnerable to the attack. However, the researchers said that the browser vendors have developed patches for the problem that will be released in the next few weeks. "We need to load JavaScript code into the victim's browser and sniff the HTTPS traffic. All SSL/TLS versions including TLS 1.2 are affected if the implementation supports the feature that we abuse to leak information about the encrypted data," Rizzo said. "The cipher-suite being used doesn't matter, a workaround for BEAST was switching from AES to RC4 but for CRIME this is not important. The feature must be supported by the client and the server." Rizzo said that the specific feature in TLS that he and Duong are using in this attack has not been a major subject of security research in the past. "The risk of implementing the feature has been superficially discussed before. However we haven't found previous research showing how efficient an attack could be or any attempt by the authors of secure protocols to avoid the problem," he said. Although the CRIME attack can use JavaScript, it's not required. Rizzo said that it really shouldn't be possible to hijack a user's session with one site just by loading JavaScript into the victim's browser from a separate site. But that's exactly what the new attack allows him to do. In addition to their work developing the BEAST attack, Rizzo and Duong in 2011 also developed a padding oracle attack on Microsoft's ASP.NET that affected millions of applications and forced the software giant to issue an emergency patch. Sursa: New Attack Uses SSL/TLS Information Leak to Hijack HTTPS Sessions | threatpost

Mai veniti cu idei, mai multe variante de banner, diseara punem la vot si il alegem.

The Shellcoder’s Handbook Discovering and Exploiting Security Holes Second Edition Chris Anley John Heasman Felix “FX” Linder Gerardo Richarte The Shellcoder’s Handbook: Discovering and Exploiting Security Holes (1st Edition) was written by Jack Koziol, David Litchfield, Dave Aitel, Chris Anley, Sinan Eren, Neel Mehta, and Riley Hassell. "This book is dedicated to anyone and everyone who understands that hacking and learning is a way to live your life, not a day job or semi-ordered list of instructions found in a thick book." About the Authors vii Acknowledgments xi Introduction to the Second Edition xxiii Part I Introduction to Exploitation: Linux on x86 Chapter 1 Before You Begin 3 Basic Concepts 3 Memory Management 4 Assembly 6 Recognizing C and C++ Code Constructs in Assembly 7 Conclusion 10 Chapter 2 Stack Overflows 11 Buffers 12 The Stack 13 Functions and the Stack 15 Overflowing Buffers on the Stack 18 Controlling EIP 22 An Interesting Diversion 23 Using an Exploit to Get Root Privileges 25 The Address Problem 27 The NOP Method 33 Defeating a Non-Executable Stack 35 Return to libc 35 Conclusion 39 Chapter 3 Shellcode 41 Understanding System Calls 42 Writing Shellcode for the exit() Syscall 44 Injectable Shellcode 48 Spawning a Shell 50 Conclusion 59 Chapter 4 Introduction to Format String Bugs 61 Prerequisites 61 What Is a Format String? 61 What Is a Format String Bug? 63 Format String Exploits 68 Crashing Services 69 Information Leakage 70 Controlling Execution for Exploitation 75 Why Did This Happen? 84 Format String Technique Roundup 85 Conclusion 88 Chapter 5 Introduction to Heap Overflows 89 What Is a Heap? 90 How a Heap Works 91 Finding Heap Overflows 91 Basic Heap Overflows 93 Intermediate Heap Overflows 98 Advanced Heap Overflow Exploitation 105 Conclusion 107 Part II Other Platforms—Windows, Solaris, OS/X, and Cisco Chapter 6 The Wild World of Windows 111 How Does Windows Differ from Linux? 111 Win32 API and PE-COFF 112 Heaps 114 Threading 115 The Genius and Idiocy of the Distributed Common Object Model and DCE-RPC 116 Recon 118 Exploitation 120 Tokens and Impersonation 120 Exception Handling under Win32 122 Debugging Windows 124 Bugs in Win32 124 Writing Windows Shellcode 125 A Hacker’s Guide to the Win32 API 126 A Windows Family Tree from the Hacker’s Perspective 126 Conclusion 127 Chapter 7 Windows Shellcode 129 Syntax and Filters 129 Setting Up 131 Parsing the PEB 132 Heapoverflow.c Analysis 132 Searching with Windows Exception Handling 148 Popping a Shell 153 Why You Should Never Pop a Shell on Windows 153 Conclusion 154 Chapter 8 Windows Overflows 155 Stack-Based Buffer Overflows 156 Frame-Based Exception Handlers 156 Abusing Frame-Based Exception Handling on Windows 2003 Server 161 A Final Note about Frame-Based Handler Overwrites 166 Stack Protection and Windows 2003 Server 166 Heap-Based Buffer Overflows 173 The Process Heap 173 Dynamic Heaps 173 Working with the Heap 173 How the Heap Works 174 Exploiting Heap-Based Overflows 178 Overwrite Pointer to RtlEnterCriticalSection in the PEB 178 Overwrite Pointer to Unhandled Exception Filter 185 Repairing the Heap 191 Other Aspects of Heap-Based Overflows 193 Wrapping Up the Heap 194 Other Overflows 194 .data Section Overflows 194 TEB/PEB Overflows 196 Exploiting Buffer Overflows and Non-Executable Stacks 197 Conclusion 203 Chapter 9 Overcoming Filters 205 Writing Exploits for Use with an Alphanumeric Filter 205 Writing Exploits for Use with a Unicode Filter 209 What Is Unicode? 210 Converting from ASCII to Unicode 210 Exploiting Unicode-Based Vulnerabilities 211 The Available Instruction Set in Unicode Exploits 212 The Venetian Method 213 An ASCII Venetian Implementation 214 Decoder and Decoding 218 The Decoder Code 219 Getting a Fix on the Buffer Address 220 Conclusion 221 Chapter 10 Introduction to Solaris Exploitation 223 Introduction to the SPARC Architecture 224 Registers and Register Windows 224 The Delay Slot 227 Synthetic Instructions 228 Solaris/SPARC Shellcode Basics 228 Self-Location Determination and SPARC Shellcode 228 Simple SPARC exec Shellcode 229 Useful System Calls on Solaris 230 NOP and Padding Instructions 231 Solaris/SPARC Stack Frame Introduction 231 Stack-Based Overflow Methodologies 232 Arbitrary Size Overflow 232 Register Windows and Stack Overflow Complications 233 Other Complicating Factors 233 Possible Solutions 234 Off-By-One Stack Overflow Vulnerabilities 234 Shellcode Locations 235 Stack Overflow Exploitation In Action 236 The Vulnerable Program 236 The Exploit 238 Heap-Based Overflows on Solaris/SPARC 241 Solaris System V Heap Introduction 242 Heap Tree Structure 242 Basic Exploit Methodology (t_delete) 263 Standard Heap Overflow Limitations 266 Targets for Overwrite 267 Other Heap-Related Vulnerabilities 270 Off-by-One Overflows 270 Double Free Vulnerabilities 270 Arbitrary Free Vulnerabilities 271 Heap Overflow Example 271 The Vulnerable Program 272 Other Solaris Exploitation Techniques 276 Static Data Overflows 276 Bypassing the Non-Executable Stack Protection 276 Conclusion 277 Chapter 11 Advanced Solaris Exploitation 279 Single Stepping the Dynamic Linker 281 Various Style Tricks for Solaris SPARC Heap Overflows 296 Advanced Solaris/SPARC Shellcode 299 Conclusion 311 Chapter 12 OS X Shellcode 313 OS X Is Just BSD, Right? 314 Is OS X Open Source? 314 OS X for the Unix-aware 315 Password Cracking 316 OS X PowerPC Shellcode 316 OS X Intel Shellcode 324 Example Shellcode 326 ret2libc 327 ret2str(l)cpy 329 OS X Cross-Platform Shellcode 332 OS X Heap Exploitation 333 Bug Hunting on OS X 335 Some Interesting Bugs 335 Essential Reading for OS X Exploits 337 Conclusion 338 Chapter 13 Cisco IOS Exploitation 339 An Overview of Cisco IOS 339 Hardware Platforms 340 Software Packages 340 IOS System Architecture 343 Vulnerabilities in Cisco IOS 346 Protocol Parsing Code 347 Services on the Router 347 Security Features 348 The Command-Line Interface 348 Reverse Engineering IOS 349 Taking the Images Apart 349 Diffing IOS Images 350 Runtime Analysis 351 Exploiting Cisco IOS 357 Stack Overflows 357 Heap Overflows 359 Shellcodes 364 Conclusion 373 Chapter 14 Protection Mechanisms 375 Protections 375 Non-Executable Stack 376 W^X (Either Writable or Executable) Memory 381 Stack Data Protection 388 AAAS: ASCII Armored Address Space 394 ASLR: Address Space Layout Randomization 396 Heap Protections 399 Windows SEH Protections 407 Other Protections 411 Implementation Differences 413 Windows 413 Linux 417 OpenBSD 421 Mac OS X 422 Solaris 423 Conclusion 425 Part III Vulnerability Discovery Chapter 15 Establishing a Working Environment 429 What You Need for Reference 430 What You Need for Code 430 gcc 430 gdb 430 NASM 431 WinDbg 431 OllyDbg 431 Visual C++ 431 Python 432 What You Need for Investigation 432 Useful Custom Scripts/Tools 432 All Platforms 434 Unix 434 Windows 435 What You Need to Know 436 Paper Archives 438 Optimizing Shellcode Development 439 Plan the Exploit 439 Write the Shellcode in Inline Assembler 439 Maintain a Shellcode Library 441 Make It Continue Nicely 441 Make the Exploit Stable 442 Make It Steal the Connection 443 Conclusion 443 Chapter 16 Fault Injection 445 Design Overview 447 Input Generation 447 Fault Injection 450 Modification Engines 450 Fault Delivery 455 Nagel Algorithm 455 Timing 455 Heuristics 456 Stateless versus State-Based Protocols 456 Fault Monitoring 456 Using a Debugger 457 FaultMon 457 Putting It Together 458 Conclusion 459 Chapter 17 The Art of Fuzzing 461 General Theory of Fuzzing 461 Static Analysis versus Fuzzing 466 Fuzzing Is Scalable 466 Weaknesses in Fuzzers 468 Modeling Arbitrary Network Protocols 469 Other Fuzzer Possibilities 469 Bit Flipping 469 Modifying Open Source Programs 470 Fuzzing with Dynamic Analysis 470 SPIKE 471 What Is a Spike? 471 Why Use the SPIKE Data Structure to Model Network Protocols? 472 Other Fuzzers 480 Conclusion 480 Chapter 18 Source Code Auditing: Finding Vulnerabilities in C-Based Languages 481 Tools 482 Cscope 482 Ctags 483 Editors 483 Cbrowser 484 Automated Source Code Analysis Tools 484 Methodology 485 Top-Down (Specific) Approach 485 Bottom-Up Approach 485 Selective Approach 485 Vulnerability Classes 486 Generic Logic Errors 486 (Almost) Extinct Bug Classes 487 Format Strings 487 Generic Incorrect Bounds-Checking 489 Loop Constructs 490 Off-by-One Vulnerabilities 490 Non-Null Termination Issues 492 Skipping Null-Termination Issues 493 Signed Comparison Vulnerabilities 494 Integer-Related Vulnerabilities 495 Different-Sized Integer Conversions 497 Double Free Vulnerabilities 498 Out-of-Scope Memory Usage Vulnerabilities 499 Uninitialized Variable Usage 499 Use After Free Vulnerabilities 500 Multithreaded Issues and Re-Entrant Safe Code 500 Beyond Recognition: A Real Vulnerability versus a Bug 501 Conclusion 501 Chapter 19 Instrumented Investigation: A Manual Approach 503 Philosophy 503 Oracle extproc Overflow 504 Common Architectural Failures 508 Problems Happen at Boundaries 508 Problems Happen When Data Is Translated 509 Problems Cluster in Areas of Asymmetry 511 Problems Occur When Authentication and Authorization Are Confused 512 Problems Occur in the Dumbest Places 512 Bypassing Input Validation and Attack Detection 513 Stripping Bad Data 513 Using Alternate Encodings 514 Using File-Handling Features 515 Evading Attack Signatures 517 Defeating Length Limitations 517 Windows 2000 SNMP DOS 520 Finding DOS Attacks 521 SQL-UDP 522 Conclusion 523 Chapter 20 Tracing for Vulnerabilities 525 Overview 526 A Vulnerable Program 527 Component Design 529 Building VulnTrace 538 Using VulnTrace 543 Advanced Techniques 546 Conclusion 548 Chapter 21 Binary Auditing: Hacking Closed Source Software 549 Binary versus Source-Code Auditing: The Obvious Differences 550 IDA Pro—The Tool of the Trade 550 Features: A Quick Crash Course 551 Debugging Symbols 552 Binary Auditing Introduction 552 Stack Frames 552 Calling Conventions 554 Compiler-Generated Code 556 memcpy-Like Code Constructs 560 strlen-Like Code Constructs 560 C++ Code Constructs 561 The this Pointer 561 Reconstructing Class Definitions 562 vtables 562 Quick but Useful Tidbits 563 Manual Binary Analysis 563 Quick Examination of Library Calls 564 Suspicious Loops and Write Instructions 564 Higher-Level Understanding and Logic Bugs 565 Graphical Analysis of Binaries 566 Manual Decompilation 566 Binary Vulnerability Examples 566 Microsoft SQL Server Bugs 566 LSD’s RPC-DCOM Vulnerability 567 IIS WebDAV Vulnerability 568 Conclusion 570 Part IV Advanced Materials Chapter 22 Alternative Payload Strategies 573 Modifying the Program 574 The SQL Server 3-Byte Patch 575 The MySQL 1-Bit Patch 578 OpenSSH RSA Authentication Patch 580 Other Runtime Patching Ideas 581 GPG 1.2.2 Randomness Patch 583 Upload and Run (or Proglet Server) 584 Syscall Proxies 584 Problems with Syscall Proxies 587 Conclusion 596 Chapter 23 Writing Exploits that Work in the Wild 597 Factors in Unreliability 597 Magic Numbers 597 Versioning 598 Shellcode Problems 599 Countermeasures 601 Preparation 602 Brute Forcing 602 Local Exploits 603 OS/Application Fingerprinting 603 Information Leaks 605 Conclusion 606 Chapter 24 Attacking Database Software 607 Network Layer Attacks 608 Application Layer Attacks 618 Running Operating System Commands 619 Microsoft SQL Server 619 Oracle 620 IBM DB2 621 Exploiting Overruns at the SQL Level 623 SQL Functions 623 Conclusion 625 Chapter 25 Unix Kernel Overflows 627 Kernel Vulnerability Types 627 0day Kernel Vulnerabilities 636 OpenBSD exec_ibcs2_coff_prep_zmagic() Stack Overflow 636 The Vulnerability 638 Solaris vfs_getvfssw() Loadable Kernel Module Traversal Vulnerability 642 The sysfs() System Call 644 The mount() System Call 645 Conclusion 646 Chapter 26 Exploiting Unix Kernel Vulnerabilities 647 The exec_ibcs2_coff_prep_zmagic() Vulnerability 647 Calculating Offsets and Breakpoints 652 Overwriting the Return Address and Redirecting Execution 654 Locating the Process Descriptor (or the Proc Structure) 655 Kernel Mode Payload Creation 658 Returning Back from Kernel Payload 659 Getting root (uid=0) 665 Solaris vfs_getvfssw() Loadable Kernel Module Path Traversal Exploit 672 Crafting the Exploit 673 The Kernel Module to Load 674 Getting root (uid=0) 678 Conclusion 678 Chapter 27 Hacking the Windows Kernel 681 Windows Kernel Mode Flaws—An Increasingly Hunted Species 681 Introduction to the Windows Kernel 682 Common Kernel-Mode Programming Flaws 683 Stack Overflows 684 Heap Overflows 688 Insufficient Validation of User-Mode Addresses 688 Repurposing Attacks 689 Shared Object Attacks 689 Windows System Calls 690 Understanding System Calls 690 Attacking System Calls 692 Communicating with Device Drivers 693 I/O Control Code Components 693 Finding Flaws in IOCTL Handlers 694 Kernel-Mode Payloads 695 Elevating a User-Mode Process 696 Running an Arbitrary User-Mode Payload 699 Subverting Kernel Security 701 Installing a Rootkit 703 Essential Reading for Kernel Shellcoders 703 Conclusion 704 Index 705 Download: http://www.filehost.ro/28851249/the_shellcoders_handbook_pdf/ http://www.sendspace.com/file/efarp3 http://www.filetransfer.ro/bM5gyv

Ziceai ca se poate ceva, astept un demo...

Nu trebuie sa fie pe placul tuturor, trebuie sa fie pe placul meu