I bought a Yoggie Gatekeeper Pro, oops

Discussion in 'privacy technology' started by rthorntn, Aug 17, 2010.

Thread Status:
Not open for further replies.
  1. rthorntn

    rthorntn Registered Member

    Aug 17, 2010
    Hello everyone,

    Sorry for posting in here, I seen some Yoggie discussions around JanusPA in here and I really don't know where else to turn, I tried emailing Yoggie and Kyle.

    I bought a Yoggie Gatekeeper Pro on Ebay, it powers on but the SD and security alert lights keep flashing, it is getting detected as Yoggie Gatekeeper in Win7 device manager but I doubt I can find Win7 64bit drivers.

    I bought it to put JanusPA onto it but it looks like Yoggie are bust and JanusPA is on hold.

    Can anybody please help me?

    Kind Regards
  2. lotuseclat79

    lotuseclat79 Registered Member

    Jun 16, 2005
    Hi rthorntn,

    Kyle posted in the thread Is the JanusPA project dead? the reasons the project is on hold.

    Don't hold your breath about your issue - it's not very likely you will get any help to make the device work with JanusPA.

    OTOH, if you do a search for: Win7 64-bit drivers
    you may be able to find the information that will help that particular issue.

    -- Tom
  3. pandlouk

    pandlouk Registered Member

    Jul 15, 2007
    Hi Richard,

    I uploaded at hotfile the latest drivers of Yoggie in a zip archive.
    The followind files are included:
    The windows version "Yoggie_5.4.0.exe" supports XP 32bit and Vista/7 32bit and 64bit versions.
    The Mac version "Yoggie_5.4.0.dmg" supports OS X 10.5.6 (Leopard) and OS X 10.6 (Snow Leopard).
    An Excel file "Yoggie Default Settings.xls" with the default configurations for low, medium and high security policies.

    Yoggie 5.4.0.zip

    Hope it helps,
  4. rthorntn

    rthorntn Registered Member

    Aug 17, 2010
    Hi Panagiotis,

    Brilliant thank you, I use OS X 10.6 as my main computer.

    Trying it now, plugged in by USB, no dice.

    So if I plug in a PC using ethernet it gets a 192.168.4.x address and I see an arp entry for but I cant find any open ports on .1 with nmap...

    Thanks again.

    Kind Regards
  5. pandlouk

    pandlouk Registered Member

    Jul 15, 2007
    You are welcome. :)
    You mean that is not recognised?
    I have a yoggie pico and from personal experience sometimes is not initiated when plugged in (I believe it does not always discarge completely the static current).
    When it happens I unplug/replug the usb 1-2 times and then it is solved.
    You can identify that yoggie reboots/initialize correctly by it's leds.
    When pluged-in and booting correctly the power led stays on and the others blink for 4-5 seconds; if only the power led is on you will have to unplug it and replug it.

    You mean for accessing the yoggie control?
    Try the following addresses through the browser: (? not sure about this)

    When connected as USB, the default address should be (at least on my yoggie pico is this...)

    Last edited: Aug 18, 2010
  6. goldenone

    goldenone Registered Member

    May 31, 2007
    Forgive me for not answering e-mails within 24 hours. Working two jobs takes a lot of my time.
    What version does the web interface claim it is? Now that their is no update server, older version are vulnerable.


    Here is a document I put together some time ago in regards to this. Enjoy.

    Hacking the Yoggie Gatekeeper Pro

    I ordered a Yoggie Open Firewall in hopes of finding a replacement for the Gumstix NetDUO. I received a Open Firewall SOHO instead. I reported this to Yoggie, but they didn't seem to mind that they just shipped a product that was worth $180 more than what I paid. I didn't want the Gatekeeper Pro, I wanted the Open Firewall. I was just dying to see how similar the Yoggie was to the Gumstix NetDUO. As it turns out they are very similar, with some extra perks. In fact, Yoggie reverse engineered Gumstix products to build their own at a much lower cost.

    Yoggie spent a lot of time to secure the Gatekeeper Pro from hackers. After all, it does provide “corporate-grade security for home or small office network“. The Gatekeeper Pro offers anti-virus, anti-spyware, anti-spam, anti-phising, IPS, IDS, firewall, and much more. The Open Firewall is just a firewall. They both use the exact same hardware. However, the Open Firewall allows you to login over SSH. The Gatekeeper Pro does not allow or want the user to be able to snoop around with what's going on inside the device. Considering I'm not a big fan of locks, I knew what had to be done.

    The first thing I did was a full TCP port scan to see what was open. NMAP was scanning too fast, and the Firewall blocked the “Portscan Attack”. Scanning more than 5 ports per second seemed to fail, and it would take days to scan every port. Disregard NMAP...

    I did a bit of searching on Google, and found that someone had previously found a vulnerability in the Pico and Pico Pro[1]. To sum it up, someone discovered that can use back-ticks to execute a command from the "PING TOOL" in the web interface. So I tried the same thing on the Gatekeeper Pro, and it worked....for about two hours. What I didn't realize was the Gatekeeper Pro does automatic updates in the back ground. Yoggie appears to use a progressive update system. Version 1.1.0 is updated to version 1.1.1, then another update changes it from version 1.1.1 to 1.1.2, and so on.

    At about version 1.2.0, the back-tick vulnerability was patched by the automatic updates. As a hacker, it's very frusterating when you're exploit just quit working and you don't immediately know why. As soon as I realized what was happening, I let the device stay online for a whole day before using it again. I wanted to make sure it had the latest firmware version before I continued my hunt for a hole to exploit.

    After work the next day, I checked on it to see if the firmware upates were complete. It had been updated from version 1.1.x to I rebooted it and let it sit while I had dinner, then checked it again. Still version It appeared as though the updates were finished. Now it was time to find another hole. Like an idiot, I left this plugged into the Internet while doing this. Bad, bad idea.

    After a few hours of input sanitation checking, I figured out that the certain characters were being treated as a “Hack Attempt”. Yes, it literally tells you that you've tried a “Hack Attempt”. However, the dollar sign ( $ ) was not one of these characters. So I thought to myself, “What web server environmental variables can the client web browser manipulate, and would those variables automatically be resolved in a CGI script?”......”I think I might be onto something.” My first thought was REFERER, which is read on the server side as $HTTP_REFERER. So instead of putting in an IP address into ping, I put “$HTTP_REFERER”. Before I clicked on the “Ping” button, I used the “Modify Headers” Add-on for Firefox to change the Referer header that was passed to the server. Instead of the referring URL, I used “`cp -f /etc/shadow shadow.txt`”. Then a simple click on “Ping” and a few seconds later, https://yoggie.yoggie.com:8443/cgi-bin/shadow.txt was there. Stuck the root password into John the Ripper for further analysis. After two weeks it is still trying to crack the password.


    What made this so wonderful was the fact that lighttpd (the web server on the Yoggie) was being run by root. So every exploit against the web server would be run as root. Sweet. Next I looked at the running processes, netstat, iptables, and various directory listings. I found something very interesting. There is a file called “/etc/gumstix-release”. The contents of this file are as follows.

    BUILD_DATE='Mon Jul 17 17:23:16 IDT 2006'

    That confirmed my suspicion, Yoggie was using the same Gumstix buildroot environment that I had been using all along. It seemed fitting since they were using the same CPU and system configuration that the Gumstix NetDUO has. I figured that this is going to be easy to install JanusPA on.....boy was I wrong.

    Just then my Gatekeeper Pro rebooted, and received a firmware update to I tried my exploit again, and it didn't work. I verified nothing changed on my end, tried again, nothing. The update from to patched the vulnerability I had found just hours earlier. Then it dawns on me...Yoggie products are probably reporting back to the company about firewall stats, attacks, etc, etc in order for the company to be able to detect new attacks against their products. They are doing this every hour according to their website.

    On one hand, this is a very cool feature for a security appliance. It's really quite brilliant. Let the hackers hack on your hardware, detect their attacks, send the attack reports and data back to themselves, develop a patch, and apply it within hours. I believe this is Yoggie's “L-8 Security Engine “ or “Adaptive Security Policy “.

    On the other hand, this is a nightmare for a privacy adapter like JanusPA. Software that reports your every move or anything that looks “suspicious” back to a single entity is not at all acceptable. Hence why I want to get JanusPA working on it.

    After a few more hours of research, trying to find another vulnerability to exploit, I decided to take the case off and hope for a COM port or some sort of debug port. They say “be careful what you wish for”; I found what I was looking for and it was micro-sized.

    As it turns out, the whole case is just glued together. A small flat-head screw driver is all that is needed to open the case. After removing the case, I inspected the hardware. Two RJ45 ports, an SD Card reader, a USB port, Intel Xscale PXA270 @ 520MHz CPU, 4 RAM chips, a Sharp NAND storage chip (128MB), a mini 20 pin interface, and various smaller parts such as resistors and capacitors. The USB cable is soldered onto the board, and cannot be remove easily. The most interesting and useful part of the hardware is the 20 pin port on the corner of the board. Yoggie says this is the Debug port for developers, but doesn't offer a developer board. They do however offer a PDF that shows what each pin on the connector is for. Time for some hardware hacking....fun fun.

    The 20 pin connector is about an inch in width, and each pin on the flex cable connector is about 0.5mm wide. Very, very small. After a trip to Radio Shack and Fry's, I had all the tools and supplies I needed to solder to the back pins on the connector. Keeping in mind I haven't soldered anything in about 3 years, I took my time getting the wire soldered to the back of the connector. The problem was that the small wire I picked up at Radio Shack wasn't small enough. The bare wire was about double the side of the pin, so one wire would cover two pins and short out. Not fun.

    After that didn't work, I found a place that sold flexible ribbon cables. The smallest one I found still had pins about four times the size of the pin on the 20 pin connector. I got mid-evil on this cable, cutting it into individual strands, trimming the width of cable's head to about 0.5mm. After I had three strands of cable striped and clipped, I laid them over each other, taped them together, while putting the tips of the wires as close together as possible without causing a short. Several attempts and days later, I finally made a “ribbon” or “flex” cable that worked on the 20 pin debug port on the Yoggie. What I mean by “worked” is I was able to get a serial console on the Yoggie. I can't stress how much of a pain in the ass it was to get a console connection to the Yoggie, but it is possible.

    The reason I needed console on the Yoggie was so I could flash the JanusPA firmware to the device. However, you have to do this from u-boot, and in order to get to a u-boot command prompt, you have to press any key before the number of seconds specified in the “bootdelay” setting of u-boot. Yoggie thought it would be funny and set this to zero ( “0” ). Their goes the easy way to flash a Yoggie from u-boot....

    U-boot has utility programs, fw_printenv and fw_setenv, that let you view and set the u-boot settings from within Linux. Very cool.....if it worked as advertised. fw_printenv doesn't read the correct partition (mtd1). Instead it tries to read mtd0, then fails, and display's the “default configuration”. Great...

    So here I am with a serial connection to this cool little hardware device. I tried to guess a few password's for the “root” account, but didn't have any luck. John the Ripper hasn't produced anything yet either. However, there was a “default” account with no password, so I used it to login. The device doesn't have the “sudo” command, so I could not elevate to root easily. So how could I get root?

    Then I remembered that the lighttpd was running as root, and had several CGI scripts. I located these scripts in the “/var/www/cgi-bin/” directory. Well well, it appears that the owner of the CGI is the “default” account, yet the web server is running as root. So anything in a CGI script is being run as root. At this point, I knew I was going to get root. So I copied /etc/shadow to my home directory and modified it so the root password was blank. Then I modified one of the CGI scripts to copy the shadow file from my home directory over the shadow file in /etc. Then I ran the CGI script through the web interface, went back to the console to verify that the /etc/shadow file had been replaced. Sure enough, it was replaced. I then logged out of console, and logged back into the device as “root” with no password.

    So, that is how you get root on a Yoggie Gatekeeper Pro SOHO device. After an hour or so of full access to the device, it was obvious they wanted to keep hackers out. They way they do their Anti-Virus updates is very insecure and could be cloned by anyone who saw how it worked. I've choosen not to publish details about this because it would potentially harm Yoggie's profits. I'm not out to screw them over, I just wanted my Open Firewall that I could install JanusPA onto, and they sent me the wrong one.

    [1] http://www.securityfocus.com/bid/24743/info

    Startup screen output

    U-Boot 1.1.4 (Jul 7 2006 - 15:49:32)

    U-Boot code: A1700000 -> A171E650 BSS: -> A17230C0
    RAM Configuration:
    Bank #0: a0000000 64 MB
    Bank #1: a4000000 64 MB
    Bank #2: a8000000 0 kB
    Bank #3: ac000000 0 kB
    Flash: 8 MB
    In: serial
    Out: serial
    Err: serial
    Hit any key to stop autoboot: 0
    ## Booting image at 00060000 ...
    Image Name: Yoggie Kernel 1.0.1
    Image Type: ARM Linux Kernel Image (uncompressed)
    Data Size: 2775248 Bytes = 2.6 MB
    Load Address: a0008000
    Entry Point: a0008000
    Verifying Checksum ... OK

    Starting kernel ...

    Linux version (root@ubuntu) (gcc version 3.4.4) #364 PREEMPT Sun Mar 18 09:17:25 UTC 2007
    CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE)
    Machine: Yoggie Board
    Memory policy: ECC disabled, Data cache writeback
    Run Mode clock: 208.00MHz (*16)
    Turbo Mode clock: 416.00MHz (*2.0, active)
    Memory clock: 208.00MHz (/2)
    System bus clock: 208.00MHz
    CPU0: D VIVT undefined 5 cache
    CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
    CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
    Built 1 zonelists
    Kernel command line: console=ttyS1,115200 rw root=31:04 rootfstype=jffs2 ramdisk_size=40960 mac0=<CENSORED> mac1=<CENSORED> yserial=PR00-1907-0000-0000-XXXX
    Console: colour dummy device 80x30
    Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
    Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
    Memory: 64MB 64MB 0MB 0MB = 128MB total
    Memory: 126848KB available (2320K code, 409K data, 92K init)
    Mount-cache hash table entries: 512
    CPU: Testing write buffer coherency: ok
    Yoggie GPIO Leds driver v1.0, (c) 2006 Yoggie Security Systems.
    NET: Registered protocol family 16
    Generic PHY: Registered new driver
    pxa27x: CPU frequency change support initialized
    NetWinder Floating Point Emulator V0.97 (extended precision)
    JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
    Initializing Cryptographic API
    io scheduler noop registered (default)
    pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART
    pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART
    pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART
    RAMDISK driver initialized: 16 RAM disks of 40960K size 1024 blocksize
    loop: loaded (max 8 devices)
    Davicom DM9161E: Registered new driver
    Davicom DM9131: Registered new driver
    dm9000 Ethernet Driver
    eth0: dm9000 at c8852000,c8854004 IRQ 43 MAC: <CENSORED>
    eth1: dm9000 at c8856000,c8858004 IRQ 44 MAC: <CENSORED>
    Probing Nor flash at physical address 0x00000000 (16-bit bankwidth)
    Nor flash: Found 1 x16 devices at 0x0 in 16-bit bank
    Intel/Sharp Extended Query Table at 0x0031
    Using buffer write method
    cfi_cmdset_0001: Erase suspend on write enabled
    RedBoot partition parsing not available
    cmdlinepart partition parsing not available
    Using static partitions on Nor flash
    Creating 4 MTD partitions on "Nor flash":
    0x00000000-0x00040000 : "BootLoader"
    0x00040000-0x00060000 : "BootLoaderParams"
    0x00060000-0x003e0000 : "Kernel"
    0x00440000-0x00800000 : "Empty"
    Yoggie nand init
    NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit)
    Scanning device for bad blocks
    cmdlinepart partition parsing not available
    Creating 2 MTD partitions on "yoggie-nand":
    0x00000000-0x02800000 : "System Area"
    0x02800000-0x08000000 : "Main"
    pxa27x_udc: version 01-01-2006
    ether gadget: using random self ethernet address
    ether gadget: using random host ethernet address
    usb0: Yoggie Gatekeeper, version: May Day 2005
    usb0: using pxa27x_udc, OUT ep2out-bulk IN ep1in-bulk STATUS ep3in-intr
    usb0: MAC <CENSORED>
    usb0: RNDIS ready
    mice: PS/2 mouse device common for all mice
    NET: Registered protocol family 2
    IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
    TCP established hash table entries: 8192 (order: 3, 32768 bytes)
    TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
    TCP: Hash tables configured (established 8192 bind 8192)
    TCP reno registered
    TCP bic registered
    NET: Registered protocol family 17
    VFS: Mounted root (jffs2 filesystem).
    Freeing init memory: 92K
    JFFS2 notice: (1) read_dnode: header CRC failed on node at 0x1ddf7c0: read 0xffffffff, calculated 0xa3b1376b
    JFFS2 notice: (1) read_dnode: header CRC failed on node at 0xe2f7e4: read 0xffffffff, calculated 0x171eb603
    JFFS2 notice: (1) read_dnode: header CRC failed on node at 0xe26fcc: read 0xffffffff, calculated 0x4514b49f
    NET: Registered protocol family 1
    JFFS2 notice: (193) read_dnode: header CRC failed on node at 0xe3b7f0: read 0xffffffff, calculated 0xed994922
    JFFS2 notice: (193) check_node_data: wrong data CRC in data node at 0x0233a000: read 0x7e4ae71a, calculated 0xe4aa0e2f.
    JFFS2 notice: (193) check_node_data: wrong data CRC in data node at 0x01dcc000: read 0x634b826d, calculated 0xe83270cc.
    kjournald starting. Commit interval 5 seconds
    EXT3 FS on ram0, internal journal
    EXT3-fs: mounted filesystem with ordered data mode.
    jffs2_scan_eraseblock(): Node at 0x0028c7f8 {0x1985, 0xe002, 0x00000171) has invalid CRC 0xe0021985 (calculated 0x5ec099b9)
    jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0028c7fc: 0x0171 instead
    jffs2_scan_eraseblock(): Node at 0x0028d7f8 {0x1985, 0xe002, 0x00000171) has invalid CRC 0xe0021985 (calculated 0x5ec099b9)
    jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0028d7fc: 0x0171 instead
    eth0: link down
    eth1: link down
    JFFS2 notice: (24:cool: check_node_data: wrong data CRC in data node at 0x048d9000: read 0x18378a92, calculated 0x65aa4a4e.
    eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
    JFFS2 notice: (24:cool: check_node_data: wrong data CRC in data node at 0x048d7800: read 0xd5a543f6, calculated 0x6e8abf4d.
    JFFS2 notice: (24:cool: check_node_data: wrong data CRC in data node at 0x048df000: read 0x4fc1ca1a, calculated 0x9fcd3ccc.
    JFFS2 notice: (24:cool: check_node_data: wrong data CRC in data node at 0x048de000: read 0x4fc1ca1a, calculated 0xd2be4278.
    JFFS2 notice: (24:cool: check_node_data: wrong data CRC in data node at 0x048db800: read 0x91c3ceb3, calculated 0xc89ec2b6.
    JFFS2 notice: (24:cool: check_node_data: wrong data CRC in data node at 0x048dd000: read 0x6a4b6283, calculated 0x10304c8.
    JFFS2 notice: (24:cool: check_node_data: wrong data CRC in data node at 0x048da800: read 0x6a4b6283, calculated 0x25ade537.
    JFFS2 notice: (191) check_node_data: wrong data CRC in data node at 0x019c2800: read 0xc05b3d35, calculated 0x72152707.
    JFFS2 notice: (191) check_node_data: wrong data CRC in data node at 0x017d3000: read 0xb7403873, calculated 0x89cd19a9.
    JFFS2 notice: (191) check_node_data: wrong data CRC in data node at 0x01bc4000: read 0xc567f269, calculated 0x2f62a181.
    Dec 31 16:01:10 policymanager: Standalone mode.
    JFFS2 notice: (191) check_node_data: wrong data CRC in data node at 0x01dda800: read 0x1a39be4c, calculated 0x38f3ed56.
    ip_tables: (C) 2000-2006 Netfilter Core Team
    ip_conntrack version 2.4 (1024 buckets, 8192 max) - 240 bytes per conntrack
    Dec 31 16:01:22 lighttpd[597]: (log.c.75) server started

    Welcome to the YPSG

    ypsa login: root
    Welcome to YPSG!

    As for the Privacy adapter software, that will be release soon for anyone to download and install on their hacked Yoggie's.


  7. rthorntn

    rthorntn Registered Member

    Aug 17, 2010
    Thanks all.

    Hi Kyle,

    Dang I missed your reply, what an idiot I am, I put this in the cupboard, but it could be time to get it out again, so if I read correctly you are releasing the code and I need to get me a botched serial cable, would you be able to help me with this please?

    Kind Regards
Thread Status:
Not open for further replies.