Forum Replies Created
-
Posts
-
Sorry, I rushed with my reply there! 🙂
I see mitmproxy attempts to do exactly that. I thought you just listed other similar ways of downgrading the connection. Thanks, I will look into that. And I’ll be on the lookout for your posts on the topic 🙂
Another thing, just a quick suggestion. Everyone is doing courses on “the cool stuff” like gaining access and hijacking webcams. But there is very little accessible knowledge on covering our tracks afterwards. Clearing logs etc. I’m not sure why, for me this concept is also fascinating, and regardless, it is very important. Maybe you guys would like to focus a little on that at some point 😉
I know it’s beside the scope of this thread, but it’s all connected, and I won’t be creating another post just to suggest this to you, you obviously know stuff 😉Anyways, thanks again!
Hey, thanks for the comprehensive response!
What I mean concerns more the client (target) side, not the server side. If you’re ever so kind to donate even more of your time to my question, here it is more detailed:
// Let’s assume we want to become the MITM to gain access to the target. So no backdoors etc (if we already have access, we can pretty much do whatever anyways, right? :))
So regardless of what method we choose as MITM, the target still connects through http. We can use SSLstrip or any other method, and sure it will work with many (most?) websites. But “work” means we will establish a connection, and as far as the server is concerned, we’re the client, so for them it looks like a legitimate https connection.
But the client machine knows it’s connected through http. And that’s what concerns me. If the client is using any modern browser, it will surely let him know that this is not a private connection with flashy alerts and this pretty much raises a red flag. Even if the user has no knowledge of http(S) protocols, he or she will think twice before going further. If I remember right, on Chrome for example you need to click “advanced” and than “allow the connection anyways”, stating that you’re aware of how dangerous it might be.
So that’s what I meant in the original question. Is there a way to fool the target into thinking it is actually connecting through https? (without having access to the target machine).
Ok, I figured it out 🙂
For anyone interested, here goes the solution that worked for me:#####
# json.dumps() takes a string, returns a string
# json.loads() takes a string, bytes or bytearray, returns string
# .encode() takes a string, return bytes
# .decode() takes bytes, returns a string
#####so the simplified working version (just one message from host to client); This is the code after establishing connection:
<<HOST>>
msg = input(“>> “) #(msg is a STRING)
msg_json = json.dumps(msg) #msg_json is a (serialized) STRING
connection.send(msg_json.encode()) #since the socket.send() in Python3 requires bytes, we use the .encode() function –> sending BYTES
<<CLIENT>>
msg_json_encoded = connection.recv(1024) #we receive the json-formatted BYTES
***msg_json_encoded.decode()*** – this step is not necessary, explained below*
msg = json.loads(msg_json_encoded) #jason.loads() does all the magic
print(msg)* This is what json.loads() does: “Deserialize s (a str, bytes or bytearray instance containing a JSON document) to a Python object” Therefore it can handle bytes, we don’t need to use .decode() first. Learned that by accident 😀
Ok, so not only does it work, it’s actually not that complicated 😀
Still, if I may, I would like to know if it’s “right”?
Meaning, is there a more elegant/efficient way of dealing with json and sockets in Python3?Thanks, sorry again for all the trouble!
…but so may other features still don’t, that I’ve decided to roll back to 2.4.0, as you suggested 🙂
Just wanted to share in case others experience similar issues.
Thanks again!
