Add jsse_skiptls_mitm_proxy.rb #5513
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This module exploits an incomplete internal state distinction in Java Secure Socket Extension (JSSE) by impersonating the server and finishing the handshake before the peers have authenticated themselves and instantiated negotiated security parameters, resulting in a plaintext SSL/TLS session with the client. This plaintext SSL/TLS session is then proxied to the server using a second SSL/TLS session from the proxy to the server (or an alternate fake server) allowing the session to continue normally and plaintext application data transmitted between the peers to be saved. This module requires an active man-in-the-middle attack.
|
|
||
| print_status('Connected to %s:%d' % [fake_host, fake_port]) | ||
|
|
||
| server = Socket.new(Socket::AF_INET, Socket::SOCK_STREAM) |
|
@rcvalle This is a really neat submission, but may take some time and tweaking to include into master |
|
msftidy issues: |
| local_port = datastore['SRVPORT'] | ||
| port = datastore['PORT'] | ||
|
|
||
| proxy = TCPServer.new(local_host, local_port) |
There was a problem hiding this comment.
It should be a rex socket, shouldn't be?
|
I've reviewed the basics about what the module is trying since I wasn't familiar with the attack.... also I suck on TLS so pls forget if I do dummy questions =). I did a first straightforward test with a Java client like this: try {
System.out.println("****** Content of the URL ********");
BufferedReader br =
new BufferedReader(
new InputStreamReader(con.getInputStream()));
String input;
while ((input = br.readLine()) != null){
System.out.println(input);
}
br.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}(btw, I'm using Oracle Java 1.7.0_67 for testing). So I run the mitm module with the next options (I'm not providing a FAKEHOST, I feel that's legit, isn't it?): When trying to use the example it is what I get (I wasn't expecting an exception because of an invalid HTTP response really): And in the module: When I check the contents of the file saved by the module I can see the request in plaintext, so looks like the client is using a plaintext SSL/TLS as announced by the PR. But it's odd to me how the connection with the server is being handled :S Indeed the module isn't recording plaintext server responses, neither returning correct answers to the client (who throws an Exception because of course can't parse the HTTP response). Since the module is announced as mitm it looks unexpected to me. Probably I'm not using it correctly and I'm missing something dummy =) feedback is welcome. |
|
Today I noticed I don't know how to copy and paste :) So pasting again the full source of the client I've used for testing. Hopefully this time the full code =) import java.net.URL;
import java.net.MalformedURLException;
import java.io.IOException;
import javax.net.ssl.HttpsURLConnection;
import java.io.*;
class Main {
public static void main(String[] args) throws MalformedURLException, IOException {
System.out.println("Hello World!"); // Display the string.
URL url;
url = new URL("https://www.google.com");
HttpsURLConnection con = (HttpsURLConnection)url.openConnection();
System.out.println("Response Code : " + con.getResponseCode());
print_content(con);
System.out.println("Bye World!");
}
private static void print_content(HttpsURLConnection con){
if(con!=null){
try {
System.out.println("****** Content of the URL ********");
BufferedReader br =
new BufferedReader(
new InputStreamReader(con.getInputStream()));
String input;
while ((input = br.readLine()) != null){
System.out.println(input);
}
br.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
} |
jvazquez-r7
added a commit
that referenced
this pull request
Aug 8, 2015
|
Hi @rcvalle, after our chat (thanks again for the detailed explanations :)) I gave a second chance to the module. Did the necessary changes to use Rex sockets, some small fixes and now I can setup the mitm correctly =) Please, feel free to check my changes in case I wasted something: Final version here: c8ba5bb Test after changes (with the pasted Java client above): Now the client can see the HTTP response correctly and the HTTP communication is stored in plaintext by the module =) In the client: Thanks @rcvalle, awesome work! |
|
@jvazquez-r7 Awesome! Thank you! |
|
heya
... but the generated loot-output-files are empty. did I hit a bug here, can I help in a way, or do you have any idea whats going on, or what could be the reason for this behaviour? regards, Ulrich |
|
@pulgit Can you provide more information, such as the application and JRE version? |
|
Java-Version on the client is 1.7.0_71. The application is "proprietary" and the underlying protocol is some sort of "ftp dialect" (FTPish, but not 100% following RFC4217/FTP-S). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This module exploits an incomplete internal state distinction in Java Secure Socket Extension (JSSE) by impersonating the server and finishing the handshake before the peers have authenticated themselves and instantiated negotiated security parameters, resulting in a plaintext SSL/TLS session with the client. This plaintext SSL/TLS session is then proxied to the server using a second SSL/TLS session from the proxy to the server (or an alternate fake server) allowing the session to continue normally and plaintext application data transmitted between the peers to be saved. This module requires an active man-in-the-middle attack.