Hardware - 8

John do, a reader of this blog made a serious break-trough! Via SSH on B593 prompt, he found the flashtest-command. Before this I had no knowledge about such command, but see what I can do with this new information:

# flashtest
Usage: flashtest {info|read|write|erase|export|load} {addr} {len} [data]
Format:
flashtest    help
flashtest    info
flashtest    read      addr    len
flashtest    write     addr    len    {data}
flashtest    erase     addr    len
flashtest    export    addr    len

Well ... the info sound interesting. Let's see:

# flashtest info
 flash  block  size  :  0x40000 (256k Bytes)
  flash  block  num   :  0x40 (64 Blocks)
  flash  total  size  :  0x1000000 (16M Bytes)
  flash  partation  info :
  ---------------------------------------------------------------
  Name                  Address                    Usage
 ---------------------------------------------------------------
  Boot                  0x0---0x40000            Bootloader
  Image             0x40000---0xA40000           Main  image
  Image            0xA40000---0xE00000           Subject  image
  Curcfg           0xE00000---0xE40000           Curcent  config
  Faccfg           0xE40000---0xE80000           Factury  config
  Tmpcfg           0xE80000---0xF00000           Temp  config
  Fixcfg           0xF00000---0xF40000           Fixed  config
  Logcfg           0xF40000---0xF80000           Log  config
  TR069            0xF80000---0xFC0000           TR069  cert
  Nvram            0xFC0000---0xFFFFFF           Nvram

Current config! Really!? (Mis-typed as Curcent config). The run-time -only /var/curcfg.xml's real storage has eluded me this far. Let's explore that further:

# flashtest export 0xE00000 65536
Read data: addr = 0xe00000, len = 0x10000 ...
Begin write to file
Export done

What did it do? Where it wrote to? Some poking around reveals:

# cd /tmp/
# ls -l
----------    1 0        0           65536 flashinfo.bin

Oh yes! The next thing is to get my hands on to the file. In the B593 firmware's Busybox there is only a limited set of tools.

Let's use the USB/FTP-hack for transferring the file. The idea is to plug an USB-stick into B593. Any FAT32-formatted stick will do, it is totally irrelevant if there are files or not. Early firmwares are known to have a flaw in them. You can mount the entire filesystem into FTP-server and transfer file to/from the box. Setup goes like this:

Make sure you have the FTP-server running, add a user to the new mount and set the directory as ../.. It is really important to do that! That effectively breaks out of /mnt/usb2_1 into /. See this pic:

I added user with name test. Now let's see if the FTP-connection works from an external machine:

# ftp 192.168.1.1
Connected to 192.168.1.1 (192.168.1.1).
220 bftpd %v at 192.168.1.1 ready.
Name (192.168.1.1:user): test
331 Password please.
Password:
230 User logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /tmp
250 OK
ftp> dir
227 Entering Passive Mode (192,168,1,1,166,124)
150 BINARY data connection established.
----------   1 0        0        65536 May 21 19:26 flashinfo.bin
226 Directory list has been submitted.
ftp>

Oh yes! The extracted NVRAM-binary is there. Let's download it:

ftp> get flashinfo.bin
local: flashinfo.bin remote: flashinfo.bin
227 Entering Passive Mode (192,168,1,1,144,190)
150 BINARY data connection established.
226 File transmission successful.
65536 bytes received in 0.06 secs (1092.41 Kbytes/sec)

A brief analysis of the file reveals:

# hexdump -C flashinfo.bin | head -3
00000000  3e 00 64 fe 3c 3f 78 6d  6c 20 76 65 72 73 69 6f  |>.d.<?xml versio|
00000010  6e 3d 22 31 2e 30 22 20  3f 3e 0a 3c 49 6e 74 65  |n="1.0" ?>.<Inte|
00000020  72 6e 65 74 47 61 74 65  77 61 79 44 65 76 69 63  |rnetGatewayDevic|

# hexdump -C flashinfo.bin | tail -5
000064f0  65 77 61 79 44 65 76 69  63 65 43 6f 6e 66 69 67  |ewayDeviceConfig|
00006500  3e 0a 00 ff ff ff ff ff  ff ff ff ff ff ff ff ff  |>...............|
00006510  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00010000

The first 4 bytes of 3e 00 64 fe are bit of a mystery. I don't know what the 3e 00 is for, but the 64 fe is obvious! It is the length of the XML-file following the header bytes. I can confirm that the entire /var/curcfg.xml is there. Unchanged. Intact!

My next move is to try altering the curcfg.xml and write it back. There is a chance of locking myself out of my own B593, so ... I need to be really careful with this. If everything works as I expect, my next move is to write tools for allowing people to access their devices as they want to.

I'd like to extend my gratitude to Mr. John do. This really is ground-breaking stuff allowing us to new lengths with Huawei B593 hacking. Thank you, sir!

This is something that has been bugging me since November. In my post about different models, I stated that I have a u-12 (and still do). Last year I did setup a s-22 to a friend and got to see that it is pretty much the same. However, "pretty much the same" is not exactly the same.

The s-22 is a newer model and it has been well established, that it has a TDD 2600 MHz added into it. All the FDD frequencies are exactly the same than in u-12.

In the comments of my post, a user suggested that s-22 differs from u-12 by having only one USB-connector. At the time I was unable to find proof of that, all the pictures I could found of alleged s-22 units had no difference for a u-12 unit.

Now the situation has changed. In my ventures of the wonderful Internet I found an article What's the difference between HUAWEI B593s-22 and B593u-12? and it has a picture of both units side by side in it. Nice! But which one is which?

Just to make sure that s-22 is in the left and u-12 is in the right, I'll post a fresh picture of my own u-12 unit:

Also to close the case I also found a vendor page with a nice picture of s-22 in it, see HUAWEI B593s-22 4G LTE CPE [B593s-22]. It has a picture of the unit in the page, and their s-22 looks exactly the same than the left unit in the picture, and exactly NOT the same than my u-12. Apparently s-22 does not have a power switch, it lacks the side USB-connector and SIM-card -slot has been changed into a tray. Lot of differences to spot, actually.

So I'm confident that s-22 is very much re-designed both in hardware and firmware. The hardware side is surely changed because of the new(ish) 4G TDD radio interface. And while Huawei engineers were at it, they changed also the firmware in number of ways, one of them being to resist hacking attempts better than their 1st gen version did. This is also a well established fact, s-22 firmware has a completely different structure than u-12 firmware.

Now me and everybody else should be able to identify the units by a simple visual inspection.

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!