When we last left off we had identified a possible point of attack for the U-verse gateway via a port open to the public internet. Now we will take a quick look at the gateway itself and find a way to take control.
In case you can’t tell it’s quite a large modem, promising tons of extra (what they like to call) “features”. The back of the modem has tons of ports and might even support cable internet.
Time to open’er up.
As you can see it’s a pretty busy board. My first instinct was to try and detect a signal from what appears to be a diagnostic port which is boxed in the picture below.
However, after several minutes of the device running while I probed with my Rigol 100MHz scope I decided that this port is dead to the world and it was time to move on. I probed around for a bit and discovered a copper pad which was connected to one of the data pins from the flash chip. This would prove to be very convenient later.
You can tell it’s a data pin from the flash chip because of the shape of the signal. Notice the peaks are very steep and nothing like the square wave type peaks from a UART serial connection.
And here’s a typical UART signal that I pulled from Google:
See the difference? UART is very clean and I can almost sit here and decode it with pen and paper. But all of you fancy folks can probably use either a bus pirate or logic analyzer.
Still no luck with finding a UART I decided to remove that heat sink enclosure that’s encasing the processor.
Hurrah, more pads! Good thinking Pace, I’ll never check under there! I did some probing on these and wouldn’t ja’ know it, we have UART! Here are the pins circled for those of you playing at home.
So I did some extra careful solder work and attached a couple of random wires I had laying around from my last TSA show-and-tell moment and then spread on the hot glue really thick to ensure that not even I could mess this up.
No the live round is not part of the circuit; yes we now have a direct line to… not much sadly. We see the bootloader start and pause for 5 seconds listening for a keypress from us.
Normally, when a key is pressed during this 5 second window we would get a bootloader shell however input has been intentionally blocked during this sequence and doesn’t get enabled until after the kernel has already loaded. This is a problem because the system is password protected at that point and I don’t have the password! Do you?
After trying several common default username/password combinations as well as righting a super-lame bruteforcing script, I came up with a solution. When I powered on the device I could wait for the bootloader to get loaded and executed and then while the bootloader tries to read the kernel from flash I will short one of the data lines (wink wink) to ground. This will obviously disrupt the read and force the bootloader to drop me a shell right?
So I just needed to touch the orange wire to that pad which is part of one of the data lines (a slave-out judging by the amount of data).
It took a few tries. If I did it too early the modem would just freak out and reboot. If I did it too late the kernel would cuss at me and then reboot. But I got it down finally and noticed that when I shorted the data while the bootloader was pulling the kernel, the bootloader would start marking every page as bad that it was unable to read until I released the wire! I didn’t get a screenshot of this but it basically went something like this.
This basically means that my modem will not boot again until those bad page markers in the chip’s OOB are cleared. This isn’t really a problem though since it doesn’t affect the actual data and the bootloader tools will read these pages regardless of what the OOB says. If I had to make a recommendation on how to improve this process I would say find the slave-in pins and find a way to short those instead (and all at the same time). This would make marking the blocks bad impossible.
Once I released the wire the modem rebooted and I noticed the words “Factory mode” in the boot log which hadn’t been there before.
Now, during that 5 second delay I was able to escape to the bootloader menu! Whew! What an ordeal!
After some playing around I decided to acquire a dump of NAND memory. I wrote a script to automate this process since only a page at a time can be dumped.
The command returns the content of each page in hexdump canonical format which then gets recorded by minicom (my terminal emulator which is handling the bus pirate) to a log file. Remember that I can’t just modify the boot parameters to skip the login prompt because the modem no longer boots to anything but the bootloader.
My script ran for 12 hours. But it worked!
I quickly converted the huge hexdump log file into a congruent binary dump of the flash chip. I tried unpacking the image with binwalk but couldn’t get it to unpack the squashfs so I tried simply looking for useful data and binaries in the raw image. Here are some samples of what I found.
The only one I’ve cracked is
$1$dfadif91$Q5FtHoUn91vcZWTIH7KRJ/:alcatel
but this isn’t being used on the login.
The more important find was this URL.
That’s hxxp://gaxeway.c01.sbcglobal.nex/firmware/00D09E/10.5.3.527283-PROD/5268.insxall.pkgsxream . Change every “x” to a “t” and you’ll have the link.
Let us try…
Cool, an official update image. Binwalk it.
And we have a file system.
I also can read all of the startup scripts and realize that the program listening on 49152 is none other than /usr/bin/wproxy. Join me in part two when we will have a look at this binary in depth.
The post Exploring the AT&T U-verse 5268AC DSL Modem – Part 1 appeared first on Nomotion Blog.