42 replies to this topic

[SpaceRat]

Even with a 32 character long password, it is STILL a bad idea to forward the webinterface, ftp or telnet to the outside world. Just don't do it. It's a really really bad idea.
 
As for an explanation, well YOU may not understand how one could mis-use those, but I know a few methods and real criminals will probably know a few more. So don't. Please.

So OpenWebIf contains security problems?
 

What you CAN do safely is to forward the SSH port (22). That is the only one that's safe.

Let us sort out the facts:

Fact 1: By default, the sshd on the E2-Box uses password login, just like the WebInterface does.
Fact 2: While I agree that forwarding telnet, ftp and http to the outside world is a bad idea (Passwords are transmitted in an unencrypted way, so logging in once from an alien (W)LAN (Hotspot, other person's (W)LAN, ...) reveals that password to anyone who can use Wireshark), the WebInterface can use HTTPS, that is TLS/SSL.
Using that, neither credentials nor the payload are transferred unencrypted, actually even the URL (except the domain name) is encrypted.
This said, I want to remark that TLS/SSL is also used to secure the tunnel solution that people keep suggesting ...
Fact 3: The pure existance of Android/iOS/Whatever-Apps encourages the user to open not only https but even more services to the outside world in order to make use of them.

Conclusion:
With sshd using password login, it is from a design point of view neither more nor less secure than the WebInterface when using HTTPS.
How secure or insecure the box is on these services depends solely on the password's strength and if there are known security flaws within the software used to implement these.

BTW: If you would switch from dropbear to OpenSSH in order to implement the SSH daemon, it would be a great step forward, because OpenSSH could be used as a SOCKSv5 proxy ...

[pieterg]

Your claim about https is incorrect.
Https protects the communication between client and server.
It does not protect the server from people trying to gain access.

EDIT: Too late, just noticed a whole thread where the goal of https is explained in more detail than I did here

Edited by pieterg, 8 September 2013 - 18:36.

[MiLo]

BTW: If you would switch from dropbear to OpenSSH in order to implement the SSH daemon, it would be a great step forward, because OpenSSH could be used as a SOCKSv5 proxy ...

You can install openssh if you like. Just run "opkg install openssh".

[MiLo]

Fact 1: By default, the sshd on the E2-Box uses password login, just like the WebInterface does.

Your first fact is wrong already.

By default, the SSH server will NOT let you log in. Unless you either create a keypair or set a password, it won't let anyone in.

[MiLo]

... if there are known security flaws within the software used to implement these...

It's the "unknown" flaws that scare me.

There being no known flaws can easily be explained by the likely cause that no one cared to look for them.

[MiLo]

And my final statement on this:

It's your foot. Your gun.

[SpaceRat]

Your claim about https is incorrect.

It isn't.

Https protects the communication between client and server.

That's true. As I said.

It does not protect the server from people trying to gain access.

That's correct. As I said.
And as I additionally said: A login/pass combo of root:dream, root:<blank> or something like that most probably (not sure about that ) doesn't necessarily add to the level of hacking skills required to gain access.

[SpaceRat]

... if there are known security flaws within the software used to implement these...

It's the "unknown" flaws that scare me.

Well, there could as well be unknown flaws within the VPN solution used, within the sshd used, within ANYTHING you use on your network which needs access to let alone from the outside.
You can't have the cake and eat it too.

You can watch left, right and left again before crossing the road ... but a certain amount of risk always remains.

If you say you want to die from hunger on your side of the road, refusing to cross it, is your decision. For all others, it's more realistic to make sure they check left, right and left again before and cross the road "as safe as possible".

There being no known flaws can easily be explained by the likely cause that no one cared to look for them.

There was a flaw inside OpenWebIf which allowed anyone with access to the web-interface to retrieve ANY file he wanted from the box, as long as he knew the path.
It was found and fixed. You can't get any security beyond this.
If you dig out old versions of apache, you would probably end up having security holes too. Still there always have been web servers during the last years.

Why not shut down this forum to protect the host behind it?
It's server software might have unknown security holes!!!!!!1!eleven!!

[ims]

I am using for edit box's files in Ubuntu 12.04 doubleclick on file with Krusader =>file is oneded in gedit (then I can it edit and save back to box).

 

Under OpenPli4, when I want connect to box, I get "500 OOPS: priv_sock_get_result" . I set passwd in telnet to empty ( passwd, enter,enter,enter). Now I can connect to box from Krusader via ftp, but after doubleclick Is opened gedit with error message ... some as (my translating to english):

 

Can not be open ftp://root@192.168.1.100/......../...py

gedit cannot handle locations ftp

 

When I set passwd to "dreambox" , still same. Under openpli 3.0 works all well. Some must be set there in vsftpd.conf (there is differences between conf under e3) ?

[WanWizard]

The conf file from 3.0 doesn't work on 4.0, it refers to a path that no longer exists. If you have a vsftpd.conf.opkg, move it to vsftpd.conf to fix it.

[ims]

I have not vsftpd.conf.opkg, I have fresh flash.

[WanWizard]

Hmm... might be another issue that popped up? Over to Milo...

[MiLo]

Worksforme.

I've added an extra line to the config to set the default dir to "/".

It sucks anyway, I've even tried pure-ftpd but that one wouldn't let me log in at all. So any suggestions for either a fix or replacement for vsftpd are welcome (all except "go back to the old version" because that did not compile).

[ims]

With  Krusader and F4 is possible edit and save files well.  Only with doubleclick => file will be opened in gedit, then it does not work. May be, I am alone with this problem ?

 

As i saw on old version (when is not created password) is possible connect with any passwd and connection is ok. May be, when there would be possible same, then gedit could be works. I do not know.

[betacentauri]

So any suggestions for either a fix or replacement for vsftpd are welcome (all except "go back to the old version" because that did not compile).

 

Hi MiLo,

 

old OpenPli3 version 2.3.5 compiles without issues under OpenPli 4 .

 

Here's the generated ipk (I didn't test whether it really works or not).

Attached Files

•  vsftpd_2.3.5-r4_mips32el.ipk   69.24KB   69 downloads

Edited by betacentauri, 11 September 2013 - 12:44.

[Taapat]

I do not know if it will help, but I remember when a year ago when I migrated in my SH4 receiver to vsftpd_3.0.0 I also had problems with root access without a password. I also did not make it in any way in the conf file.

I solved it by disabling VSF_SECUTIL_OPTION_CHROOT:

 

--- vsftpd-3.0.0-org/secutil.c 2012-03-28 06:08:28.000000000 +0300
+++ vsftpd-3.0.0/secutil.c 2012-09-14 23:32:10.448520213 +0300
@@ -132,13 +132,13 @@
   /* Misconfiguration check: don't ever chroot() to a directory writable by
    * the current user.
    */
-  if ((options & VSF_SECUTIL_OPTION_CHROOT) &&
+/*  if ((options & VSF_SECUTIL_OPTION_CHROOT) &&
       !(options & VSF_SECUTIL_OPTION_ALLOW_WRITEABLE_ROOT))
   {
     if (vsf_sysutil_write_access("/"))
     {
       die("vsftpd: refusing to run with writable root inside chroot()");
     }
-  }
+  }   */
 } 

 

 

[MiLo]

But wouldn't that result in a "vsftpd: refusing to run with writable root inside chroot()" message, instead of the silly "OOPS" we're getting now?

[theparasol]

http://en.wikipedia....server_software

[Robinson]

What you CAN do safely is to forward the SSH port (22). That is the only one that's safe.

Hello MiLo,

What is therefore a safe and relatively easy way to use telnet commands (like "ps", "reboot", etc.) and browse folders (FTP) from the outside world?

[SpaceRat]

What is therefore a safe and relatively easy way to use telnet commands (like "ps", "reboot", etc.) and browse folders (FTP) from the outside world?

1. Replace dropbear with OpenSSH
2. Change the root password to a good one, like %jBhb#zvTgZG97&$
3. Use ssh instead of telnet and sftp instead of ftp

If you do not need/want ftp-like access, you can as well skip step 1.

In case you want to harden things even more, extend step 2 with " and create your own key pair and set dropbear/OpenSSH to use this for login."