Tag Info

Hot answers tagged

36

Address Space Layout Randomisation (ASLR) is a technology used to help prevent shellcode from being successful. It does this by randomly offsetting the location of modules and certain in-memory structures. Data Execution Prevention (DEP) prevents certain memory sectors, e.g. the stack, from being executed. When combined it becomes exceedingly difficult to ...


28

The Linux kernel can be viewed as a kind of ultimate shell code, since it is "injected" on a raw machine (which only has the BIOS code at that point) and then provides a lot of functionality. That kernel is written in C. If you write shell code in C or C++, you will run into trouble with library calls and linking, which are two facets of the same issue. ...


18

It is perfectly valid to write shellcode in any language that gets compiled down to machine code instructions. Provided no external libraries that are not linked by the victim program are required for its operation. However, it is almost never the case that directly compiled code (even from just C) is a valid, injectable shellcode. The most common reason ...


17

To complement @Polynomial's self-answer: DEP can actually be enforced on older x86 machines (which predate the NX bit), but at a price. The easy but limited way to do DEP on old x86 hardware is to use segment registers. With current operating systems on such systems, addresses are 32-bit values in a flat 4 GB address space, but internally each memory access ...


9

In assembly code, NOP is short for No OPeration. This is most popularly known for x86 chips as 0x90. When a processor loads that instruction, it simply does nothing (at least useful) for the one cycle and then advances the register to the next instruction. NOPs keep the payload sizes consistent ... by ensuring that any space not used by other code ...


9

It's not clear what you're asking, but a researcher likely analysed the Javascript code line by line. In doing so they saw the string "WinNT" and "Firefox", which is who the Javascript is targeting. Linux VMs, exe analysis tools are anecdotal and don't focus on the core target: Windows machines running Firefox with ToR. The Firefox version must be old ...


7

The NX bit is a feature of the Memory Management Unit of some CPU (including recent enough x86). It allows to mark each memory page as being "allowed" or "disallowed" for code execution. The MMU is under control of the kernel; the kernel code decides which pages get the execution privilege and which do not. Therefore, whether the stack space is protected ...


6

If you are stepping through one instruction at a time, and the segfault occurs immediately upon jumping (and not when hitting some potentially broken shellcode at the end of the NOP sled, which could also cause a segfault), and you are certain that the address is correct, points to valid memory and that your NOP sled itself isn't broken, then yes it seems ...


5

You do not call functions inside the kernel. The kernel resides in another privilege level; its memory pages are not accessible from normal code. To jump into kernel code, application code performs a system call which entails using a specific doorway which handles the temporary privilege escalation. On a 32-bit x86 system running Linux, this is done with int ...


5

"Leaky Pointers" or more commonly known as "Dangling Pointers" is useful to create an attack chain to bypass a layered security system. The idea behind DEP is that you are making regions of memory non-executable, such that shellcode in this area cannot be executed. DEP alone is really easy to bypass, you can just ret-to-lib, and call any function you ...


5

It is very unlikely that this would be a viable route to dropping a web shell. The input is probably stored in a database, not in a file, so the interpreter (ASP, PHP, etc) will not process it as source code. A much more likely attack vector is Cross Site Scripting, if the filter is not strict enough. EDIT to answer 2 points added later: There is no way ...


5

You don't always have to overwrite the return address in order to exploit a stack based buffer overflow (also has a great diagram of the stack layout). With a stack based buffer overflow you can corrupt other variables declared in the local scope of the function which can produce interesting results. For instance lets say there is an authentication ...


5

There are two "unknowns" that the attacker has to contend with. First, the attacker is overflowing a buffer, supposedly on the stack, and among the bytes which follow the buffer in RAM are the bytes which store the "return address" where execution jumps after the current function is finished. The attacker wants to overwrite these bytes with another address, ...


4

That's the other way round: you overflow a stack buffer so that you get to overwrite the field with which EIP will be loaded when the function returns. In usual architectures, the stack grows downwards, so that the "return address" pushed on the stack when the function was called lies a few bytes after the local variables. By overflowing a local buffer, you ...


4

A stack canary is still a problem, because you cannot control the EIP in a stack based buffer overflow without overwriting the return address (which is above the carny). Further more the function that contained the stack based buffer overflow must return before the corrupted return address becomes the new EIP. This is not a problem for dangling pointers. ...


4

By marking the stack as non-execute, you effectively prevent code inserted into the stack from running. You're not protecting the stack from modification; rather, you're causing a hard crash when the code attempts to jump to a position in the NX-marked stack. The workaround is to not attempt to execute code on the stack. Instead of setting the return ...


4

There's no way to tell directly from that actual test, there's no enough information. However, you could tell whether the exploit works or not by telling the target system to do something that it is allowed to do, for instance browse to a web server under your control (presuming that any outbound web connectivity is allowed). If you command it to get a ...


4

Short version: Shell scripts require more caution with untrusted input; there are inherent dangers. Shell scripts are not general purpose languages, and are probably unsuited for "parsing untrusted data over networks" All that said, shell scripts can do amazing amounts of things, and can do it securely with enough care. Should is a different matter, and ...


3

This is not obfuscated code, it is just base64. You can decode it on this site. It is an email containing a flight reservation confirmation. I don't know if it should be publicly available, maybe you should edit your post. You can read more about email encoding here.


3

Yes it's still worth learning. People who are in the early stages of learning exploit development are not going to come out of the gate knowing everything. It's good to use the buffer overflow, that you reference and shell code writing to get ppl's interest piqued and to use as a stepping stone to becoming a professional exploit developer. You never know, ...


3

How do you start analysis? Do you start at main and spread out from there, or do you have a better method? Start on exhausting basic analysis (both dynamic and static) - enumerate exports, imports, function use, syscalls, winapi, mutex, dll dependencies, strings and some grepping on that. Run dynamic analysis on basic sandboxes to come to some, ...


3

SafeSEH is a mechanism that protects stack-based exception handler chains from being overwritten. However, on x64 and Itanium architectures, the exception handlers are table-based (i.e. stored in PDATA) and therefore cannot be overwritten directly by a stack buffer overflow - they're simply not on the stack. As such, SafeSEH is irrelevant to those systems.


3

Your memcpy utilization needs a review - please follow: Your original post: memcpy(buffer+(sizeof(buffer)-1)/2,shellcode,strlen(shellcode)); For starters, you use buffer without referring to it as a pointer - &buffer actually, there are some compiler that can handle it, so it's not necessarily what stops you from exploiting the stack. Now, you try to ...


3

You could begin looking at Symantec: http://www.symantec.com/connect/articles/windows-anti-debug-reference And there is a question in Stackoverflow about anti-debugging tricks.


3

NOPs tend to get flagged by anti-virus, so an alternate method can be used to 'slide' the execution to the shell code. The way you were told was to add 1500 bytes to the ESP, which (I'm assuming) should replace 1500 NOPs, landing you at your shellcode. If you have not already seen this, you NEED to be reading corelan.be for awesome BO writing tutorials. ...


3

Assuming you have located a buffer overrun (or equivalent), If the machine code doesn't match the language of the remote machine, then the expected result is that the application with the overrun will crash. The overrun will operate as 'normal', trying to execute the code in your binary blob of a payload. The victim system will attempt to execute the ...


3

As an addition to GdD's answer, have the "payload" try several things, since you'd have no idea about finding out if your code / exploit was actually executed. A range of things could be one of the following: fetch a webpage using the system's browser settings' proxy send an email to an outside address. If you have nearby access to the infected ...


3

I am asking from perspective of someone who writes shell scripts that parse untrusted input I would not recommend any of these shells to parse untrusted input, because it is far to easy to make errors with the shell syntax which can cause unwanted command execution. This is not a problem how secure the implementation of the shell itself is, but how ...



Only top voted, non community-wiki answers of a minimum length are eligible