Bero.dev

Blog

  • Webshops are about people and products, not user flows

    I’ve spent a long time building webshops, and for years I thought it was all about features and removing friction to improve conversion funnels.

    I thought that if a shop didn’t do well, we could always get it back on track by researching, improving, and measuring. The process is repeated forever, and the business grows.

    One day I went to check the time my local coffee shop opens and learned they have a webshop. I went to order coffee immediately and was unpleasantly surprised that the Add to Cart button is just a mailto link.

    Not even a form with prefilled data about the product I clicked, just a link!

    They wanted me to write an email, wait for them to send me an invoice, and ship the coffee after I paid.

    The amount of friction and unnecessary steps seemed insane.

    But I was lazy to walk, so I went through the “Checkout”. We exchanged a few emails, I paid, they confirmed, and shipped.

    The next morning around 8 am there was a delivery on my door, freshly roasted coffee.

    I still do it every month, except that now, I go back to the email thread, just say The same please, and they reply, We shipped it. Here is the invoice, pay when you get a chance.

    That’s a frictionless experience! It’s the best webshop I’ve ever used.

  • Someone finished installing WordPress for me

    When I first started building this site, I took it slow and did a bit every day. One day I would update DNS records, the next day I would set up Nginx, and so on.

    When it was time to install WordPress I uploaded the files and stopped for the day, leaving an unfinished WordPress installation publicly available for anyone to finish. At the time I thought that it would be funny to come back and see the site was installed.

    I didn’t care about the server and could rebuild it at any time, so I left it unfinished.

    The next day guess what happened. My site installation was finished. When I saw it I was excited.

    I’m a huge Darknet Diaries fan but don’t have a lot of security experience, so this was a perfect opportunity for me to practice what I’ve learned.

    Cleaning up

    First I turned off the server to get some time to think. I considered leaving it running to see what the hacker would do next but decided to don’t do it because I had very limited time to play with it. Plus, I now know how to get hacked, so I can easily recreate it in the future.

    The next day I made a clone of the server and restored my server from a backup.

    After that, I changed a couple of passwords and SSH keys the server had. With that done, I was back up and running and ensured nobody could come back. I don’t think that they could come back, but this was an exercise for me and I wanted to do everything the right way.

    Analysis

    Now it was time to see what happened. I turned on the cloned machine and connected to it.

    Remote database

    First I took a look at the WordPress installation because I assume that there are database credentials in wp-config.php and I was right.

    I was also able to find the exact time when the installation happened by checking when wp-config.php was created.

    Of course, I had to connect to the remote database to see what I could find there.

    The database contained a couple of WordPress installations and they all looked standard as if someone just went through the installation process.

    There was an admin email in the options table. It looks like a throwaway Gmail account, but the format is FirstnameLastnameNumbers.

    In the end, I removed my database tables from the remote database.

    WordPress installation

    To my surprise, there weren’t any plugins or themes installed, and the files weren’t changed by the hacker. There wasn’t much I could find there.

    Server

    I assumed that the hacker didn’t get server access, but to be sure I went to check what files were changed and I couldn’t find anything unusual.

    Also, there were no new users added.

    Next, I went through the logs to see if I could find where the attack came from.

    I quickly checked Nginx and PHP logs, but there wasn’t anything useful there.

    This is when I decided to stop and actually launch the blog.

    Next steps

    Because I have the domain names of other hacked sites, I will try to get in touch with site owners and let them know what happened.

    Things I learned

    It can be fun to get hacked as long as you don’t have anything to lose.

    From now on I will always put my unfinished sites behind basic auth.

    I should disable remote database connections because they aren’t necessary and would have prevented this from happening.