Author Archives: mcontino

The Future of the CAPTCHA: Interactive Advertising

Posted on by

I’ve recently done quite a bit of research around using CAPTCHA’s to protect against automated form submissions on web pages. Unfortunately CAPTCHA’s are a thing of the past and it’s my belief that interactive advertising is next big alternative.

CAPTCHA’s have been common place on logon and registration forms for almost a decade now. However recent research conducted by industry leaders has shown that CAPTCHA’s are no longer very effective. In fact, there are several company’s that now offer CAPTCHA solving as a service, where humans will solve them for pennies. In fact just this year Google’s Recaptcha service moved from a user input driven model to a completely data analytic model for verification. This change was largely because of one of Google’s own research fellows released a paper describing how to programmatically beat the recaptcha over 70% of the time.

So what’s next? It’s my belief that one of the new interactive advertising firm on the internet will likely soon pull through as a leader in automated form submission protection. This may sound like an unusual combination, but it really does make since. With the payouts for conventional advertising online dropping rapidly, due to increased add relestate, site owners are looking for more ways to supplement hosting costs. Advertisers are also looking for new ways to engage their audience and new social science research shows that getting people to interact with your brand makes them more likely to buy.

I guess the the other question is will interactive advertising really protect against programmatic form submissions and increase the overall security of said website? I believe if site owns force users to participate in the add and only process form submissions once they have validated with the adds API. It should still stop rapid form submissions from being processed and make it significantly harder for attackers to find injection vulnerabilities.

The only question that remains to be answered is will these interactive advertising provide enough entropy and data analytics to ensure that they can’t easily be solved or bypassed.

Free JetCash: How We Got JetCash from the New jet.com

Posted on by

The following is a description of how Tyler Schmidtke and I obtained free JetCash shortly after the launch of the site. This research was conducted on July 25, 2015. We worked with Jet to ensure that the finding described in this post was remedied prior to this blog post being published.

Jet.com is a recently launched eCommerce site hoping to reinvent online shopping. There has been quite a lot of hype around it, so Tyler and I decided to check it out. In browsing the site and watching some of the videos that had been posted, we learned of JetCash, free credits for jet.com that could be earned by shopping at third party retailers. Jet refers to this as Shop Anywhere. In investigating these credits further, we learned that verification for external purchases relied on submission of order confirmation, from the third party, via email. Jet launched with a large list of external vendors, including Nike.com. What was enticing about Nike.com was that 30 percent of the total purchase price at Nike.com, could be directly converted to JetCash.

Upon seeing the conversion rate and looking at the validation method for external purchases, we decided to create an account to test this third party order validation method. Jet.com utilizes a subscription model; however, considering its recent launch, I was able to find a promo code to get 6 months of access for free. Once the account had been created, I proceeded to make a purchase on Nike.com. I didn’t want to invest too much in testing Jet’s external purchase validation, so Tyler and I decided that we would purchase the cheapest thing available (Nike sweat bands).

Nike Purchase, Nike Order, Nike Purchase Order, Free JetCash

The Nike Purchase Order.

Once the order had been placed, we waited to receive the confirmation email. We suspected that this email would be HTML, meaning that it could be easily modified prior to sending to Jet for verification. Shortly after placing the order for 1 Nike sweat band, I received an order confirmation in my inbox. The confirmation email was fairly simple, containing an order number, shipping information, and order details. Considering the validation process relied on this confirmation email, we thought that we would modify the email prior to forwarding it on to the confirmation email at Jet (anywhere@jet.com).

Nike Email, Confirmation Email, Nike Confirmation Email, Free JetCash

Purchase Confirmation email from Nike.

We then just simply edited the html and plain text portions of the email to reflect a quantity of 20 sweat bands instead of 1, and updated the prices accordingly. The email that we forwarded then looked like this:

Spoofed Email, Fake Email, Altered Email, HTML Edits, Free JetCash

The Spoofed Email We sent to Jet Anywhere.

Our purpose for modifying the email was to identify a potential vulnerability in this functionality of Jet.com, so we only modified the email to potentially obtain a slight amount of JetCash. We increased the quantity of the sweat bangs in the confirmation email to 20 and appropriately updated the tax and total. This brought the total of our fabricated order to $114.75, enough to earn us approximately $30 in JetCash.

We sent the modified confirmation email and hoped for the best. After waiting a short while, we received the following email confirming that we had earned $30 in JetCash.

JetCash, JetCash Email, JetCash Award, Free JetCash

Email showing JetCash Award.

It should be noted that we had no intention of using any of this free JetCash. This test was simply conducted for research, to potentially identify a vulnerability in this feature of Jet.com. We notified Jet of our findings and ultimately received the following response.

”
– Jet does not consider this a security issue as there was no bug present. The steps you describe highlight a temporary process that would allow people to commit fraud and potentially not be caught.
– In order to not delay the launch of Jet Anywhere, the program was launched with a manual verification step for the first two weeks until a more automated link tracking mechanism was in place. Some merchants had automatic link tracking in place while others were manual.
– Jet was founded on core values of trust, transparency and fairness. Jet trusted the “good” in our members to only forward us legitimate receipts and reward them with instant JetCash, and not intentionally committing fraud by altering an actual order.
– The process is now fully-implemented with click-tracking, merchant verification, and pending jet cash in case someone later cancels their purchase.
”

As stated in Jet’s response, this issue has been resolved. While this was not necessarily a vulnerability related to the technical aspects of Jet.com, Tyler and I still feel that this finding was a signficant flaw that existed on Jet.com during its initial launch period. During the reporting process, Jet was incredibly responsive, keeping in touch with Tyler and I until the issue had been resolved.

During this process, we also learned that Jet’s official bug bounty program is run through Bug Crowd. If you’re interested in helping Jet out by hunting for bugs, you can learn more about the program here: https://bugcrowd.com/jet

So You Got a Shell: SSH for Linux Post Exploitation

Posted on by

So you worked hard to find that cool web application exploit and got a shell on the box. Many people not so familiar with the Linux operating system, quickly find themselves throwing there hand in the air and saying; Now what do I do? By popular demand, this is a list of some of my favorite SSH for Linux Post Exploitation techniques that I’ve used over and over in past Cyber Defense competitions and my career.

Note: I’m assuming that you will likely exploit a service level account, such as ftpd, www-data, ldapadmin, squid, apache or syslog, and not immediately have root level access on the system.

One of my overall favorites is utilizing SSH for linux post exploitation,  as a mean of developing access to systems on the internal network and to maintain access. Almost all Linux distro’s come with openssh-client baked in and many also have openssh-server set to run at startup by default. Fortunately, openssh’s config files ship with fairly basic security measures in place and expect system administrators to utilize the many additional security features, that are available, to defend systems. Most simply don’t bother.  Additionally the permissions on the /etc/ssh/ssh_conf and /etc/ssh/sshd_conf files are world readable by default. So start by just checking them out.

User$ cat /etc/ssh/ssh.conf

User$ cat /etc/ssh/sshd.conf

Within /etc/ssh/sshd_conf the default configuration allows for public file authentication; with the following line.

PubkeyAuthentication yes

This line allows for a public key to be passed to the system in order to authenticate as a specified user. This is done by adding your public key to the .ssh/authorized_keys file; under the users home directory structure. Once added you can use the simply ssh to the system, using your private key, while specifying the username.

Note: Most default system service accounts ship with /bin/false or /sbin/nologin as their default, which means ssh wont allow you to login directly via ssh.

So you are looking issued the command cat /etc/passwd and she that your user has no login shell and you say Michael this whole maintaining access with public keys in the authorized_keys file is useless to me. So how about another user of SSH for linux post exploitation; using your user to port forward into the local network over ssh?

So you get a web shell using some fancy new wordpress vulnerability and then you cat out the wp-config.php file and see that the database isn’t hosted on the local system. Now you have to pop another box to access that database right? Wrong. You can create a local port forward the the mysql port with ssh. by using the following command.

ssh -R 9000:<mysql server ip>:3306 www-data@localhost

So now maybe people are thinking of great I have to have a shell again…but www-data has /sbin/nologin! Thats fine we dont need a shell. Just follow the steps above. Use your web shell from the wordpress vulnerability to use ssh-keygen to generate the www-data users keys and .ssh directly. Then simply cat your public key into the .ssh/authorized_keys file, to give you a means of local authentication. You may not be able to get a local shell, but you can still ssh port forward by telling ssh not to use interactive login or allocate a tty with the following command.

ssh -v -nNT -R 9000:<mysql server ip>:3306 www-data@localhost

This will create an ssh tunnel that will port forward all traffic from 9000 to the mysql server on its default port. So simply issue the mysql command to connect on port 9000 and use the credentials in the wp-config.php file.

mysql -u wordpress -p -h <web server ip> -p 9000

Profit!

If you have any questions or want to know more just leave a comment or hit me up on social media.