Tag Info

Hot answers tagged

47

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. ...


19

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 ...


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 ...


14

I would enable auditd to monitor changes to the files you expect to be backdoored. You will be able to determine which account and process that is responsible for doing these changes. After installing auditd (not installed pr default on all systems), you can start monitoring changes in files. To do this, simply run the command: auditctl -w /var/www -p wa ...


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 ...


9

I originally posted this as a comment, but I think this could do with a little explanation. From my experience with website takeover scenarios, when a shell is uploaded to a website, the hacker either manages to exploit a vulnerability in the server, gain root access, backdoor your SSH and compromise all other sites on the server, or he simply doesn't ...


8

"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 ...


8

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 ...


7

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 ...


6

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 ...


6

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, ...


6

I've had a very similar thing happen to a site I manage. After much frustration of deleting the malicious code and then it appearing about 2 weeks later, I discovered this: I took note of the date stamp of when all the files got modified, then I looked up the access log for that minute. I saw a certain page was requested that seemed suspicious, since it was ...


6

Vulnerable programs need to listen to ports in order to access them over the network directly. But, you could gain access to the system through other means then exploit a vulnerable program that does not access the network (e.g. email malware that triggers a vulnerability in a PDF reader) Knowing how the vulnerable program behaves predictably is the key to ...


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

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 ...


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 ...


4

It sounds like the attackers have installed a rootkit on your server. A rootkit can provide a backdoor even if everything looks clean. The best approach now in my opinion would be to wipe the server and reinstall from scratch. Patch the websites to eliminate the vulnerability. If you need to restore from backup (you have backups, right? :) ) make sure it's ...


4

The mistake isn't how you validate the file. You should never execute any file that is uploaded. Full stop. If an uploaded file is supposed to be an image, then the only thing you should do with it is present it to an image processing program to be opened. In a sense, the entire desktop paradigm of guessing the correct program to open a file by looking ...


4

It is ultimately going to be a web shell that provides command execution. The relevant code/strings are shown here.. shellinvoker.war shellinvoker.jsp <%@ page import="java.util.*,java.io.*"%><pre><%if(request.getParameter("ppp") != null && request.getHeader("user-agent").equals("jexboss") ) { Process p = ...


3

So far the answers have mentioned only the knowledge part that one gains from learning how to shell code. However, shell code knowledge is required for performing real world attacks and the knowledge is used by the attackers for remaining stealthy as well as for performing a task specific to a particular environment. In order to give an example, look ...


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, ...



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