Jump to content

Recommended Posts

Posted (edited)

Hi,

This is a module that allows you to control your WiFi Pineapple over IRC. It uses a custom configuration file that you can edit in the Web Interface. The configuration file contains four sections, "Network", "Security", "Commands" and "Other".

Firstly, "Network" contains the network information such as the server, port, nickname and channel to join. The new "Security" block contains the name of the Master and the trigger. "Commands" contains your commands in the format of "phrase: command to execute". Finally the "Other" block is for other options such as debugging.

For more information on the config file format, see here.

Heres some screenshots:

hXxItpG.png?1L0EPLDG.png?1

Thanks!

-Foxtrot

Edited by Foxtrot
  • Upvote 2
Posted

This is really cool. Could you explain any possible security issues with using this? It seems to me without authentication anyone could connect to your IRC channel, if it's open to the internet for remote control, and issue commands on your Pineapple. Is this correct or should we take additional measures to guard the Pineapple?

Posted (edited)

This is really cool. Could you explain any possible security issues with using this? It seems to me without authentication anyone could connect to your IRC channel, if it's open to the internet for remote control, and issue commands on your Pineapple. Is this correct or should we take additional measures to guard the Pineapple?

Sure. Should someone find out the nickname of the pineapple, they can /WHOIS and find it, and execute any of the commands you set. There is no user identification of any kind at the moment, and the module is very much a project to learn from for me.

Off the top of my head, it would be easy to add a password parameter for your channel. And while you probably don't want people to be executing commands on your pineapple, nobody would know it was Commander unless you told them. To everyone else, it looks like just another user.

Edited by Foxtrot
  • Upvote 1
Posted (edited)

This is a cool idea, and I like it. Now with the latest update, I approve of it for use.

Doesn't standard IRC on port 6667 go over the air completely in plaintext? So even if you password protected your nick, and only allowed your nick to send commands that it would accept, wouldn't you still be sending your password over in plaintext whenever you login with the nickserv?

The hak5 irc does support SSLv3/TLSv1 on port 6697 and I think that's how I'm going to start using it. This way at least when you send your password to login to your nick it'll be over SSL, even though the things you say on it will become public. The certificate comes up as not valid though, does this look good though and should it be trusted?:

* Looking up irc.hak5.org
* Connecting to irc.vhirc.net (151.80.80.78) port 6697...
* * Subject: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ
* * Issuer: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ
* * Subject: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ
* * Issuer: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ
* * Certification info:
*   Subject:
*     CN=fr01.vhirc.net
*     OU=Server Admins
*     O=VHirc
*     L=Earth
*     ST=Earth
*     C=XZ
*   Issuer:
*     CN=fr01.vhirc.net
*     OU=Server Admins
*     O=VHirc
*     L=Earth
*     ST=Earth
*     C=XZ
*   Public key algorithm: rsaEncryption (2048 bits)
*   Sign algorithm sha256WithRSAEncryption
*   Valid since Jan 31 16:57:09 2016 GMT to Jan 30 16:57:09 2017 GMT
* * Cipher info:
*   Version: TLSv1/SSLv3, cipher ECDHE-RSA-AES256-GCM-SHA (256 bits)
* Connection failed. Error: unable to verify the first certificate.? (21)

It does look like you are restricting it to accept the commands only from a certain nick, is that correct? If so that is a good way to secure this I think, and only set it to accept the nick that's yours that you have registered and login to over the SSL port.

"they can /WHOIS and find it, and execute any of the commands you set"

How is that? If your commander connects to the hak5 irc, and looks for the commands there in your chosen channel and for a certain nick only? Only unless the hak5 irc is compromised, or where your pineapple is connecting to it from has the dns redirect to their own evil irc server?

Oh wait a minute the nick isn't for who the commands to accept are from, it's the nick of this commander module connected to the irc instead... Make it so it only will take commands from a certain nick, then with the above mentioned practice (only use your registered nick over SSL) it should be secure already. :)

Edited by AlfAlfa
Posted

This is a cool idea, and I like it. I wouldn't use this currently though due to it basically just leaving your pineapple wide open on the net totally unsecured... Doesn't standard IRC on port 6667 go over the air completely in plaintext? So even if you password protected your nick, and only allowed your nick to send commands that it would accept, wouldn't you still be sending your password over in plaintext whenever you login with the nickserv?

I'm not really sure what you mean by this... identifying with a networks services is currently not possible with Commander, and wouldn't change who can send commands. Non-SSL is ofcourse plaintext, but I don't think using SSL would make much of a huge difference. Its not like you can just sniff an IRC network and watch every byte going through the IRC server. (...right?)

The hak5 irc does support SSLv3/TLSv1 on port 6697 and I think that's how I'm going to start using it. This way at least when you send your password to login to your nick it'll be over SSL, even though the things you say on it will become public. The certificate comes up as not valid though, does this look good though and should it be trusted?:

* Looking up irc.hak5.org

* Connecting to irc.vhirc.net (151.80.80.78) port 6697...

* * Subject: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ

* * Issuer: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ

* * Subject: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ

* * Issuer: /CN=fr01.vhirc.net/OU=Server Admins/O=VHirc/L=Earth/ST=Earth/C=XZ

* * Certification info:

* Subject:

* CN=fr01.vhirc.net

* OU=Server Admins

* O=VHirc

* L=Earth

* ST=Earth

* C=XZ

* Issuer:

* CN=fr01.vhirc.net

* OU=Server Admins

* O=VHirc

* L=Earth

* ST=Earth

* C=XZ

* Public key algorithm: rsaEncryption (2048 bits)

* Sign algorithm sha256WithRSAEncryption

* Valid since Jan 31 16:57:09 2016 GMT to Jan 30 16:57:09 2017 GMT

* * Cipher info:

* Version: TLSv1/SSLv3, cipher ECDHE-RSA-AES256-GCM-SHA (256 bits)

* Connection failed. Error: unable to verify the first certificate.? (21)

That certificate is fine to accept. It was issued by the Net Admins of the network.

It does look like you are restricting it to accept the commands only from a certain nick, is that correct? If so that is a good way to secure this I think.

It does not, and I agree.

Posted

Okay let me clarify the first thing, I didn't mean for the commander to identify with the nickserv, yes that would be unnecessary and wouldn't help anything. I meant that it should only accept the commands from a certain nick, and you agree that it's a good next course of action to improve upon this current build, and it is the nick you use to actually send the commands to commander that I was talking about that should be registered and SSL'd.

As for that certificate, thanks now I know what the proper certificate should look like and I've set it to accept that certificate.

Posted

Version 2.0 (yes already) has been sent to Seb for uploading to the module manager.

Brief Changelog:

  • Completely rewrite the Python backend. Python is now structured with good OOP and methods. Learnt alot about OOP and Python in general.
  • Now we have security in the form of checking whether our master (defined in .conf) sent us the command to execute.
  • Better handling of sockets and the buffer.
  • I don't sleep apparently

More detail about the checking who said what has been added into the first post.

:D

  • Upvote 3
  • 5 months later...
Posted

I've implemented a start on boot option for this module (created a new option in "Others" named "StartOnBoot"), ran a check to see if commander was already running at the begining of commander.py and module.php files in order to prevent multiple insstances and if start on boot was enabled I'd add a line to crontab to restart every minute...

I am now working on a simple way to retrieve the response  so I can  run commands as ifconfig or ps and see the result on IRC...

I'd suggest Foxtrot to implement such features as they can be really useful!

If you want to I can attach my files here...

 

DRepas

Posted (edited)

I'm not sure I understand what you mean by adding a "StartOnBoot" to the Others section. Just add the commander.py program to /etc/rc.local. I'll put an auto-start feature in soon.

As for retrieving outputs of commands like ps and ifconfig, i've been meaning to get around to that for a while now, and will do eventually.

Edited by Foxtrot

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...