Enphase Data Access

12357

Comments

  • brturn
    brturn Registered Users Posts: 7
    Re: Enphase Data Access

    Sandeen,

    Thanks, that was helpful. That board's boot-select jumper is tied to a programmable logic chip which sends PCI commands to the ARM. Unfortunately our Envoy does not have the logic chip, nor the PCI bus. It may be that this bus was taken over by some component of the Freescale package, but it is not obvious to me. It is also not obvious how the PCI commands translated into boot selection.

    I've traced system boot-up from the start, and it appears that the flash-disable attack will work:

    1) ecos/packages/hal/arm/mx27/emu/current/include/hal_platform_setup.h

    Not sure where this code is stored, but probably in the NOR flash. It sets up the chip and checks the location of the PC, which appears to be in NOR flash, sets the aforementioned NOR_FLASH_BOOT in the boot-select register, and jumps to a known location for RedBoot.

    2) RedBoot main: ecos/packages/redboot/current/src/main.c

    A list of initialization functions is called..

    3) Redboot_INIT_FIRST: ecos/packages/redboot/current/src/flash.c

    Setup flash chip and read the directory block. This is the first line of output from nbias' log (read at 0xc07e0000 - the FIS directory block).

    4) Redboot_INIT_SECOND: ecos/packages/redboot/current/src/fconfig.c

    Reads the flash configuration block (0xc07ff000), the second line of output from nbias' log. This is the block that contains the boot script.

    5) At this point, Redboot and the boot script are loaded and the script will be executed. We cannot hit Ctl-C, so it continues on.

    6) "fis load ..." : ecos/packages/redboot/current/src/flash.c

    If we disable the chip before this point, the "fis load" command will attempt to read the directory block and locate a partition named "kernel". This step will fail, and exit with an error. It will leave the global "load_address" un-set (let's assume the value of this variable is zero initially, although I cannot find where this might occur).

    7) "exec ..." : ecos/packages/hal/arm/arch/current/src/redboot_linux_exec.c

    The exec command sets the variable "base_addr" to "load_address", which we assume is zero. No option re-sets this value, so when it checks for a valid address, it finds zero, and exits.

    8) Boot script is finished, redboot reverts to reading from the console.

    Attack complete. This confirms case #2 from my original post.

    Alternate attack:

    The goal of the alternate flash-disable attack is to make the read in step 4 return garbage (or zero) and drop to prompt. Since there is no (human achievable) delay between power on and read of this block, this flash-disable attack must work statically.

    The first idea that comes to mind is to tie one of the address lines of the NOR flash (any of the enabled bits in the address 0x007e0000) to the NOR flash reset pin, so any attempt to read from these addresses will return zero. Would have to check the pin timings to see if this works correctly. Would also have to see if any of these address pins are exposed beneath the NOR flash, or as traces above.
    [EDIT: Adding pinouts for the NOR flash]

    The NOR flash is an Intel StrataFlash P30 (640P30B). Same basic attack mode as the NAND flash - disable the chip.

    I mapped photos of the front of the board onto the rear of the board to see which pins are accessible from below. A cluster of pins are accessible, but unfortunately none of the useful ones.

    However, the OE# (Output Enable) pin is edge-exposed. Holding this pin high should cause the output pins to float(?), disabling reads from the chip.

    --Bryan
  • System2
    System2 Posts: 6,290 admin
    Re: Enphase Data Access

    I traced out the boot select pins before giving up and going with the jtag route. The boot pins are tied to RN2, which is located near the edge of the board. Pin 1 is labeled, and resistors 1-4 map to boot3-boot0. They are wired to boot0=1, boot1=0, boot2=1, boot3=0.
  • brturn
    brturn Registered Users Posts: 7
    Re: Enphase Data Access
    colincross wrote: »
    The boot pins are tied to RN2, which is located near the edge of the board.

    Confirmed, thanks! How'd you trace the pins all the way out there? Is there a technique for finding where the embedded traces pop out? I could definitely use some help finding an easier-to-reach control pin on the NOR Flash chip.

    This also opens up the possibility of tying all four BOOT pins to ground and using the bootstrap programming mode (UART/USB programming) of the MX27. Is there a utility program (like a COM terminal or netcat) that can be used to send and receive arbitrary messages on the USB bus?

    --Bryan
  • System2
    System2 Posts: 6,290 admin
    Re: Enphase Data Access

    You can sort of see the pattern of the BGA balls in the vias on the bottom side of the board. Once I locate the via that is probably underneath the pad you're looking for, I just use a multimeter set to continuity tester to poke around in likely locations until it beeps. You can drag the probe along a row of pins and test them all very quickly. In this case, I knew I was looking for pullup resistors or a resistor network, so it didn't take long to find.

    For bootstrapping, I would guess UART would be easier than USB. USB probably requires a device-side port, but only the host-side port is externally available. There might be pins for the device port somewhere, I haven't looked for them. The console is easy to access, all you need is something like TTL-232RG-VSW3V3-WE from FTDI (don't connect the power line, just GND/TX/RX), and having access to the console is extremely useful for debugging anyways. I think the software required for USB or UART bootstrapping is called "IMX ATK Toolkit".
  • brturn
    brturn Registered Users Posts: 7
    Re: Enphase Data Access
    colincross wrote: »
    You can sort of see the pattern of the BGA balls in the vias on the bottom side of the board. Once I locate the via that is probably underneath the pad you're looking for, I just use a multimeter set to continuity tester to poke around in likely locations until it beeps. You can drag the probe along a row of pins and test them all very quickly. In this case, I knew I was looking for pullup resistors or a resistor network, so it didn't take long to find.

    Ah, basically the same technique I use. Although I can't rake my continuity tester down a line of pins as it takes a little while to signal the connection. But my multimeter is the cheap digital variety.

    Right now I'm using magnet wire to reach the pins below the NOR flash, and attempting to locate an exposed pad for the OE# pin. I don't trust my ability to hit the microscopic pin with a live wire in a 1 second window after bootup.
    colincross wrote: »
    For bootstrapping, I would guess UART would be easier than USB. USB probably requires a device-side port, but only the host-side port is externally available. There might be pins for the device port somewhere, I haven't looked for them. The console is easy to access, all you need is something like TTL-232RG-VSW3V3-WE from FTDI (don't connect the power line, just GND/TX/RX), and having access to the console is extremely useful for debugging anyways. I think the software required for USB or UART bootstrapping is called "IMX ATK Toolkit".

    The USB idea stemmed from some code in Redboot for bootstrap programming via USB-OTG, but after examining the USB port on the Envoy it appears to be the standard 4-pin "A" port. Would prefer a mode of attack that did not require soldering (after all, if you're willing to soldier a COM header then a JTAG is not much further). Also, future revs of the board may expose the JTAG (or COM) pins.

    Thanks for the IMX Toolkit info. I found it on the Freescale site under dev tools for the MX27 development board:
    http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX27PDK

    --Bryan
  • System2
    System2 Posts: 6,290 admin
    Re: Enphase Data Access
    brturn wrote: »
    The USB idea stemmed from some code in Redboot for bootstrap programming via USB-OTG, but after examining the USB port on the Envoy it appears to be the standard 4-pin "A" port. Would prefer a mode of attack that did not require soldering (after all, if you're willing to soldier a COM header then a JTAG is not much further). Also, future revs of the board may expose the JTAG (or COM) pins.

    You could probably avoid soldering the COM header, just wedging in a 4 pin male header on the end of the console cable.
  • rahvin
    rahvin Registered Users Posts: 10
    Re: Enphase Data Access

    I read through this thread with interest. Although not a current owner I plan to purchase solar panels in the future and was researching the differences between Micro-Inverters and standard inverters and stumbled over this page. I'm amazed by the hardware wizards on this forum!

    Anyway, after reading a bit I feel like the software attack side is being neglected. As noted earlier someone said they had access to a the system and password file. I noted the amazing attempt to use a GPU EC2 instance to try to crack the password hash that failed but I feel like something was overlooked with that regard (no disrespect intended, I think what you did was amazing). I don't have a ton of experience with Salting but I understand it enough I think. Anyway, I see a couple ways to crack the root password. Depending on the level of security I'm willing to bet there should be a few openings.

    The First attack on the root password would be the following.

    The Salt value should be stored on the root partition for decoding the password hash. So if you have access to the root partition it's simply a matter of finding the file with the Salt value in it. It's possible it's stored in encrypted form but again the decryption key would need to be present to decode it for use.

    If they concealed the salt value it should be possible to reverse it using the known login/pass provided previously in the thread. A post noted that admin/admin was a valid non-privileged user. Knowing that the admin login has the password admin should make it possible to reverse out the Salt value from the Hash.

    Once you have the Salt value I see a couple paths to the root password but first there should be a discussion on the security level and how smart they were about securing the system. Given that their own techs need access to the system to make their service provisions work I would wager they need root access. Although it's possible that they set the system up such that controlling the inverters can be done through unprivileged user accounts I doubt that's the case.

    The second concern would be whether each system has a unique root password or if they are all the same. This is where the Salt security comes into play. If the salt value is stored in plain text on the root partition I'd wager it's a single root password for every inverter. If on the other hand they went to an effort to protect the system even if it's mounted separately I'd wager each system has it's own unique Root password. But if they have a unique root password it needs to be something that the techs can readily use or get access to. If on the long shot the system does have a unique root password I'd be willing to bet it's tied directly to the serial number or other unique identifier.

    Then there is the final issue, the length of password. The use of pass-phrases is non-existent. The Boss's and Tech's aren't going to want their employees spending a bunch of time typing in long passwords. So I'd probably bet the password is under 8 chars, if it's more than that it's a custom password based on the serial number that's the same length.

    So here's how I see the attack going:

    First either find the Salt Value or reverse the salt value from the known login/pass.

    Second, take a standard dictionary table and add all the unique identifiers related to the hardware to the table.

    Third, take another GPU EC2 instance and try to smash the hash using the known Salt value and the custom dictionary table set with an 8 char max.

    Fourth, if step three doesn't work I run the custom dictionary with the number of char's of the largest unique identifier I can find but narrow the dictionary to those values.

    I'd put high odds on success for this attack.

    The second best attack on Root I see would be to run a local/remote root exploit on a known vulnerability on the software they have running. If they are smart they chrooted all the daemons and software to avoid this attack. I doubt that's the case. Given the age of some of these there should be high odds that one of the software versions used has an un-patched root exploit. There could even be a root exploit for SSH if they aren't patching the system (which I doubt they are).

    That's the two I thought of last night while thinking about the thread while I tried to fall asleep. I'm sure some of the wizards on here can think of other software exploits. If you can crack the root password on a single system it should be easy to determine how they are setting the passwords (single or unique ID). If this isn't successful it might be that the root account is fully secured, ie. a random password (because they setup the system securely such that all the work they do can be done with user space tools and unprivileged accounts). Out of curiosity, has anyone run one of the black hat vulnerability tools on it to see if there is a remotely exploitable root access available on one of the daemons that responds to network traffic?

    Anyway, I might be willing to help if someone that has dd'd the root partition wants to post it and let the rest of us take a stab at cracking the system. From my perspective the best hack is one that doesn't require a hardware hack even if you hardware wizards are amazing!

    Cheers,
    Rahvin
  • nsaspook
    nsaspook Solar Expert Posts: 396 ✭✭✭
    Re: Enphase Data Access

    I agree. I would think that each unit would have it's own unique root password that's in a database at the company by serial number. It's possible to use the chip SRAM or other hardware to generate it own unique signature that only 1 chip has using a technique called PUF.
    http://en.wikipedia.org/wiki/Physical_Unclonable_Function

    If they are using something like this then a brute force attack is usually the only way to crack it unless a "social engineering" attack is used.
    http://en.wikipedia.org/wiki/Social_engineering_%28security%29

    Analyzing small changes in current flow or changes in the EM emissions (side channel attack) can help reduce the effort if their decryption function design is not secure from this method.
    http://en.wikipedia.org/wiki/Side_channel_attack


    This is just a example, no electrons were harmed in this post.
  • sandeen
    sandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    nsaspook wrote: »
    I agree. I would think that each unit would have it's own unique root password that's in a database at the company by serial number

    It's not, the passwd files are identical across several boxes.

    Edit: Also, if you look back though the thread, you'll probably find that it is not salted.
  • sandeen
    sandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    rahvin wrote: »
    If they concealed the salt value it should be possible to reverse it using the known login/pass provided previously in the thread. A post noted that admin/admin was a valid non-privileged user.

    admin/admin is only used in a .htaccess file for the webserver; totally different authentication.
  • nsaspook
    nsaspook Solar Expert Posts: 396 ✭✭✭
    Re: Enphase Data Access
    sandeen wrote: »
    It's not, the passwd files are identical across several boxes.

    Edit: Also, if you look back though the thread, you'll probably find that it is not salted.

    I don't have a unit to look at but if they are the same it might just be a shadow password file that some systems use to keep Unix compatibility with uid/gid system programs but the actual access files are elsewhere like selinux.
    http://www.centos.org/docs/4/html/rhel-rg-en-4/s1-selinux-files.html

    Having one master root password for all systems is poor security because it allows a distributed name-space attack. Because it's a money center for the company I would think they put a lot of effort in making it secure.

    Good hunting.
  • Peter_V
    Peter_V Solar Expert Posts: 226 ✭✭✭
    Re: Enphase Data Access

    I believe the assumption is that the individual Envoys will be behind the home's firewall and protected from attacks by NAT.

    Distributed attacks aren't any good if you can't access the vulnerable hosts.
    nsaspook wrote: »
    I don't have a unit to look at but if they are the same it might just be a shadow password file that some systems use to keep Unix compatibility with uid/gid system programs but the actual access files are elsewhere like selinux.
    http://www.centos.org/docs/4/html/rhel-rg-en-4/s1-selinux-files.html

    Having one master root password for all systems is poor security because it allows a distributed name-space attack. Because it's a money center for the company I would think they put a lot of effort in making it secure.

    Good hunting.
  • nsaspook
    nsaspook Solar Expert Posts: 396 ✭✭✭
    Re: Enphase Data Access
    Peter_V wrote: »
    I believe the assumption is that the individual Envoys will be behind the home's firewall and protected from attacks by NAT.

    Distributed attacks aren't any good if you can't access the vulnerable hosts.

    I was referring to the password file. If it's really the same on all units (A Big If) and that's really the access code storage file, that's the object to brute force in your own sandboxed unit. I personally think the chances are low that's the real security.
  • Peter_V
    Peter_V Solar Expert Posts: 226 ✭✭✭
    Re: Enphase Data Access
    nsaspook wrote: »
    I was referring to the password file. If it's really the same on all units (A Big If) and that's really the access code storage file, that's the object to brute force in your own sandboxed unit. I personally think the chances are low that's the real security.

    My point is, for it to be a vulnerability, someone has to be able to ACCESS the password file.

    You can't do a distributed attack if you can't get to the box.

    As near as I can tell, the point of the password file is for telneting/etc. into the box which, in this case, generally means you have to be locally connected to it.
    I suspect it's mostly intended for maintenance functions, i.e. working on the envoy when it is on the bench. Having to look up a password for each individual box would be cumbersome and add very little security (see above, a vulnerability is only a vulnerability if someone can exploit it)
  • nsaspook
    nsaspook Solar Expert Posts: 396 ✭✭✭
    Re: Enphase Data Access

    My reading of some earlier posts was that someone does have the password file from a early unit.
  • brturn
    brturn Registered Users Posts: 7
    Re: Enphase Data Access

    Yes, there have been multiple boxes entered (old and new) and the root password hash was the same on all of them. It is available back in msg #62 (http://forum.solar-electric.com/showpost.php?p=65531&postcount=62). This is a standard salted MD5 hash, and easily entered into a brute-force tool.

    The password was brute-forced for lengths 0-5 and revealed nothing. The MD5 algorithm is a 128-bit hash. A true brute-force attack would examine all possible passwords containing any of 95 printable characters. That's roughly 6.57 bits per character, so a maximum password length of 19.48 characters is needed. Due to birthday attacks, we have a reasonable chance of finding a hash at half this length, or 9.74 characters (64 bits).

    My computer has 8 cores and each core can test 27000 passwords per second, which would have a reasonable chance of cracking the password in 2,708,066 years. At 180W, and $0.09 per kWh, that's roughly $47 billion dollars to crack the root password.

    I'm sure there's an error in there, but even if I'm off by three orders of magnitude, you can see the futility of the effort. It's much cheaper (and more fun!) to find another way in.

    Speaking of which.. my JTAG just arrived. :)
    --Bryan
  • rahvin
    rahvin Registered Users Posts: 10
    Re: Enphase Data Access

    Step back a second. I doubt anyone knows Enphase's sales numbers but they aren't one off hand manufacturing these. So you've got a product that's mass produced so the question is are they writing a custom password to every unit or are they writing a common password?

    If you assume they are a secure organization you would assume they are going to take every precaution. But the problem is they are a small company who's primary business is a piece of hardware that they have assumed is behind a firewall. This can be shown because they set it up with a VPN tunnel to penetrate a secure system (and exposed systems to hacking). Like most small companies they are going to outsource the software stack (beyond their own tools) to a subcontractor that's probably picked on price. This subcontractor is going to care about security as much as their client.

    I think it's going to be pretty likely that every system is identical down to the root password unless someone finds evidence of much higher security such as selinux profiles or IDS systems. Although you might want to believe they secured the system it's more likely they didn't and that the concerns that this is a gaping hole in your firewall are justified.

    So where do we go? First I hope the hardware wizards didn't stop because of my post. They're analysis could be crucial later depending on how successful the software attacks are? Has anyone checked the SSH version to see if there is a vulnerability? What about the other network aware software? From the kernel version it appears the software stack is several years old and probably unpatched so there might even be a kernel vulnerability but that would require local access.

    And finally, anyone have a copy of the root partition available so we can all mount it and investigate it?
  • rahvin
    rahvin Registered Users Posts: 10
    Re: Enphase Data Access
    brturn wrote: »
    Yes, there have been multiple boxes entered (old and new) and the root password hash was the same on all of them. It is available back in msg #62 (http://forum.solar-electric.com/showpost.php?p=65531&postcount=62). This is a standard salted MD5 hash, and easily entered into a brute-force tool.

    Wait, someone else said the password isn't salted. We need to at least agree on that, Is the password salted or not? That salt value becomes crucial if it's salted, if it's not then it should have been cracked with the GPU EC2 attempt. The research I've read says a GPU instance like that can crack a hashed password in at most a couple hours so if it's not salted the password is definitely not 5 chars.

    I'm a little curious about the EC2 attempt, was a dictionary used or just a random char attack and what was the parameters (ie upper/lower/numbers/special)?
  • sandeen
    sandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access

    Distributing the image would probably violate Enphase's copyright...
  • sandeen
    sandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    rahvin wrote: »
    Wait, someone else said the password isn't salted. We need to at least agree on that, Is the password salted or not? That salt value becomes crucial if it's salted, if it's not then it should have been cracked with the GPU EC2 attempt. The research I've read says a GPU instance like that can crack a hashed password in at most a couple hours so if it's not salted the password is definitely not 5 chars.

    I'm a little curious about the EC2 attempt, was a dictionary used or just a random char attack and what was the parameters (ie upper/lower/numbers/special)?

    I might be wrong but I thought starting with $1$$(cryptedpassword) meant it had no salt.... Salt would be between the 2nd and 3rd $ no?
  • Peter_V
    Peter_V Solar Expert Posts: 226 ✭✭✭
    Re: Enphase Data Access
    rahvin wrote: »
    I think it's going to be pretty likely that every system is identical down to the root password unless someone finds evidence of much higher security such as selinux profiles or IDS systems. Although you might want to believe they secured the system it's more likely they didn't and that the concerns that this is a gaping hole in your firewall are justified.

    Correct me if I'm wrong, but the VPN is initiated from the Envoy. Therefor this would only make it a hole in your firewall if someone could intercept the outgoing VPN connection and spoof the Envoy into believing it's connected to Enphase's servers.

    If it was possible to do that, then we could exploit that ourselves to have the Envoy report to a server of our choice. the reason folks are going through all the effort mentioned in this thread is that doing the above is even more difficult than hacking the box.

    For all practical purposes cracking the public keys used by SSL is nearly as difficult as cracking the password hash.

    For someone outside the home to be able to do this would require them to have hacked into a router in the path between the house and Enphase (which is difficult enough) AND have cracked the public keys, AND have figured out the proper handshaking, etc once they can convince the envoy to connect to their server.
  • rahvin
    rahvin Registered Users Posts: 10
    Re: Enphase Data Access
    sandeen wrote: »
    I might be wrong but I thought starting with $1$$(cryptedpassword) meant it had no salt.... Salt would be between the 2nd and 3rd $ no?
    root:$1$$pNDuPsavJsKMV7LpLH29y.:0:0:root:/root:/bin/bash
    guest:!:506:506:Linux User:/home/guest:/bin/sh
    nobody:!:200:200:non-user:/dev/null:/bin/true
    ntp:!:105:105::/home/ntp:/bin/false
    energytracking:$1$$2UsWUEUB3Ky/53aZvd7r20:507:507:Linux User,,,:/home/energytracking:/bin/sh
    

    So according to the following link the Salt value in stored in the passwd file (or it's shadow). I'm assuming that passwd file from a previous post listed above was verified to be from the correct file (shadow vs. passwd). Anyway, from my reading the value is stored like the following:
    For example a salt of "foo" and password of "bar" would hash to this: $1$foo$te5SBM.7C25fFDu6bIRbX1.

    With that basis the salt value is empty meaning that it's a straight hash. According to what I'm reading on stack overflow the best way to crack the hash is using a custom rainbow table. There's some good input on the thread so the link is included below.

    http://stackoverflow.com/questions/420843/need-some-help-understanding-password-salt
    Peter_V wrote: »
    Correct me if I'm wrong, but the VPN is initiated from the Envoy. Therefor this would only make it a hole in your firewall if someone could intercept the outgoing VPN connection and spoof the Envoy into believing it's connected to Enphase's servers.

    You are putting full trust in Enphase. The exploit path you are missing is the hack of enphases own servers that then give the hacker access to every one of these little servers behind firewalls. There is massive potential there, something that could be very appealing to a true cracker that could then social engineer their way into the Enphase network and through that crack then gain access to every single network one of these devices is installed on.

    Having these little servers that create tunnels through firewalls to allow unfettered external access is quite scary. Any company that was aware of it would never allow these things to be connected to anything other than a DMZ or a solitary Internet connection. That Enphase isn't telling people and requesting permission to install this little remote access server into peoples network is another scary indicator.

    Consider for a moment that these thing could very well be hooked up to a major commercial solar power plant where it could be connected to a power companies internal network. This little device could potentially be used to hack into the power grid in a worst case scenario.

    Maybe I'm paranoid but I don't have a lot of faith in trusting other people to protect my network.
  • sandeen
    sandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access

    I think that most rainbow tables in existence are for different hash schemes though; not certain...

    In any case if Enphase is watching, all this should change soon....

    Hi Enphase! :)
  • rahvin
    rahvin Registered Users Posts: 10
    Re: Enphase Data Access

    They might see it, but I doubt they will react. A small company like this isn't going to have the IT assets to realize that installing these insecure little servers into all your customers networks is a recipe for disaster. I can only hope the executives see this thread and do two things. Satisfy the terms of the GPL they are violating so that some competitor doesn't pay for a copyright suit that destroys them and tell all their customers they are network servers that can be remotely accessed through a VPN tunnel while fixing the obvious security issues.

    Anyway back to the issue of cracking the root password hash. I've found a list of rainbow tables for MD5 that are available. The link is below, there are about a dozen different tables with various combinations (lower/upper/numeric/special).

    http://www.freerainbowtables.com/en/tables/

    I'm going to install a network security distro in a VM and take a shot at running the hash through them and see if I get any hits. Gotta download the tables first and they are big.
  • sandeen
    sandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    rahvin wrote: »
    So according to the following link the Salt value in stored in the passwd file (or it's shadow). I'm assuming that passwd file from a previous post listed above was verified to be from the correct file (shadow vs. passwd). Anyway, from my reading the value is stored like the following:

    ... there is no shadow file on the box. And certainly no selinux. :)

    And there is no salt. For example:
    $ openssl passwd -1 -salt "" enlighten 
    $1$$pNKHbEIDlcG.Ryz/Rz/.n.
    $ openssl passwd -1 -salt "salt" enlighten 
    $1$salt$PrW8NorjDBEaHqA5KAHV5/
    

    Likely due to this CVE: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-1058 , a flaw in busybox 1.1.1 and from what we've seen the passwd hasn't changed since the old square Emu days...

    It's not clear to me whether any rainbow tables exist for unsalted md5 passwd files, since that's a relative rarity. Reading up :)

    One thing to bear in mind though, gentlemen, is that once you obtain that root passwd, you can really shoot yourselves in the foot, render your Envoy unusable, and you expose anyone with an internet-facing Envoy to exploit. Just something to keep in mind.
  • sandeen
    sandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    sandeen wrote: »
    It's not clear to me whether any rainbow tables exist for unsalted md5 passwd files, since that's a relative rarity. Reading up :)

    http://lwn.net/Articles/418699/

    but

    http://darthnull.org/2010/12/22/nails-in-the-crypt/
  • rahvin
    rahvin Registered Users Posts: 10
    Re: Enphase Data Access
    sandeen wrote: »
    One thing to bear in mind though, gentlemen, is that once you obtain that root passwd, you can really shoot yourselves in the foot, render your Envoy unusable, and you expose anyone with an internet-facing Envoy to exploit. Just something to keep in mind.

    The danger with worrying about whether revealing the root password being dangerous is assuming the black hats can't do exactly what we are discussing. A determined adversary is as smart as any of us. That we publicly reveal the password and force Enphase to actually secure these devices would be a good thing even if it cuts off our own access later.

    Security through obscurity isn't an answer to the problem. By revealing the root password the users also gain the ability to secure the devices themselves if Enphase isn't willing. In reality Enphase should be telling everyone what these things are capable of (a full server with VPN tunneling) and allowing customers full access to secure the device. Enphase should need permission and to be provided the password by the customer to access the device. Every access should be logged and reported to the customer. The devices should contain full offsite logging (probably as part of the service contract) and IDS systems (file and network) to detect and respond to hacking attempts.

    Network and computer security isn't a joke and obscurity never buys you security, it only ensure that the black hats know things well before the white hats. My main point is that if you think revealing the root password is bad, it's worse that it's not revealed because it means the black hats probably already have it. At least if the users have the password they can secure the device themselves because it's clear Enphase didn't. A single common root password across 10s of thousands of devices is asking for trouble. That's as bad as default logins/pass combinations like linksys/linksys.
  • sandeen
    sandeen Solar Expert Posts: 48 ✭✭✭
    Re: Enphase Data Access
    rahvin wrote: »
    The danger with worrying about whether revealing the root password being dangerous is assuming the black hats can't do exactly what we are discussing. A determined adversary is as smart as any of us. ...

    I agree with everything you say, I just think we are the more motivated crowd, there are more interesting targets for black hats, I expect. ;) By and large these things are not internet facing, so having the root password mostly gives the owner a chance to shoot themselves in the foot and create a support nightmare for Enphase.

    And I'm just saying, while poking around on the box is interesting, you'd better be a ruby whiz or you're not going to get very far -anyway- :)

    Aside: I wish these embedded doohickey things were all like my logitech squeezebox radio. They give you the root password, and tell you to have fun:
    root@squeezeradio1's password: 
    
    This network device is for authorized use only. Unauthorized or improper use
    of this system may result in you hearing very bad music. If you do not consent
    to these terms, LOG OFF IMMEDIATELY. 
    
    Ha, only joking. Now you have logged in feel free to change your root password
    using the 'passwd' command. You can safely modify any of the files on this
    system. A factory reset (press and hold add on power on) will remove all your
    modifications and revert to the installed firmware.
    
    Enjoy!
    #
    

    Now how cool is that?
  • rahvin
    rahvin Registered Users Posts: 10
    Re: Enphase Data Access
    sandeen wrote: »
    Now how cool is that?

    Cool enough that you may have sold one to me. I'll never understand trying to lock customers out. There are many examples (Linksys) where openness actually sold more product.
  • rahvin
    rahvin Registered Users Posts: 10
    Re: Enphase Data Access

    So I took the base64 stored MD5 hash from the password file posted earlier and converted it to the raw Message Digest 5 format which leads to the below MD5 value.
    be44b27c9d80c8afb0e6f58bad374a56
    

    I took the proper MD5 32 char number and ran it through ~328GB worth of 99.6% accurate rainbow tables with Mixed-Alpha, Numeric, Full Symbol and Space Character sets (the full set is listed below)
    abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()-_+=~`[]{}|\:;"'<>,.?/
    

    The password wasn't found in the rainbow tables. I have to say, it's a pretty good password (probably random chars). Output from Rainbow Crack (multi-Threaded) is below:
    plaintext found:            0 of 1 (0.00%)
    total disk access time:     307.73 s
    total cryptanalysis time:   16.79 s
    total pre-calculation time: 34.46 s
    total chain walk step:      799940001
    total false alarm:          23614
    total chain walk step due to false alarm: 347528169
    
    result
    -------------------------------------------------------
    be44b27c9d80c8afb0e6f58bad374a56        <notfound>      hex:<notfound>
    

    I'm gonna submit the MD5 to the rainbow table community and see if it can be cracked by the community but it might have to be brute forced. The proper path to exploit might be to target a known software exploit.