From a thread I've just seen over at DigitalPoint:

http://forums.digitalpoint.com/showthread.php?t=1392703


First of all, What I am going to disclose here is not a fake statement.
I am also the user of Zamfoo and like this script spacially support of Zamfoo.
But I found that every time when you run zamfoo upgrade, Zamfoo decode the server root password and send that password to support@zamfoo.com.
See below email,

version 3.1 license: xxxxxxxxxxxxxxx

debugger: Summary of my perl5 (revision 5 version 8 subversion 8) configuration:

Platform:

osname=linux, osvers=2.6.18-128.1.1.el5.028stab062.3, archname=i686-linux

uname='linux Serverhost name 2.6.18-128.1.1.el5.028stab062.3 #1 smp sun may 10 18:54:51 msd 2009 i686 i686 i386 gnulinux '

config_args='-ds -e -Dprefix=/usr/local -Doptimize=-Os -Duseshrplib -Dusemymalloc=y'

hint=recommended, useposix=true, d_sigaction=define

usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef

useperlio=define d_sfio=undef uselargefiles=define usesocks=undef

use64bitint=undef use64bitall=undef uselongdouble=undef

usemymalloc=y, bincompat5005=undef

Compiler:

cc='cc', ccflags ='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',

optimize='-Os',

cppflags='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -I/usr/include/gdbm'

ccversion='', gccversion='4.1.2 20080704 (Red Hat 4.1.2-44)', gccosandvers=''

intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234

d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12

ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8

alignbytes=4, prototype=define

Linker and Libraries:

ld='cc', ldflags =' -L/usr/local/lib'

libpth=/usr/local/lib /lib /usr/lib

libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc

perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc

libc=/lib/libc-2.5.so, so=so, useshrplib=true, libperl=libperl.so

gnulibc_version='2.5'

Dynamic Linking:

dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/local/lib/perl5/5.8.8/i686-linux/CORE'

cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'





Characteristics of this binary (from libperl):

Compile-time options: MYMALLOC PERL_MALLOC_WRAP USE_LARGE_FILES

USE_PERLIO

Built under linux

Compiled at Jun 3 2009 02:53:21

@INC:

/usr/local/lib/perl5/5.8.8/i686-linux

/usr/local/lib/perl5/5.8.8

/usr/local/lib/perl5/site_perl/5.8.8/i686-linux

/usr/local/lib/perl5/site_perl/5.8.8

/usr/local/lib/perl5/site_perl

.



querystring: license=YouZamfooLicenseDetail

compare:

capture: read_license,pathtranslated,php_exec_curl,parse xml,parseurl,

capture2: PATH=/usr/local/jdk/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/courier-imap/sbin:/usr/lib/courier-imap/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/X11R6/bin:/root/bin:/opt/bin

DOCUMENT_ROOT=/usr/local/cpanel/base

SERVER_SOFTWARE=cpaneld

CPANEL=active

SERVER_PORT=2086

SERVER_PROTOCOL=HTTP/1.1

GATEWAY_INTERFACE=CGI/1.1

DNS=yourdomain.com

REMOTE_HOST=212.116.219.101

REMOTE_ADDR=212.116.219.101

REMOTE_PORT=38184

SERVER_ADDR=YourServerMainIP

REQUEST_METHOD=GET

CONTENT_LENGTH=

QUERY_STRING=

ACCEPT_ENCODING=gzip,deflate

TRANSFER_ENCODING=

REQUEST_URI=/cgi/zamfoo/zamfoo_b9_toolset.cgi

SCRIPT_URI=/cgi/zamfoo/zamfoo_b9_toolset.cgi

HTTP_X_FORWARDED_FOR=xxxxxxxx

HTTP_USER_AGENT=Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11

HTTP_REFERER=http://xxxxxxxxxxxxx:2086/cgi/zamfoo/zamfoo_landing_root.cgi

CONTENT_TYPE=

HTTP_COOKIE=logintheme=cpanel; whostmgrrelogin=no; whostmgrsession=closed

HTTP_ACCEPT_CHARSET=ISO-8859-1,utf-8;q=0.7,*;q=0.7

HTTP_ACCEPT_ENCODING=gzip,deflate

HTTP_ACCEPT_LANGUAGE=en-us,en;q=0.5

HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

HTTP_HOST=ServerMainIP

SERVER_NAME=ServerMainIP

SUBID=

UPLINK=

REMOTE_USER=root

REMOTE_PASSWORD=xxxxxxxxxxx

SCRIPT_NAME=/cgi/zamfoo/zamfoo_b9_toolset.cgi

SCRIPT_FILENAME=/usr/local/cpanel/whostmgr/docroot/cgi/zamfoo/zamfoo_b9_toolset.cgi

REDIRECT_STATUS=1



I have change and bold the my server detail.

How can you test in your server?

I don't know its work for you or not but try it.
Create a cPanel account with domain zamfoo.com
then create a email Id in this account via cPanel support@zamfoo.com

now run upgrade via Zamfoo >> B9 Tool Set - BETA >> check Update ZamFoo
and click do it

After that check email of support@zamfoo.com
You will see the email above.

Method 2:
Block all out going email then check Mail Queue Manager under root WHM after upgrade Zamfoo you will see this email.


----

This certainly does seem worrying for a piece of hosting software, it has been confirmed by the producer of the script later on in the thread and they're working on a patch . . . they said it was put in by accident.

I don't use the software personally, never will touch anything to do with master reseller. I thought I'd post a thread here since there isn't one currently.

Wow. And I thought only rootkits did that. As a side note, they don't even have a website up now, heh.

Their website tries to download something to my hard drive.

hi,

the website was down while php was being recompiled. the site is backup. i will answer any and all questions pertaining to this. and regularly update both DP and here pertaining to this. i was just notified of this thread. the thread on DP contains at this point a better and full explanation as to how this occurred and what is being done about it.

thanks,
kevin

hi,

there is now a patch available through the update function. an email to all clients has been queue for seding. please run the update function. verifty that the version has changed to version 3.4

after sucessfull update then immediately change your password. we encourage you to retest and ensure that this gap is fully closed.

thanks,
kevin

to all WHT people: please also read the DP posts as it may contain information not posted here.


hi,

i feel and hope that this matter is now closed. i am providing for public record the email that has been sent to every client regarding this matter

email
------

hi,

we regret to inform everyone that a mistake was made when releasing version 3.3

we did not remove a piece of debugging code from our script. the debugging code, unbeknownst to us was mailing us root credentials in plain text. this has been pointed out on some forums this morning.

we are terribly sorry that this has occurred. earlier today we release an initial patch. we now have a full patch available which can be run through the easy updater.

we understand the full severity of this mishap and hope that you continue to trust our software, support and intention of not causing harm to your business, your systems or anyone elses systems through your servers.

full explanations, ways to replicate the problem and see it first hand, an explanation on how and why this piece of code was in the software can be found on the forums.digitalpoint.com and webhostingtalk.com websites as well as the method to verify in the future that this doesn't occur.


please do the following IMMEDIATELY:
--------------------------------------------

run the update script from b9 toolset
then verify that you are running version 3.4 from the footer of the root reseller screen
then change your root password


we will not confirm on an individual server, client or license basis that the problem has been corrected but will ask the clients and people who have reported the problem to publicly that the problem has been corrected.


we value your business greatly and cherrish our good standing reputation. we can only hope that this blemish doesn't permanantly impact the view of how good or how secure the software is.


sincerest apollogies,
kevin

Hi
Both whmreseller and zamfoo were caught for sending our root password because both are running inside the server as executable files.

Another one is WHMPHP (http://whmphp.com)which is I believe, the safest one in the market regarding the server security. Since it is of PHP and communicating directly with the cPanel ( direct quote from the author ) it can not send out root passwords from the server.

CGI programs can collect environment variables and thus send our root passwords. Such a backdoor is zamfoo. Thumbs down

hi,

as i stated. it was an accidental oversite in version 3.3 release. a patch was issued within 1 hour.

php and mysql are much more vulnerable to cross site scripting and remote file injection. these are big issues. if you use whmphp for multiple servers then you are vulnerable to not just one machine...but all of them.

im not putting down whmphp but there are draw backs to their software as well. additionally php can similiarly grab environment variables.

kevin

hi,

as i stated. it was an accidental oversite in version 3.3 release. a patch was issued within 1 hour.

php and mysql are much more vulnerable to cross site scripting and remote file injection. these are big issues. if you use whmphp for multiple servers then you are vulnerable to not just one machine...but all of them.

im not putting down whmphp but there are draw backs to their software as well. additionally php can similiarly grab environment variables.

kevin


Hm.. I believe you are not aware of php.
PHP can not collect dangerous information such as server root password, like what you did with your script.

file and sql injection , a good php developer can overcome it and I haven't heard any single bad comment about whmphp. My friend is using it on his server and we both have nothing to say other than its just great.

I have checked your script as well, well, it really ***ks! IMO. Plus today I heard the news as well, that it collects server root password same as whmreseller as proved by coolstfuff on DP

hi,

it does not collect root passwords. you can verify this. additionally php has the availability to contain cgi code and use cgi libraries so the claim that this is not possible is entirely.....unintelligent.

kevin

hi,

it does not collect root passwords. you can verify this. additionally php has the availability to contain cgi code and use cgi libraries so the claim that this is not possible is entirely.....unintelligent.

kevin

Can you elaborate these sentence ?
It does not collect ? which one ? zamfoo ? well , it was already proved that zamfoo collects root pass and send it to support@zamfoo.com for you

hi,

zamfoo does not collect root passwords, v3.3 was the only piece that had the debugging code in it. it was removed within the hour. you can verify it does not do what you are claiming to be the case. download the latest version, install it and do what they are telling you to do. you will see no passwords are sent.

kevin

hi,

zamfoo does not collect root passwords, v3.3 was the only piece that had the debugging code in it. it was removed within the hour. you can verify it does not do what you are claiming to be the case. download the latest version, install it and do what they are telling you to do. you will see no passwords are sent.

kevin

Since the codes are encrypted, there is no way to verify it.

Well, you seems like a little kid who is playing with me by arguing

Since the codes are encrypted, there is no way to verify it.

Well, you seems like a little kid who is playing with me by arguing

im not arguing with you. you clearly do not know what you are talking about. im attempting to clarify your misconception.

yes it can be verified. without giving my source code away.
there are posts on how to verify the software is not sending root passwords.

did you read this full thread which i clearly point to and say how to verify that the debugging code has been removed or just post blindly to it about whmphp as a plug for the whmphp script?

I think he is not plugging whmphp. he was stating the fact that your script is collecting passwords. by stating that, its unavoidable to compare you to other master script providers. dont get too defensive just because someone pointed out a fact. you may have already patched it but you cant deny that you have already collected root password before you were able to patch it. That means all your clients had to change root password just to ensure that zamfoo will not be a like rootkits

After hearing this, I don't think I'll be installing master reseller software at all. I think all software that does master resellers equal crap right now anyways. None of the interface's look good and your software is encrypted with ioncube which is a lot harder to crack than zend obviously to see what is really going on. Could you link to the posts where you can verify the software that the software isn't sending root passwords to you? I can't find any at all.

. . . they said it was put in by accident.


That's a pretty big 'accident'.

That's a pretty big 'accident'.According to hosty on the DP thread, the debugging code simply echoed all environment variables into an email and the 'accident' was to leave that debugging code in a production release. A mistake certainly but IMO not that big a mistake - the very big and nasty consequences are more a result of storing the root password as an environment variable in the first place.

Is that (as claimed) something that cPanel itself did / does? I wouldn't be surprised - I remember it putting plain-text passwords into the "download backup" links.

According to hosty on the DP thread, the debugging code simply echoed all environment variables into an email and the 'accident' was to leave that debugging code in a production release. A mistake certainly but IMO not that big a mistake - the very big and nasty consequences are more a result of storing the root password as an environment variable in the first place.

Is that (as claimed) something that cPanel itself did / does? I wouldn't be surprised - I remember it putting plain-text passwords into the "download backup" links.

After looking at the #1 post, to be clear what was transmitted was the CGI variable as shown below:

REMOTE_PASSWORD=xxxxxxxxxxx

It didn't get it as a result of digging around the machine, it got it as a result of the login process. So, it is not actually 'stored', it is an artifact of a point in time. The point in time being the generation of the page in question.

It is worth noting that it may be comforting to know that support people are often privy to passwords when they are given access by clients. What is important to each individual is their perception, before this incident, of the trustworthiness of the vendor. If they would have handed it over anyways, then handing it over by accident might not be such a tragedy. If you trust the guy, then change your password and move on. If you don't ...

Oh thank God, I was thinking to install zamfoo but I don't think after reading this post will go for zamfoo.

Oh thank God, I was thinking to install zamfoo but I don't think after reading this post will go for zamfoo.

Why not avoid Master Reseller/ Alpha Reseller/ Supper Duper Alpha Reseller software in the first place? It's all garbage.

The mistake of transmitting root passwords because "debugging" code was left in the software is inexcusable and unacceptable. If I am reading this correctly, I've never tried the software, but it is encrypted, correct? What is to say you didn't slip it in a past version and then remove it on the next version in the hopes that no one would decode that version and see the mistake. If I am missing something here, feel free to point it out to me.

EDIT: Also, bashing on writing master reseller in PHP, LOL. You're the one sending passwords in clear text, not the master reseller software written in PHP LOL!

Coding secure PHP is actually relatively simple, never trust user input.

A few steps to take:

mysql_real_escape_string()
using post instead of get on forms (implies)
stronger session validation.

Coding secure PHP is actually relatively simple, never trust user input.

A few steps to take:

mysql_real_escape_string()
using post instead of get on forms (implies)
stronger session validation.

Actually, its simpler than that. Never trust PHP.

But seriously, GET vs POST makes absolutely no difference, other than for the fact that a well behaved browser will not cache a page resulting from a POST. The dilettantes will want to talk about what is idempotent or not. But, if you look at the data going across the wire it makes *no* difference.

Actually, its simpler than that. Never trust PHP.

But seriously, GET vs POST makes absolutely no difference, other than for the fact that a well behaved browser will not cache a page resulting from a POST. The dilettantes will want to talk about what is idempotent or not. But, if you look at the data going across the wire it makes *no* difference.

Get an post methods are not same and has difference. A serious and experienced developer can understand this very easy and will patch the holes.

PHP is one of the best programming language out here, used by thousands of sites and programs. Example, this forum , VBulletine .

So I will say, php is not vulnerable. The php programs and its security depends on the experience of the developer.

Sorry for the late post. The software was fixed a bit back. I do not see anything in the code that indicates this. I plan on using this software from now on as my only master reseller software. :D

According to hosty on the DP thread, the debugging code simply echoed all environment variables into an email and the 'accident' was to leave that debugging code in a production release. A mistake certainly but IMO not that big a mistake - the very big and nasty consequences are more a result of storing the root password as an environment variable in the first place.

Is that (as claimed) something that cPanel itself did / does? I wouldn't be surprised - I remember it putting plain-text passwords into the "download backup" links.

Are we talking about the root password from /etc/shadow? Because if that is decrypted and stored in an environmental variable, that's one f**ked up system and should win some type of an award. Who does that? The only thing worse is having the /etc/passwd file 777 with the root password inside (unhashed).

no matter how something gets explained...someone always doesn't get it. how do you get /etc/shadow from environment variable? i fail to see the logic that has transformed one concept into the other.

you type your password in the password box. it gets stored as an environment varaible. stored in plain text. $ENV['remote_password']

kevin

Stored by your plugin or Cpanel/WHM?

....cpanel.....obviously.

....cpanel.....obviously.

Then what's the fuss all about? ... A broken system is broken.

This script then just echos the env variables. Which is perfectly legit.

tell that to cpanel

It's a feature, not a bug!

After hearing this, I don't think I'll be installing master reseller software at all. I think all software that does master resellers equal crap right now anyways. None of the interface's look good and your software is encrypted with ioncube which is a lot harder to crack than zend obviously to see what is really going on. Could you link to the posts where you can verify the software that the software isn't sending root passwords to you? I can't find any at all.

Sorry for the late post. The software was fixed a bit back. I do not see anything in the code that indicates this. I plan on using this software from now on as my only master reseller software. :D

Lol that made me laugh :D

hi,

its not a feature or a bug. it is a security risk. a pretty large one appearantly.

kevin