Taco5 Posted August 11, 2023 Share Posted August 11, 2023 C2 Server: OS: Ubuntu 22.04.2 LTS C2: 3.3.0-Stable Systemd command: /opt/c2/c2_amd64_linux -hostname c2.tako.dev -https -certFile /opt/c2/cert.pem -keyFile /opt/c2/privkey.pem -sshport 12912 -db /opt/c2/c2.db Lan Turtle Client: Version 6.2 Description LAN Turtle and C2 server reside on two different subnets. 192.168.160.0/24 and 192.168.170.0/24 respectively. Firewall ports are open on the network there is no host firewall on C2. I am able to see traffic passing between the LAN Turtle and the C2 server, but it is over 443 and ends with a client reset. This is the only device I have to connect to my C2 server. I am happy to provide more info, just let me know what you need. Odd things I am seeing From the firewall I see the LAN Turtle attempting to connect over TLS on port 443. Not the designated protocol ssh or port of 12912. Confirmed looking in the device.config file it reflects the correct port. I assume for first connection some HTTP traffic is needed? From the firewall and the packet captures I can confirm the client (the LAN Turtle) is terminating the connection after a reset. I cannot decrypt the traffic, because it is used EC and not RSA. It may be possible the LAN Turtle does not support those ciphers? Modifications: In the /etc/config/dhcp file I had to add "option rebind_protection '0'" under "config dnsmasq" to get internal DNS to resolve correctly. NMAP Showing ports are open This was on my host machine which is on the same network as the LAN Turtle sudo nmap -p- c2.tako.dev [sudo] password for takoman: Starting Nmap 7.94 ( https://nmap.org ) at 2023-08-11 00:31 MST Nmap scan report for c2.tako.dev (192.168.170.14) Host is up (0.00063s latency). Not shown: 65531 closed tcp ports (reset) PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https 12912/tcp open unknown ping from LAN Turtle to C2 Server root@turtle:~# ping -c 4 c2.tako.dev PING c2.tako.dev (192.168.170.14): 56 data bytes 64 bytes from 192.168.170.14: seq=0 ttl=63 time=1.309 ms 64 bytes from 192.168.170.14: seq=1 ttl=63 time=1.420 ms 64 bytes from 192.168.170.14: seq=2 ttl=63 time=1.408 ms 64 bytes from 192.168.170.14: seq=3 ttl=63 time=1.389 ms --- c2.tako.dev ping statistics --- /tmp/cc-client-error.log [1691741581 !ERR INITSYNC ] Error in startup sync post [1691741581 !ERR MAIN ] Device startup sync failed. Retrying... [1691741587 !ERR CURL ] Error posting update to server... [1691741587 !ERR INITSYNC ] Error in startup sync post [1691741587 !ERR MAIN ] Device startup sync failed. Retrying... [1691741593 !ERR CURL ] Error posting update to server... [1691741593 !ERR INITSYNC ] Error in startup sync post [1691741593 !ERR MAIN ] Device startup sync failed. Retrying... 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 1.309/1.381/1.420 ms Quote Link to comment Share on other sites More sharing options...
dark_pyrro Posted August 11, 2023 Share Posted August 11, 2023 Is the cert available for/on the Turtle? Quote Link to comment Share on other sites More sharing options...
dark_pyrro Posted August 11, 2023 Share Posted August 11, 2023 And, also follow the documented command line argument order. Not that I can see that it really should matter, but since the docs explicitly says to enter the parameters/arguments in a specific order, it could be a good thing to follow what the docs say. Quote Link to comment Share on other sites More sharing options...
Solution Taco5 Posted August 12, 2023 Author Solution Share Posted August 12, 2023 Doing some additional testing by browsing the forums root@turtle:~# wget https://c2.tako.dev --2023-08-11 14:30:17-- https://c2.tako.dev/ Resolving c2.tako.dev... 192.168.170.14 Connecting to c2.tako.dev|192.168.170.14|:443... connected. ERROR: cannot verify c2.tako.dev's certificate, issued by 'CN=R3,O=Let\'s Encrypt,C=US': Unable to locally verify the issuer's authority. To connect to c2.tako.dev insecurely, use `--no-check-certificate' added new letsencrypts certs to /etc/ssl/certs. So I extracted ISRG_Root_1.crt and DST_Root_CA_03.crt from the fullchain.pem and make new crt files. I then moved them over /etc/ssl/certs overwritting the existing certs with the new ones. now I can get wget to work. root@turtle:~# wget c2.tako.dev --2023-08-11 14:49:37-- http://c2.tako.dev/ Resolving c2.tako.dev... 192.168.170.14 Connecting to c2.tako.dev|192.168.170.14|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1020 [text/html] Saving to: 'index.html' index.html 100%[=================================================>] 1020 --.-KB/s in 0s The c2 auto redirects 80 to 443, but for doucmentation purposes I am showing that it works with a wget to https. root@turtle:~# wget https://c2.tako.dev --2023-08-11 15:13:46-- https://c2.tako.dev/ Resolving c2.tako.dev... 192.168.170.14 Connecting to c2.tako.dev|192.168.170.14|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1020 [text/html] Saving to: 'index.html.1' index.html.1 100%[=================================================>] 1020 --.-KB/s in 0.01s Still not working so I added the wildcard public cert I am using on my C2 server. Following the process found here: https://docs.hak5.org/cloud-c2/guides/cloud-c-setup-with-self-signed-ssl-certificates. I get it is not self signed, but still. root@turtle:/etc/ssl# cat ./wildcard.crt >> cert.pem C2DISSCONNECT followed by C2CONNECT did not work. Rebooted the device and did not work. Firewall still shows tcp reset from client on port 443 same number of bytes transferred 3.5k. It looks like the issue remains when I updated the certificates on the appliance. *** SOLUTION *** I updated my C2 server to point to the fullchain and just the public cert and that seems to work. I am not sure if updating the certs helped. If you have the same issue make sure to include the fullchain.pem and possibly update the certbundle. ExecStart=/opt/c2/c2_amd64_linux -hostname c2.tako.dev -https -certFile /opt/c2/fullchain.pem -keyFile /opt/c2/privkey.pem -sshport 12912 -db /opt/c2/c2.db NOTE: - It looks like -sshport option only applies when you make a revse tunnel. All traffic is managed over 443. So I guess I need to make a new listening port for my server to change it from 443. - The device is stuck in "Online and Syncing Changes", but I can manually exfil data using the C2EXFIL command. Now the device will auto disconnect from C2 after an hour or two. looks like something else to troubleshoot... Quote Link to comment Share on other sites More sharing options...
Taco5 Posted August 12, 2023 Author Share Posted August 12, 2023 Also thank you dark_pyrro. It was one of your post that got me pointed in the right direction. Thank you for your effort on this forum. Quote Link to comment Share on other sites More sharing options...
Taco5 Posted August 13, 2023 Author Share Posted August 13, 2023 Been troubleshooting LANTurtle being stuck in "online and syncing changes and found a better way to update the certs. The leaves only changing the /etc/config/dhcp file I and adding the "option rebind_protection '0'" under "config dnsmasq". These two commands will upgrade the certificate error issues. This is assuming the cert is not self signed. Which means only the thing that needs to be done is adding opkg update opkg upgrade ca-bundle Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.