On MacOS EOF is never triggered - Potential fix

[henshin]

I think this might be related to issue #12.
I'm testing on a Mac OS and I looked into the OSX troubleshooting issue #4 but didn't find anyone mentioning this before.
That config.json wasn't working properly for me, I think AnyConnect expects more certificate information than the one on that example but I'm not sure. So what I ended up doing was to use Burp Suite as an invisible proxy and route the traffic to the hostscan-bypass listener.
Burp generates a proper (self-signed) certificate which seems to work fine with AnyConnect.

Tested with AnyConnect 4.9.04043 on MacOS 10.15.6.

Steps I did to prepare my test setup were the following:

Hardcode the DNS in /etc/hosts to point to localhost

127.0.0.1    targethost

PortForward port 443 to 8443

This is because it's a bad idea to run Burp as root

echo "rdr pass inet proto tcp from any to any port 443 -> 127.0.0.1 port 8443" | sudo pfctl -ef -

Setup Burp as an invisible proxy

With this setup, Burp will intercept all the communications (useful for debugging) while forwarding all the traffic to hostscan-bypass:

Note: The certificate name must be manually set to the targethost, otherwise AnyConnect will reject the connection.

Start hostscan-bypass

go run hostscan-bypass.go -l 127.0.0.1 -p 9443 -r targethost:443 -o anyconnect-mac.sh -s -c config.json 

Finally, establish the connection on AnyConnect.
So this works fine and the connection is successfully established and hostscan-bypass manages to capture all the traffic. The problem is that it never finds the EOF when reading the data, so it never finishes. I noticed that the last received bytes were the following on the output:

00000200  2e 31 35 2e 36 22 3b 0a  65 6e 64 70 6f 69 6e 74  |.15.6";.endpoint|
00000210  2e 61 6d 5b 22 31 30 30  31 33 37 22 5d 2e 61 63  |.am["100137"].ac|
00000220  74 69 76 65 73 63 61 6e  3d 22 6f 6b 22 3b 0a 0a  |tivescan="ok";..|

So, the fix for me was to add the following code to the script (not elegant but it does the job):

...
                // I added this check
                if strings.HasSuffix(hostscan.Endpoint,"\x0a\x0a") {
                        err = io.EOF
                }
                if err != nil && err == io.EOF {
                        if hostscan.Endpoint != "" {
...

This checks if the HTTP request has finished sending all the data, and if so, forces the EOF to trigger.
This works for me and now the script is able to finish and create the output file successfully.

UPDATE: Looking closely at the generated script, I can see 2 problems with this approach: The user agent and the platform were not replaced, this means that the script ended prematurely and it needs another way of checking if all the fields were replaced correctly first. The second problem is that the <ENDPOINT> includes the HTTP request headers which is not meant to happen. I believe this has to do with using Burp as an invisible proxy and not related to hostscan-bypass. I can do more tests on this later if necessary.

[Gilks]

I apologize for the delay on this. I appreciate the in depth troubleshooting! The biggest problem for me is that I cannot test this. As a general rule, I've been avoiding doing any sort of direct os x support.

However, I don't mind having this added in under an argument like --osx-eof. Based off what you're saying, this command line argument could control which eof sequence is being looked for. I'm not certain what the solution would be for the user-agent or platform versioning, though.

I'd be willing to land this change into the tool without being able to test it myself as long as the original functionality still works without the --osx-eof option specified.

[henshin]

Hey @Gilks, sorry for the not replying earlier.
I no longer have an environment to test this as well, so I suggest closing this issue and if I ever come back to this, re-open it or create a new one with mode info.