Voice of the DBA

Tag: security

  • Building CyberSecurity Skills with an Advent Challenge

    I’ve been working on the Advent of Cyber challenge this December. It’s more of a walkthrough of some puzzles than it is solving them yourself, but it has given me a brush up on some skills and helped me learn some basics of how people in charge of (or looking to break) security look at the world. Plus it’s been a little fun with a silly storyline each day.

    The first challenge starts with a chatbot and trying to social engineer answers out of it. This was interesting to me, even though it was likely (hopefully) not a representative example of how AIs would work in most systems. However, it got me to think more about how I pose questions to an AI and how I can grow my prompts. The neat thing about AI is that you don’t have to ask the perfect question and then re-ask the same question with more info to get an answer. The AI keeps context in a conversation, which is way more powerful than previous Q&A search systems.

    The second day was Python and Jupyter Notebook basics, which were a nice refresher for me on a couple of concepts, but not that interesting. However, the third day introduced some password-cracking tools, the fourth day added other ones, and a few subsequent days showed some software that is devious in how it can be used to penetrate security. Other challenges have me the chance to brush up on Linux and network skills I hadn’t used in a long time.

    The SQL Injection module (day 10) is well done, and I might recommend most developers go through that to see why their easy, convenient build-a-sql-string-to-execute code is an incredibly bad idea. It’s also why they can’t also use stored procedures as built-up batch commands. Use the stored procedure objects to execute with named parameters.

    The idea of using a little plot and story, with a simple challenge to teach some skills is a good one. I’ve been lucky in my career to be exposed to a lot of different technologies and ways of working with systems. I’ve set up bridges, routers, and firewalls. I’ve had to get network links and cables to work and talk with different protocols, including configuring T1 connections. I’ve built machines, dealt with different types of local and remote storage, and had to program and administer systems at all levels of the OSI model. Does anyone remember that?

    This was a fun break from work, doing a module or two every other day, remembering there are a lot of complexities to our systems outside the database, or outside the application software. It’s also reminded me of all the different ways that security can be breached.

    Take the challenge and learn some new skills. I think many of you will learn something and you might enjoy yourself along the journey.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • Breaking Biometrics

    In the movies, when someone needs to bypass some sort of fingerprint biometric system, they use tape to lift a fingerprint, or in the more gory films, cut off a body part. In any case, there have been a lot of attempts to replicate this in the real world. Sometimes these work, though the consensus is modern hardware isn’t as susceptible as older hardware. I don’t know if that’s true, but I did see an interesting look at the main three sensors used in most laptops.

    All the laptops had their authentication bypassed, though not with any fake biometric device, but rather with attacking the actual communications between the sensor and the OS. There’s a great report from two people who were asked by Microsoft to evaluate the security of the top three sensors. It’s a fascinating look at how the hardware and software of the OS are set up to provide secure authentication and how both can be fooled.

    Some of the problems are users not enabling features and some are that manufacturers aren’t understanding or implementing the secure protocols from Microsoft. I both get how this happens and I feel it’s not acceptable. Certainly someone might read a spec and not completely understand it, even across a team of people. However, for vendors, this can’t be something they don’t have researchers, pen testers, or some security professional examine. Hardware vendors spending money designing these devices ought to include the money for a few people to try and break the security before they are sold.

    At least for security features.

    I like the enhancements made with multi-factor authentication, and I appreciate biometrics as a convenient way to access things. At the same time, I want to be able to trust them. The efforts made by the researchers are pretty high, not something that someone in a coffee shop can do in 5 minutes while you go to the bathroom. At least, apart from the Surface. It appears that one can be quick.

    At the same time, if you lose your laptop, within hours someone can break past the biometrics with a man-in-the-middle attack. Even if you’ve encrypted the disk, your data can be accessed since this attack gets the OS to authenticate them.

    Security is tricky, but I don’t plan on disabling my fingerprint scanner. However, if I were carrying around data that was more important than the work I do now or data worth a lot of money, I don’t know I’d ever enable biometrics.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • TryHackMe Advent of Cyber

    I posted that I was thinking about the AdventOfCode this year, but wasn’t sure I’d spend the time. Someone then posted a link to the TryHackMe advent calendar.

    I decided to give it a try.

    There’s a fairly long (10min) video intro and then you sign up.

    Day 1

    One of the good things was that the video has some spoilers to help you solve the challenge. If you skipped the video, watch it now. Or try.

    There are three questions we need answered, and we then have to fool the AI/ML chatbot. The video shows how, but essentially you need an email address, a server room password and a project name.

    The interesting thing is this shows how a poorly secured and trained chatbot might disclose this information. For the email address, you just ask. For the password, you need to find an employee’s name and then tell the chatbot you’re that person and need the password. It seems silly, but I bet this works on some chatbots people have created with wizards or templates and not secured or limited the training data.

    The last one is interesting, you ask the machine to go into maintenance mode and you get the name of a project. Getting into the maintenance side of applications or mainframes used to be a way to attack them. Unfortunately, too many people didn’t secure many early systems and this was too easy.

    Day 2

    Day 2 is about using Jupyter notebooks. A good portion of the tutorial is helping you understand how notebooks work. Hopefully you’ve read my article on notebooks. If not, this helps you figure out how to use them. It also has a short tutorial on some python that you use to perform data analysis on a csv. While many of us might like to do this in SQL, the experience in python isn’t bad.

    This ends up helping you understand how to count, summarize, and group data in python.

    Day 3

    This day was interesting. Now we are learning about some security tools. In this case, we learn about hydra, which is a tool to brute force logins against a web page. This is a fantastic tutorial that should teach you that unlimited retries on a page without some timer is a bad idea. This should also help you understand that you need to track failed logins and do something about them, especially from weird IPs.

    Day 4

    Continuing on, we learn how to use cewl to create customized wordlists and then use those to brute force in a smarter way.

    Again, scary for a non-security person. These tools are likely good for security folks, but terrifying in that perhaps criminals use them every day.

    Summary

    The first few days of the challenge were interesting and it was neat to spend some time thinking about the world from a cybersecurity point of view.

  • Ten Database Commandments

    I love the Notorious B.I.G. His music isn’t for everyone, but I enjoy it. This piece takes one of his songs (NSFW – Ten Crack Commandments) and applies the list to databases. Each item from the song is listed, along with the way it might be changed for database work. The list is from Ottertune, which is a service designed to help you optimize your use of AWS RDS and Aurora databases, with AI. If you believe their hype, their service will get better performance and lower costs for you.

    In any case, with regard to databases, I suspect that the author is having some fun with the rules, and a few of them made me smile. They are cloud-related, but a few will apply to any environment.

    The first one is about budgets, noting you should not disclose your budget, which is in general a good rule whenever you are buying something. Don’t disclose information, and someone working for a vendor of tools, I think that most budget conversations aren’t something technical people should worry about. Decide what value you get from some tool/service/process/etc. and if there are time savings. Then let someone else decide if the ROI is worth the cost.

    Rule 2 is a stretch, but I do think that looking at new tools can be helpful. The caveat here is that many people, don’t often learn enough about existing tools to understand if they will solve issues. There are a lot of things you can do with many tools, so don’t just look for some magical new tool. Learn to use your tools well, and if you want to try a new one, keep in mind you will need to invest some time both learning about it and practicing some skills before you really know if it’s helpful. The other thing to remember is every new tool increases the bar for new staff. Try to limit the number of tools you use to those you need.

    Security is important and rule 3 is remembering not to give out more permissions than needed, especially to developers. I love this quote: “You don’t want randos at your organization logging in and running queries that they found on Stack Overflow.”

    A number of the other rules have to do with performance, which is certainly Ottertune’s business, but these are good basic practices that I see organizations not following. Too often management wants to save money and technical people make decisions that compromise performance. Lots of people overload systems, and then they can’t handle the workload well. I get that many CFOs and others want to see high CPU usage, which means they’re using the resources they pay for, but databases can be very bursty with resource usage. At the same time, you don’t want to over-provision resources because you are scared. Learn to find a balance that doesn’t waste money, but handles your workload well.

    Perhaps one of the best things about the cloud is that if we do make bad decisions, we can often provision more resources. It can take time to move to a new tier of service, so don’t expect instance response up or down, but if you need to double the CPUs for month-end processing, you can likely plan for the time to scale up your database instance and then scale down again when all the work is complete.

    It’s a fun article, and if you’re looking for some fun Notorious B.I.G.-related database content, grab a cup of coffee when you need a break and a smile.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.