I had made a multiclient TCP reverse shell and saw a course video which said HTTP reverse shells are better because how its difficult to trace back to the attacker compared to TCP . I didn't understand it .
I have tried googling this question with not much help .
Are HTTP reverse shells actually beneficial over TCP ? How ?
I personally think having HTTP reverse shell is bad since http is connectionless , when the attacker wants to communicate with the host , it can't since there is no connection to it and attacker can only communicate if a request (like GET) comes from the host. Am I missing anything here ?
Please explain....
First, I am just going to answer for HTTPS over HTTP because I don't see much reason to use HTTP over HTTPS, but there are a lot of benefits to encrypting your traffic this way.
It's unlikely to be auto-filtered
Many networks will block outbound traffic other than a few special ports. So, using something like port 6666 is likely to set off a few alerts. If you try to use a port for something other than it's intended use, some software can use deep packet inspection (DPI) to detect/block this. In other words, if your payload tries to use port 80/443 without using HTTP/HTTPS, it may raise an alert and get your payload caught.
It's stealthier.
I would say two of the most important factors to being a stealthy payload are looking like normal traffic so as to avoid attracting attention in the first place and to be difficult to inspect if attention does come to your connection. HTTPS accomplishes both of these rather well.
This is because on most networks, it is extremely common to see nodes on your network making requests to the internet all the time. Compare a beaconing payload making HTTPS requests to some payload connecting over some random port.
Now, as far as your question at the end... it depends on your situation, but you are right that there will often be a delay if you use something like HTTP(S) over maintaining an established connection. I alluded to this earlier, but we are able to communicate through beaconing. Essentially, that just means that the payload will check back with the server on a set interval (often with a jitter to make it a little harder to detect).
The victim will make an HTTP(S) request to your command and control (C2) server that contains the results of the previous command you told it to run. Your server will return an HTTP(S) response that contains the next instructions for the payload.
Related
I am wondering about the difference between HTTP and TCP data transfer protocols for online games.
I have heard many people using TCP or UDP to transfer data between client and server for online games.
But can you use http at all? I know http is mostly used for web browsing, but if I could set up web server and let my game applications use GET and POST methods, I can still send data back and forth right? Is it that this way of communicating is too slow or unnecessary?
And just one thing about TCP transmission protocols, if I were to write some gaming application using TCP, is it that the data are usually transferred using something called "sockets" (like Socket classes in Java)? What about UDP?
Thanks very much!
Appreciate any answer!
HTTP is an additional layer on top of TCP that defines what a request looks like, what a response looks like, and how the connection is closed or maintained across requests. You can either use it or not use it, depending on what you actually need to transport. If your game consists of a series of requests that each get a reply, HTTP might make sense. If it's more like unsolicited messages in each direction, making HTTP work is like putting a square peg in a round hole.
Most platforms provide a socket interface that allows you to work with either TCP or UDP depending on the protocol specified when the socket is allocated. Some higher-level APIs look completely different for different protocols.
I am trying to write my own HTTP proxy server and I have a question about the protocol.
First, I would like to mention that I am using this page as a reference. I think it's accurate but it's also from 1998. If anyone has a better reference for me I would be grateful to them.
So basically I understand that the connection starts with a handshake. I receive a CONNECT request, proxy-authorization, etc. Then I connect to the host and port specified in the request's resource URI. Then I send a status line, ideally HTTP/1.1 200 Connection established, followed by some headers and a CRLF like normal.
Once this handshake is complete my client and the host my client asked for are connected through my proxy server. I am supposed to tunnel data in both directions, which makes sense since I could be supporting any type of TCP based protocol, including HTTPS or even WebSocket, over this HTTP based proxy connection.
What doesn't make sense to me is how I know when to stop. If this proxy can really support any TCP based protocol then I don't understand how to know when the interaction is over. An HTTP message would be a simple 2 step read-write, an HTTPS interaction would involve several such exchanges, and a WebSocket interaction would involve indefinitely many exchanges.
I'm not asking for a perfect solution. I would be happy with something pragmatic like a timeout, but I would like to know what standard best practices are in order to do this project as well as I can.
Thanks to everyone for any help.
Just copy data in both directions simultaneously until you read an end of stream. Then:
Shutdown the opposite socket for writing and stop copying in that direction. That propagates the EOS to the peer.
If the socket you read EOS from was already shutdown for writing, which you will have to remember, close both sockets.
I was considering doing a chat server using node.js/socket.io. Should I make it a tcp server or a http server? I'd imagine tcp server would be more efficient, but can you send other stuff to it like file attachments etc? If tcp is more efficient, how much more so? Also, just wondering how many concurrent connections can one node.js server handle? Is it more work to do TCP or HTTP?
You are talking about 2 totally different approaches here - TCP is a transport layer protocol and HTTP is an application layer protocol. HTTP (usually) operates over TCP, so whichever option you choose, it will still be operating over TCP.
The efficiency question is sort of a moot point, because you are talking about different OSI layers. If you went for raw TCP sockets, your solution would probably be more efficient - in bandwidth at least - since HTTP contains a whole bunch of extra data (the headers) that would likely be irrelevant to your purposes (depending on the scale of the chat program). What you are talking about developing there is your own application layer protocol.
You can send anything you like over TCP - after all HTTP can send attachments, and that operates over TCP. FTP also operates over TCP, and that is designed purely for transferring "attachments". In order to do this, you would need to write your protocol so that it was able to tell the remote party that the following data was a file, then send the file data, then tell the remote party that the transfer is complete. Implementations of this are many and varied (the HTTP approach is completely different from the FTP approach) and your options are pretty much infinite.
I don't know for sure about the node.js connection limit, but I can say with a fair amount of confidence that it is limited by the operating system. This might help you get to grips with the answer to that question.
It is debatable whether it is more work to do it with TCP or HTTP - it's a lot of work to do it in both. I would probably lean more toward the TCP option being your best bet. While TCP would require you to design a protocol rather than/as well as an application, HTTP is not particularly suited to live, 2-way applications like chat servers. There are many implementations of chat over HTTP that use AJAX, but I can tell you from painful experience that they are a complete pain in the rear-end.
I would say that you should only be looking at HTTP if you are intending the endpoint (i.e. the client) to be a browser. If you are going to write a desktop app for the endpoint, a direct TCP link would definitely be the way to go. The main reason for this is that HTTP works in a request-response manner, where the client sends a request to the server, and the server responds. Over TCP you can open a single TCP stream, that can be used for bi-directional communication. This means that the server can push an event to the client instantly, while over HTTP you have to wait for the client to send a request, so you can respond with an event. If you were intending to use a browser as the client, it will make the whole file transfer thing much more tricky (the sending at least).
There are ways to implement this over HTTP using long-polling and server push (read this) but it can be a real pain to implement.
If you are going to implement this on a LAN (or possibly even over the internet) it is worth considering UDP over TCP - in a chat application it is not usually absolutely mission critical that messages arrive in the right order, and even if it was, users would probably not be able to type faster than the variations in network latency (probably <100ms). Then for file transfers you could either negotiate a seperate TCP socket for the data exchange (like FTP), or implement some kind of UDP ACK system (like TFTP).
I feel there is a lot more to say on this subject but right now I can't put it into words - I may extend this answer at some point.
Chat servers are the Hello World program in node. Use http.
As far as the question of how many concurrent connections can it handle, that all depends on your system. Set up a simple chat server and then try benchmarking it.
Also, check out http://search.npmjs.org/ and search for chat for a few pointers.
I began to study protocol stuffs recently.
I acknowledged that in the old method, incoming data will be first delivered to SSL proxy, where to be decrypted and then be sent to HTTP proxy through another TCP connection. For every packet passes through this connection, we need to do a connection table to look up to determine the other endpoint of the connection.
But the pipe setup and teardown require one function call each and no packet sent. Sending data through the pipe will not require a connection table lookup, as the data structures are already tied together with pointers.
I tried to search the answer of my own question, but can’t find good method to understand it. I guess there may be something related to structure of TCP or PIPE. Could any tell me that why exactly pipe is simple than TCP connection between SSL proxy and HTTP proxy? Or please suggest me what book to read or how can I understand it?
Two Pics related to this question:
http://www.tripntale.com/pic/19254/857880/pipe-jpg#pid-857880
http://www.tripntale.com/pic/19254/857880/pipe-jpg#pid-857882
So what you want to know is how these two diagrams compare?
I'm sorry to say that these diagrams don't make much sense to me either, hopefully they do make sense if there's the text to go with them when they were published.
The diagrams relate to software engineering approaches to a problem, but the objects in the diagrams aren't defined functionally, appear to me to be used in different ways and it isn't clear what the problem is that these are approaches to.
HTTP proxies can be used as:
Forward proxies (client sends it's HTTP requests to proxy, proxy fetches and returns them to client)
Or
Reverse proxies (proxy sits in front of server(s) for service engineering reasons)
The term "SSL Proxy" could refer to either application and would have differing implications to how it was designed.
See here for more explanation: http://en.wikipedia.org/wiki/SSL_Proxy
Do you just want to understand these diagrams? Or are you trying to solve a problem and think that these diagrams can help you? If so, what is the problem you are trying to solve?
For every packet passes through this connection, we need to do a
connection table
Why? I've written several proxies without a connection table.
I have some software which runs as a black box, I have no access to it. This software makes HTTP requests. What I want to do is intercept these requests, forward them on, catch the response, do something with it, before passing the response back to the software.
Can this be done? What's the best method?
Thanks
Edit: Requests are to the public internet from a local intranet via a gateway/router. I have root access to my machine. Another machine could be used as intermediate gateway.
Edit 2: Requests are not encrypted. What I am actually trying to do is save down any images that are requested.
Try yellosoft-alchemy.
If the communication isn't encrypted, use Ethereal (or any other similar program) to sniff the communication on the wire.
edit: since the communication isn't encrypted, you can do that easily with Ethereal. You can save each TCP stream independently from there.
Edit2: Ok, you want to do this automatically. In this case, I would suggest you look at two tools available on Linux called tcpflow and tcpreen.
tcpreen creates a proxy similar to what you want between a local port and a remote one. It's a TCP proxy, not an HTTP proxy so this means you'll have to write some parsing tool to isolate the HTTP streams that contain the images you want (probably based on the MIME type of the response). it's not too complex a task, though, if you understand how HTTP works.
tcpflow is similar to tcpreen except that it's a sniffer instead of a proxy. Use whatever tool you think its more adapted to your environment.