Éd_D Posted June 14, 2021 Share Posted June 14, 2021 Cloud C² is running properly on the vps server (previous problem is solved, no more conflict with other application! Great thanks to chrizree.) A Chinese sentence says that a draw is better than 100,000 words… So, you can a picture that shows my network config at https://github.com/th3m1s-42/th3m1s-42/blob/main/img/networkScheme1.png The cloud C2 server is launched by systemd:/etc/systemd/system/cloudc2.service file: root@vps:/etc/systemd/system# cat cloudc2.service [Unit] Description=Hak5 Cloud C2 After=cloudc2.service [Service] Type=idle ExecStart=/usr/local/bin/c2-3.1.2_amd64_linux \ -hostname fullyQualifiedName.tld \ -https \ -keyFile /path/to/keys/myFile.key \ -certFile /path/to/certs/myFile.crt \ -db /path/to/hak5c2/c2.db [Install] WantedBy=multi-user.target root@vps:/etc/systemd/system# I connect my laptop on Internet through the WiFi Pineapple… So I presume that, if my laptop can join an host on the net, my Pineapple device can do it too… I can surf the Internet without problem. I have run 3 tests to ensure that ports 80, 443 and 2022 are enable: In the address field of my favorite browser, I type "fullyQualifiedName.tld:80". The Hack5 Cloud C² login page is displayed in the browser window without using SSL.C² is listening HTTP on port 80. Same thing with "fullyQualifiedName.tld:443", same result with SSL.C² is listening HTTPS on port 443. In a terminal window : myself@MacBook ~ % ssh -p 2022 foobar@fullyQualifiedName.tld The authenticity of host '[fullyQualifiedName.tld]:2022 ([aaa.bbb.ccc.ddd]:2022)' can't be established. RSA key fingerprint is SHA256:sgRolDenN95AzPaxDE6BUY6npK3VTdd2xOfVuZyQL/E. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '[fullyQualifiedName.tld]:2022,[aaa.bbb.ccc.ddd]:2022' (RSA) to the list of known hosts. foobar@fullyQualifiedName.tld: Permission denied (publickey). myself@MacBook ~ % C² is listening SSH on port 2022 (even though the foobar user do not exist on this VPS! 😂). So, I think everything is ok to add my pineapple device on Cloud C². I create a device in the Cloud C² admin interface (Add button) with type "WiFi Pineapple NANO / TETRA ». I download the device.config with he Setup button on the newly created device page… I upload this file on Pineapple device: myself@MacBook ~ % scp ~/Downloads/device.config root@172.14.42.1:/etc/ root@172.16.42.1's password: device.config 100% 832 168.3KB/s 00:00 myself@MacBook ~ % I reboot Pineapple device with the admin interface of the Pineapple (http://172.16.42.1:1471/) Unfortunately, the Pineapple stays offline with the status "Last Seen: never". Another test: myself@MacBook ~ % ssh root@172.16.42.1 root@172.16.42.1's password: BusyBox v1.30.1 () built-in shell (ash) ***** WiFiPineapple Banner ***** With OpenWRT 19.07.2 --------------------- root@PineappleTetra:~# ps xaf PID TTY STAT TIME COMMAND 2 ? S 0:00 [kthreadd] 7 ? S 0:00 \_ [ksoftirqd/0] 6 ? I< 0:00 \_ [mm_percpu_wq] 4 ? I< 0:00 \_ [kworker/0:0H] 3 ? I 0:02 \_ [kworker/0:0] 5 ? I 0:01 \_ [kworker/u2:0] 8 ? I 0:01 \_ [kworker/u2:1] 82 ? S 0:00 \_ [oom_reaper] 88 ? I< 0:00 \_ [kblockd] 85 ? S 0:00 \_ [kcompactd0] 83 ? I< 0:00 \_ [writeback] 86 ? I< 0:00 \_ [crypto] 122 ? S 0:00 \_ [kswapd0] 184 ? S 0:00 \_ [spi0] 281 ? I< 0:00 \_ [ipv6_addrconf] 283 ? I< 0:00 \_ [dsa_ordered] 295 ? S 0:00 \_ [ubi_bgt0d] 300 ? I< 0:00 \_ [kworker/0:1H] 361 ? I 0:00 \_ [kworker/0:3] 404 ? S 0:00 \_ [ubifs_bgt0_1] 594 ? I< 0:00 \_ [cfg80211] 632 ? I< 0:00 \_ [rpciod] 633 ? I< 0:00 \_ [xprtiod] 666 ? I< 0:00 \_ [nfsiod] 3906 ? I 0:00 \_ [kworker/u2:2] 1 ? Ss 0:02 /sbin/procd 470 ? S 0:00 /sbin/ubusd 498 ttyS0 Ss+ 0:00 /sbin/askfirst /bin/login 564 ? S 0:01 /sbin/urngd 889 ? S 0:00 /sbin/logd -S 64 1000 ? S 0:00 /sbin/netifd 1243 ? S 0:00 \_ udhcpc -p /var/run/udhcpc-eth0.pid -s /lib/netifd 1052 ? Ss 0:00 /usr/sbin/atd 1497 ? Ss 0:00 php-fpm: master process (/etc/php7-fpm.conf) 1499 ? S 0:01 \_ php-fpm: pool www 1498 ? S 0:01 \_ php-fpm: pool www 1527 ? S 0:00 /usr/sbin/sshd -D 3632 ? Ss 0:00 \_ sshd: root@pts/0 3646 pts/0 Ss 0:00 \_ -ash 4635 pts/0 R+ 0:00 \_ ps xaf 1571 ? S 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/n 1611 ? S 0:00 \_ nginx: worker process 1574 ? Ss 0:07 /usr/sbin/hostapd -P /var/run/wifi-phy0.pid -B /var/r 1625 ? S 0:00 /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c 1746 ? S< 0:00 /usr/sbin/ntpd -n -N -S /usr/sbin/ntpd-hotplug -p 0.o 1749 ? S 0:00 /bin/sh /etc/rc.common /etc/rc.d/S99cc-client boot 1753 ? S 0:20 \_ cc-client /etc/device.config root@PineappleTetra:~# A cc-client process is running. The Pineapple device should connect to the C² Cloud server… but nothing! I even tried to change the device name to PineappleTertra (hostname of the device, seen during the ssh session, above) in the Cloud C² server and repeat the process of configuration (download device.congig from server, upload it to device and reboot device), to no avail. 🙃 I misunderstand: I think to have done everything like RTFM!! 😢 Has anyone an idea? Where can I look for the solution? Thank you for the help, Best regards. Éd. Link to comment Share on other sites More sharing options...
chrizree Posted June 14, 2021 Share Posted June 14, 2021 What happens if you kill the cc-client process and start it manually (with the device.config as a parameter)? Any messages/errors thrown back? Does the device.config file contain the domain name of the VPS (do not post the content here though)? Is port 2022 in the file? Link to comment Share on other sites More sharing options...
Foxtrot Posted June 14, 2021 Share Posted June 14, 2021 What does /tmp/cc-error-log.txt look like? Did you change your hostname or port of the server after you generated the device.config? This will invalidate any previous device.configs, so you'll have to remake them. Link to comment Share on other sites More sharing options...
Éd_D Posted June 15, 2021 Author Share Posted June 15, 2021 Ok, I am doing the test… 1st step: Once cc-client process killed, I run the command line "cc-client /etc/device.config" Nothing displayed (not even the prompt: cc-client seems to be running). I run a second ssh session to verify: root@PineappleTetra:~# ps -xaf PID TTY STAT TIME COMMAND 2 ? S 0:00 [kthreadd] 7 ? S 0:07 \_ [ksoftirqd/0] 4 ? I< 0:00 \_ [kworker/0:0H] 3 ? I 0:27 \_ [kworker/0:0] 6 ? I< 0:00 \_ [mm_percpu_wq] 82 ? S 0:00 \_ [oom_reaper] 88 ? I< 0:00 \_ [kblockd] 86 ? I< 0:00 \_ [crypto] 83 ? I< 0:00 \_ [writeback] 85 ? S 0:00 \_ [kcompactd0] 122 ? S 0:00 \_ [kswapd0] 184 ? S 0:00 \_ [spi0] 281 ? I< 0:00 \_ [ipv6_addrconf] 283 ? I< 0:00 \_ [dsa_ordered] 295 ? S 0:00 \_ [ubi_bgt0d] 300 ? I< 0:00 \_ [kworker/0:1H] 361 ? I 0:00 \_ [kworker/0:3] 404 ? S 0:00 \_ [ubifs_bgt0_1] 594 ? I< 0:00 \_ [cfg80211] 632 ? I< 0:00 \_ [rpciod] 633 ? I< 0:00 \_ [xprtiod] 666 ? I< 0:00 \_ [nfsiod] 24344 ? I 0:01 \_ [kworker/u2:2] 25820 ? I 0:01 \_ [kworker/u2:1] 27165 ? I 0:00 \_ [kworker/u2:0] 1 ? Ss 0:02 /sbin/procd 470 ? S 0:00 /sbin/ubusd 498 ttyS0 Ss+ 0:00 /sbin/askfirst /bin/login 564 ? S 0:03 /sbin/urngd 889 ? S 0:00 /sbin/logd -S 64 1000 ? S 0:02 /sbin/netifd 1243 ? S 0:00 \_ udhcpc -p /var/run/udhcpc-eth0.pid -s /lib/netifd 1052 ? Ss 0:00 /usr/sbin/atd 1497 ? Ss 0:00 php-fpm: master process (/etc/php7-fpm.conf) 1498 ? S 0:09 \_ php-fpm: pool www 1499 ? S 0:09 \_ php-fpm: pool www 1527 ? S 0:00 /usr/sbin/sshd -D 25557 ? Ss 0:00 \_ sshd: root@pts/0 25671 pts/0 Ss 0:00 | \_ -ash 25962 pts/0 S+ 0:09 | \_ cc-client /etc/device.config 27166 ? Ss 0:00 \_ sshd: root@pts/1 27224 pts/1 Ss 0:00 \_ -ash 27288 pts/1 R+ 0:00 \_ ps -xaf 1571 ? S 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/n 1611 ? S 0:04 \_ nginx: worker process 1574 ? Ss 1:29 /usr/sbin/hostapd -P /var/run/wifi-phy0.pid -B /var/r 1625 ? S 0:04 /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c 1746 ? S< 0:00 /usr/sbin/ntpd -n -N -S /usr/sbin/ntpd-hotplug -p 0.o root@PineappleTetra:~# 2nd step: root@PineappleTetra:~# grep fullyQualifiedName.tld /etc/device.config fullyQualifiedName.tld *443B ??Ѓ???k#?? root@PineappleTetra:~# It seems that this is the first line of the file... root@PineappleTetra:~# grep 2022 /etc/device.config b2022 root@PineappleTetra:~# It is the last line in the file. If I look into the file with more (or less), I can see in these lines "non printable" characters, like in a binary file… Half an hour later, cc-client is still running and nothing new in Cloud C²! Link to comment Share on other sites More sharing options...
Éd_D Posted June 15, 2021 Author Share Posted June 15, 2021 The server name and server ports did not change since Cloud C² is running on this VPS; and I did not not change anything else after downloading the device.config file. The /etc/cc-client-error.log file is full of the repetition of 3 lines : [1623716396 !ERR CURL ] Error posting update to server... [1623716396 !ERR INITSYNC ] Error in startup sync post [1623716396 !ERR MAIN ] Device startup sync failed. Retrying... [1623716401 !ERR CURL ] Error posting update to server... [1623716401 !ERR INITSYNC ] Error in startup sync post [1623716401 !ERR MAIN ] Device startup sync failed. Retrying... [1623716407 !ERR CURL ] Error posting update to server... [1623716407 !ERR INITSYNC ] Error in startup sync post [1623716407 !ERR MAIN ] Device startup sync failed. Retrying... Link to comment Share on other sites More sharing options...
chrizree Posted June 15, 2021 Share Posted June 15, 2021 Did you put your crt file on the Tetra (and register the certificate)? I just remembered now that I did this for the Key Croc a while ago since someone had problems with connecting the Croc to C2 that had self signed certs (I truly have some kind of gold fish style memory capacity). It's discussed in the thread linked below. You will probably just need to do it as it is described in the Hak5 Docs link in that thread. The additional stuff I mentioned in the thread was specific for the Croc for some reason, and... I'm not sure if those packages are the same (or available) on OpenWrt the same way they are on Debian. https://forums.hak5.org/topic/54987-keycroc-doesnt-trust-c2-self-signet-certificate-ca/ Link to comment Share on other sites More sharing options...
Foxtrot Posted June 15, 2021 Share Posted June 15, 2021 Indeed, that could be the cause. There is a guide in the docs that may help you: https://docs.hak5.org/hc/en-us/articles/360049664554-Cloud-C2-setup-with-self-signed-SSL-certificates Link to comment Share on other sites More sharing options...
Éd_D Posted June 16, 2021 Author Share Posted June 16, 2021 I already read the guide: https://docs.hak5.org/hc/en-us/articles/360049664554-Cloud-C2-setup-with-self-signed-SSL-certificates But, I don't use a self signed SSL certificate! I am using a standard wilcard one delivered by my an Internet Provider for "myDomain" and all first level subdomains "*.myDomain.tld". (My certificate is signed by a certification authority…) To have this certificate, the procedure is : I un the "openssl" command line, like a self signed SSL certificate guide… using "-out cert.csr" instead "-out cert.cst" and *.myDomain.tld" as FQDN. I send "cert.csr" file to the SSL certification department of an Internet provider of mine (and pay the bill! 🙂). On the one hand, the SSL certification department give me a fingerprint to add in a CNAME record of the myDomain.tld DNS server. On the other and, the SSL certification department send me the signed certificate ("cert.crt") and another file: an intermediate certificate called "ProviderStandardSSLCA2.pem". Writing these lines, I remember that, in the self signed SSL certificates guide, you run the "cat certs/cert.crt >> cert.pem" command line… 💡 … and remember that : On the VPS, the certificate (.crt) and intermediate certificate (.pem) don't share the same radical name! root@vps:~# cd /path/to/certs root@vps:/path/to/certs# ln -s ProviderStandardSSLCA2.pem myFile.pem root@vps:/path/to/certs# systemctl restart cloudc2.service root@vps:/path/to/certs# On the Pineapple device, I forget the cert.pem file! So, I do the following sequence: Copy (scp) the ProviderStandardSSLA2.pem to my PineApple device, in "/etc/ssl/". Connect (ssh) to the device : root@PineappleTetra:~# cd /etc/ssl root@PineappleTetra:/etc/ssl# cat ProviderStandardSSA2.pem >> cert.pem root@PineappleTetra:/etc/ssl# rm ProviderStandardSSA2.pem root@PineappleTetra:/etc/ssl# Generate and download a new "device.config" from Cloud C² server. Upload (scp) the "device.config" to my PineApple device, in "/etc/" and reboot it. AND 🥁 THE PINEAPPLE IS CONNECTED! Thanks very much for you, Foxtrot and chizree The exchanges with you are a great help. 👍👍👍 Problem solved. Link to comment Share on other sites More sharing options...
Foxtrot Posted June 16, 2021 Share Posted June 16, 2021 Glad to hear you solved it. I will update the docs page at some point to mention the type of certificate you are dealing with. Link to comment Share on other sites More sharing options...
Éd_D Posted June 16, 2021 Author Share Posted June 16, 2021 Addendum In my previous post, I said that I had linked ProviderStandardSSLCA2.pem file to myFile.pem alias… I am not sure there is much point in having this link… I do not know if it is really useful for Cloud C² sofware to find a ".pem" file with same name, in the same directory of the certificate "myFile.crt" called by the argument: "-certFile /path/to/myFile.crt" when C² is launched. May be, it is more useful to run the "cat ProviderStandardSSA2.pem >> ca-certificates.crt" command line in the certs directory of the VPS… It is exactly the same command line as run on the device because /etc/ssl/cert.pem is an alias for /etc/ssl/certs/ca-certificates.crt file. In doubt, I had done both (but my message was already sent 🙂). Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.