DEV Community: Theodoros Danos

Common Developer Pitfalls: A Guide to Bolstering Security

Theodoros Danos — Wed, 09 Aug 2023 18:51:10 +0000

“Breaking their Defense” Series

In this series dive into the thrilling depths of my role as a penetration tester. Experience the adrenaline-pumping reality of simulating an attacker in real-life engagements, seen through my lens. Discover how I infiltrate what my clients proudly dub their 'digital fortress,' daringly challenging their perception of invincibility. My mission? To uncover not just that I can penetrate their defenses, but to identify and expose every chink in their armor that puts their most valuable asset at risk - information.

Previous Article: “Breaking their Defense - Hacking Stories”

Common Security Bugs

Let's dive into the common missteps developers often make - the pitfalls we frequently uncover during our penetration tests. By reading this insightful article filled with mini-stories about various bugs, you'll be able to zero-out the most common errors and bolster your security measures.

One to rule them all - Improper Access Controls

In our tests, the bug we run into the most is a missing 'Access Control' mechanisms. We often see that web or mobile apps skip crucial checks, letting users (those who aren't supposed to) see information they're not meant to. This usually happens as the folks building the back end of the app believe that if a user can't reach certain information through the normal user screen, they can't get to it at all. At other times, it's simply an oversight.

IDOR

The most common type of access control bug is what is called an IDOR (Insecure Direct Object Reference). What’s that? This is a particular type of bug were the request is based on an ID (the reference). Such ID represents the information to be fetched (the document, the database record, etc). Often, such IDs are predictable. For example, my documents shown through the User-Interface are “invoice-01.doc” and “invoice-02.doc”. Such documents to be retrieved can be fetched through the endpoint /documents/. The UI retrieves the previously mentioned documents by calling /documents/4145 and /documents/4159 respectively. However, based on the incremental nature of the ID, one could brute-force the range of documents (i.e from 0 to 10000) and retrieve all documents of all users. A proper access control shouldn’t allow that. Don’t be fooled by the assumption that the type of interface you are using is safer as that doesn’t make a difference - GraphQL, RESTful or any other kind of interface.

Modern apps often use UUIDs, which are unique 128-bit IDs, rather than simple IDs. For instance, a UUID might look like this: '47b3c2cc-3f5c-46d5-a84a-22ae5d3031a4'. It's pretty tough to guess these UUIDs and randomly find a document. But, if someone happens to see the UUID (maybe they peek over your shoulder), they could use it to pull up the document in their own session. So, even though it might seem safer than using simple IDs, it can still be a security issue.

Unusual Ones

Some access controls can be quite unusual. Let me tell you a story. Once, I was working with an app that redirected you to the regular user interface if you tried to go to the admin area. It looked like a good security measure. But was it really?

What they did was load all the necessary JavaScript libraries for the admin UI without a problem. But before the page started loading any data, it would check with the server if the user was an admin. If yes, it would proceed to load the admin data onto the UI. If no, it would redirect the user back to their regular dashboard.

But there was a way around this. If we “skipped” the admin check and triggered the next steps manually, we could use the full admin UI! How did we do it? We cheated. We didn’t even had to skip it. We just changed the response from the server that the JavaScript saw. We made it look like the server said we were admins. After all, we control what happens on our side of the screen. That's the nature of client-side code. The issue wasn't with the front-end, it was with the back-end. They relied too heavily on the front-end to handle access control. Remember, access control should ALWAYS be implemented at the back-end.

Escalation of Privileges

Access control issues can sometimes lead to a problem known as privilege escalation. This is when a user gains more access rights or powers within a system than they should have. Although it's a big enough issue to talk about on its own, it often comes about because of other missing access controls. So, we're discussing it in this context.

Let's look at an example using the FastAPI Web Framework. This is a piece of software that changes a user's role within a system:

@app.post('/change_role')
async def change_role(role: UserRole, current_user: User = Depends(get_current_user)):

    user = User.query.get(role.user_id)
    if not user:
        raise HTTPException(status_code=400, detail='User does not exist')

    if role.new_role not in ['admin', 'user', 'guest']:
        raise HTTPException(status_code=400, detail='Invalid role')

    user.role = role.new_role
    db.session.commit()

    return {'message': 'Role changed successfully'}

Even if you don't know much about coding, you can see there's a problem. The software doesn't check if a request is coming from a normal user or an admin user. This means a normal user could potentially change their own role and make themselves an admin. Once they've done that, they could go to the admin panel (because the system now thinks they're a real admin), and do anything an admin can do. You have no idea how often we find these kind of vulnerabilities - more often than you may think.

This simple code could have prevent the worst and fix the vulnerable code mentioned before:

if current_user.role != 'admin':
        raise HTTPException(status_code=400, detail='Only admins can change roles')

Now, how can you tackle such problems? Usually, when handling data, you pull it from a database by making requests. You could create a separate request to confirm that the user has the right permissions. Or, you could include proper checks in a single request to ensure the retrieved data is appropriate for the user.

Take this as an example:

Missing an access control mechanism:

app.get('/user/:id', async (req, res) => {
    const user = await User.findById(req.params.id);
    res.json(user);
});

An access control mechanism is in-place:

app.get('/user/:id', async (req, res) => {
[...]
        if(user.role === 'admin' || user.id === req.thisUser.id) {
            const userData = await User.findById(req.params.id); 
            res.json(userData); // Return user data
        } else {
            return res.sendStatus(403);
        }
[...]

Injections

Injections are the second type of common misconfiguration. Injections is a generic category, an umbrella of specific injection vulnerabilities, which among others are “SQL and NoSQL Injection”, “XSS Injection”, “Command Injection”, “Code Injection” and more. The most common injections are the SQL and NoSQL Injections as well as XSS Injections.

Cross-Site Scripting

XSS vulnerabilities are also among the common ones. Such vulnerability deserves a category on its own but I have placed the vulnerability class under “injections” as the most usual XSS Vulnerabilities were raised through data injected by the attacker.

XSS vulnerabilities, meaning Cross-Site Scripting, is when an attacker injects a piece of client-side code which will be somehow called on the other user’s browser. Then, the code can steal the cookies that sets the session or even execute actions on behalf of the user by making requests to the server through the victim’s browser. This type of attack mostly happens on web applications where the browser is involved.

Here is an example of a vulnerable PHP Code snippet that lists the user’s usernames:

<?php
[...]
$result = $db->query("SELECT * FROM users");

echo "<ul>";
while ($row = $result->fetch_assoc()) {
    echo "<li>" . $row['username'] . "</li>";
}

echo "</ul>";
[...]
?>

Then the attacker could change their own username and place the following payload instead:

<script>users.deleteUser(30)</script>John

If the listing shown in administrator’s page, it will delete the user having ID 30. If listed on a normal user’s screen nothing will happen. In either case, the username list will include the username too, hiding the malicious code that has been executed.

SQL and NoSQL Injections

SQL and NoSQL Injections happen when an attacker manages to mix their own input with a database query. This usually happens when the system takes user data, doesn't properly sanitize it, and then includes it in a database request. The user could potentially alter the database query in ways that weren't planned by the application developers. So, it's very important to always clean the data first.

Many people these days use Object-Relational Mapping (ORM), which is a safer way to query databases. But when developers have to make their own custom queries, they often use prepared statements to keep things secure.

However, even with these tools, the most important factor is educating developers about security. For instance, I once found a blind SQL Injection attack that let me pull all the data from a database. I immediately let the customer know about this critical problem. I worked closely with their team to help fix it, and they told me it was resolved. But when I checked again, the problem was still there. They insisted they had used prepared statements, a recommended secure practice. But how they had used them showed that they hadn't been properly trained in writing secure code.

Here is a classic payload example that may bypass your login function. The following can be put into the password field:

' or 1=1 --

I won't go into detail explaining SQL Injections here, as it's a well-known example and you can easily find explanations online.

If you rush to try this on your own app and it doesn't work, don't be misled. SQL Injection is almost like a science. We usually test a wide range of attack strategies based on the information we have, such as the type of database, any firewall rules, and more. Remember, the attack strategy can be changed over and over, depending on how the app responds.

Want to keep safe from SQL Injections? You can use prepared statements or an Object-Relational Mapping (ORM) model. But that's not enough. You should really understand the tools you're using. Don't just copy and paste code that seems to work without fully grasping what it does. Consider taking courses that focus on how to code securely. This way, you won't just know what functions to use, but also how to use them properly. Even then, you can reach out to us to make sure the code pass the penetration tests!

Let me upload a file

Many web applications we test allow users to upload files. If the file upload feature isn't designed carefully, it can lead to big problems.

In many cases, uploaded files are stored on the same web server that hosts the application code (this is common with PHP or ASP). So, if the application code is in a folder named /controller/, the files might be stored under /files/. How these files are treated - whether they're run as code or offered for download - depends on their file type, and that's decided by the web server when a request is made.

An attack using this vulnerability typically happens in two stages. First, a user uploads a file. Then, the user (or someone else) downloads that file, which triggers the server to do something with it. Attackers target the upload process to trick the web server into treating the uploaded file as executable code rather than a file for download (for example, uploading a PHP file instead of an image).

Once a user runs code that an attacker uploaded, it's basically all over. The server's interpreter runs the attacker's code just like it would any other part of the application.

There's no one-size-fits-all solution to this, but a good start is to use the secure file upload features that most web frameworks offer. If your application runs on the web server's interpreter, you could also consider these defensive steps:

Firstly, always change the permissions of the upload path to make it non-executable. This helps prevent remote code execution, even if a vulnerability is found.

Secondly, move the upload directory to a location that isn't accessible to an attacker, like /uploads/ instead of /var/www/html/uploads. Even if an attacker finds a vulnerability (which they shouldn't), they can't run the file because they can't ask the web server to download it. To allow downloads in this setup, you'd need to manually read the file and send it to the user, including the correct HTTP headers.

You are not untouchable

Some folks believe they're untouchable, writing code that's as secure as Fort Knox. But guess what? Eventually they get hacked! The best way to truly gauge your coding skills is to get a penetration test done. Let us find the loopholes in your system before someone else does. Above all, stay informed about the latest tech threats and how to guard against them.

Contact us now to talk about penetration testing or whatever else might bothering you.

White Hat Hackers are here to help you, so take advantage of us!

You can find our our offered services at https://cybervelia.com/

Me, Penetrating their defenses

Theodoros Danos — Sun, 06 Aug 2023 18:03:38 +0000

Their greatest weakness

Today I will tell you a short story of how I was able to penetrate a company and gain complete access to their files, contacts, emails, backups, images, source-code, practically, every byte they had. I was a penetration tester on a project that was a bit out of the ordinary. The client didn't want to nitpick every nook and cranny of their systems. Instead of being granted a detailed scope of access, I was challenged to infiltrate their information systems from an external, remote position, emulating a genuine cyber attack - no limitations except physical ones. Methods like WiFi, RFID cards, and other such 'sweet things' could have been beneficial, these physical attack strategies were off-limits as per the client's rules of engagement.

Information Gathering

First step, I started gathering as much information I could by performing OSINT techniques and gathering information regarding the company and the company employees. Regarding their infrastructure I evaluated their domains and I gathered basic information such as domains, subdomains, mail-servers, ports any web-application hosted and more. Finally I conducted threat intelligence (along with a fellow hacker). Among various discoveries, I managed to uncover WiFi passwords, previously leaked credentials, and employee email addresses. Along with my hacker comrades, we meticulously charted their buildings, pinpointing entrances and determining the layout of their premises. We supplemented this with images gleaned from social media and their own website to construct a comprehensive picture of their physical environment - this could give us an idea of how the organization is structured, which may, or may not, help later in the social engineering phase - and in any red team activities that could follow in the future.

Launch the missile

Next, we started a full enumeration of their infrastructure and scanning for possible vulnerabilities. There was not much services except mainly their main website. I had to say that was a tough job and there was no way of getting into their internal network through their external infrastructure. As much I wanted to break-in there was no other way (given also that there were time-limitations too).

Well, to get things going, we continued with assumed breach. We gave the customer a custom device which when plugged into their network (i.e via Ethernet) it could connect back to us and give us shell via the device. It’s like being there without being there - in short, a RAT in their network. Their internal network was rough, and there was a good firewall with all proper plugins. The firewall could detect and block our plugged-in device. Explicitly unblocking our device by the IT manager we continued our journey by scanning for potential vulnerabilities yet without automated tools, to be as stealthy as possible (stealthy regarding the detection tools - IT manager was aware of course).

We exhausted all of our time window trying to breach the target from an unauthenticated standpoint. Every system was updated, each machine correctly configured, leaving no room for slip-ups. Despite our best efforts, we couldn't penetrate the target. What an embarrassing moment!

Reuse every bit

Along-side the network scan procedures, we made some research regarding their staff. Their internal infrastructure was based on Active Directory and they were using OWA as an email solution. During that time we prepared several phishing campaigns, but one was targeting all the users. We prepared a phishing scenario where the target goal was to harvest user credentials. We knew that their email account’s username and passwords were also used internally to log-in into their AD. Therefore, we concentrated our effort to gather as much credentials as possible targeting all users, except some senior ones, that could raise suspicions.

The Phishing Campaign

The plan was straightforward: we set up a simple website unrelated to their current infrastructure and the applications they were accustomed to. We introduced something completely new to them - a fresh service! The employees would receive an email, seemingly from their IT manager (but in reality, sent from our server), introducing this new service and inviting them to log in using their existing credentials. We provided a link (a phishing link) that led users to a login page on our website. The service offered was relevant to the employees' line of work. For instance, if it was a law office, the service might appear to be a new database for filing documents.

We quickly made the application and set everything up on our end, so it was ready to go. We used a domain that was a lot like theirs, just changing some letters around, so it wouldn't seem out of the ordinary.

During our reconnaissance phase we have managed to gather a list of 1100 employee emails. In our phishing campaign we have sent out approximately 900 emails and 150 users were hooked - we got some creds!. That’s almost 15% of their users providing their corporate credentials - that’s a good catch. Some users were trying too many times without success (failing to login, as we didn’t had any real application behind that fake login page). Following this, we could not log-in to their email accounts, as all users were protected by a 2FA mechanism. Eh, we were blocked again.

The bomb

So we returned back to their internal network. We have managed to use the credentials, and have some basic user access to the organization’s Active Directory.

A side note here, keep in mind that the assumed breach could have been skipped if the company had a public VPN access - then we could have used the gathered valid credentials to log-in through the VPN and have access to their internal network.

We have not found any user that had special permissions on anything that could be used to abuse any internal network misconfiguration. However, with a simple user we could have access to their Active Directory environment and so we could enumerate the AD, even though the Active Directory was tough - much like a concrete wall. Even though very well configured, had a very tiny, little weak spot, that was only accessible by any authenticated user. That was an old feature of AD left forgotten and misconfigured. It was a very well hidden weak spot but we eventually found it.

Well.., using only basic user credentials we took advantage of this mistake to gain top-level access (Domain Admin privileges). At this point we had everything at our disposal: emails, files - confidential documents, conversations, servers, web-application code-base, user accounts and more. This put the whole system at risk. Of course, we didn't do anything to hurt the company and we quickly got in touch with our point-of-contact there, as we were in a close-loop. If a real attacker had found this weak spot, the company could have been seriously harmed. Luckily, they had a security test (the one we did), which helped them find and fix problems like this one and others, like the phishing issue. After the test, we didn't just give them a detailed report. We also had a call with their team to talk about everything that happened during the test.

The moral lesson

What's the lesson here?

Even if you create strong security, it can all fall apart quickly when people make mistakes. The IT team might have set up a secure network and the developers might have made a safe web application. But, the network was still broken into when people messed up - ok the network had a well hidden issue too. We can be pretty sure about our systems, but we can't always be sure about our people. Especially those who haven't been taught about these things - but it's not their fault. This is something we can fix, just like anything else.

Think about these questions and evaluate how ready your company is to defend itself:

What is the last time you performed a phishing campaign?
How often do you perform a penetration test?
What systems do you test during the penetration test? Does this make sense? Are the most valuable?
How advanced phishing campaigns can your employees defend against?
Have you ever called an expert to train your employees against phishing campaigns? What about targeted phishing campaigns?
How well configured is your Active Directory environment?

You are not untouchable

Some believe they're invincible, setting up networks and systems that are as solid as a fortress. But guess what? Eventually, they face breaches! This is not a warning, but a reminder - in the world of IT, security isn't just an option, it's a necessity.

The best way to truly gauge your IT and coding skills is to get a penetration test done. Let us find the loopholes in your system before someone else does. Above all, stay informed about the latest tech threats and how to guard against them. You may start by subscribing to Cybervelia's newsletter.

White hat hackers are here to help you, so take advantage of us!

You can find our offered services at https://cybervelia.com/penetration-testing

Originally posted on Cybervelia's main blog found here: https://blog.cybervelia.com/p/breaking-their-defense-hacking-stories

Develop Bluetooth Apps | Fundamentals, Tools & Code

Theodoros Danos — Sat, 09 Apr 2022 21:45:04 +0000

This is a very introductory post in the Bluetooth technology. Its the first part so tune in for longer and more thorough articles.

Intro

In the Bluetooth world the Bluetooth technology has been evolved to support a sub-protocol of Bluetooth which is more energy aware. So we have Bluetooth classic which is used by your audio earrings or your car's audio system, and then we have the Bluetooth Low Energy which is used mostly by power-constrained devices such us your smartwatch, your phone or your smart lock.

I will explain the very basics of the BLE and then I'll move forward with a complete Bluetooth application.

The protocol

The Bluetooth Low Energy protocol is very simple. There are many network layers involved but you should not worry about any of them right now. We will write our apps using the application layer, as the BLE controller will handle the rest of the work for us.

In the Bluetooth ecosystem, there are two type of devices: centrals and peripherals.

The former are devices which connects to peripherals, think of them as clients - i.e your smartphone.
The latter are devices that accepts new connections. Think of them as servers - i.e your smartwatch.

The following figure summarizes the concept:

In BLE, there are some profiles defined by the Bluetooth SIG - the official organization taking care of the Bluetooth protocol.
Such profiles are HID profile, Heart Rate profile, Health thermometer profile, Proximity profile and many more.
Each profile defines which particular services must be served by the device. Each service may have zero, one or more characteristics - usually a service has between one to five characteristics.
The characteristics can be thought of as input/output endpoints of a service.
Each service or characteristic has a Unique Id, a UUID.
When a peripheral device wants to be found, its in advertising mode. In such mode advertisement packets are transmitted and received by nearby central devices scanning for peripherals. Such packets contains device-specific data such as the device's name, Bluetooth Address or battery level. Such data are analyzed in later posts of the BLE series, so don't forget to follow.

The implementation

Controller used: Open-Source BLE:bit device - Official: blebit.io
Scenario: Setup a central device and a peripheral device. Both of the devices will be controlled by our software. The goal is to have two computers communicate over BLE.

In later articles I will show you how to communicate with a smartwatch.

Setting up the Peripheral

So we will firstly setup the peripheral device. It will offer some services to the clients and will be able to accept new connections.

Since we are using BLE:Bit we will use the BLE:Bit Java SDK. The BLE:Bit is one of the easiest tools to programmatically access and setup a Bluetooth connection. Also, it offers off-the-shelf tools which helps in BLE security auditing, recon, enumeration, debugging or any kind of BLE automation, really.

The following code creates some services, adds some characteristics and creates the controller object which when finished, it starts advertising to nearby devices.


public class VerySimplePeripheral {

    public static void main(String[] args) 
    {   
        setupPeripheral();
    }

    private static void setupPeripheral()
    {
        try {
            /** Retrieve a BLE:Bit Peripheral controller **/
            PEController pe = BLEHelper.getPeripheralController(new PEBLEDeviceCallbackHandler());

            /** Create a connection parameter **/
            pe.sendConnectionParameters(new PEConnectionParameters());

            /** We won't make use of any pairing method **/
            pe.configurePairing(ConnectionTypesCommon.PairingMethods.NO_IO);

            /** Set peripheral's Bluetooth Address **/
            pe.sendBluetoothDeviceAddress("aa:bb:cc:dd:ee:ff", ConnectionTypesCommon.BITAddressType.STATIC_PRIVATE);

            /** Create HRS service **/
            BLEService heart_rate_service = new BLEService(UUID.fromString("0000180D-0000-1000-8000-00805F9B34FB").toString());

            /** Create advertisement data **/
            AdvertisementData adv_data = new AdvertisementData();
            adv_data.setFlags(AdvertisementData.FLAG_LE_GENERAL_DISCOVERABLE_MODE | AdvertisementData.FLAG_ER_BDR_NOT_SUPPORTED);
            pe.sendAdvertisementData(adv_data);

            /** Add BLE Characteristic Heart Rate Measurement **/
            String uuid_char = UUID.fromString("00002A37-0000-1000-8000-00805F9B34FB").toString();
            BLECharacteristic hr_measurement = new BLECharacteristic(uuid_char, "hello-world".getBytes());
            hr_measurement.enableRead();    // Enable read-requests
            hr_measurement.enableWrite();   // Enable write-requests

            /** Bind Characteristic to the service **/
            heart_rate_service.addCharacteristic(hr_measurement);

            /** Attach service to the controller device **/
            pe.sendBLEService(heart_rate_service);

            /** Let the controller know that 
             * we have finished with setting 
             * up the device **/
            pe.finishSetup();

        }catch(IOException e) {
            System.err.println(e.getMessage());
        }
    }
}

The above code shows how easy job it is to create a peripheral using the BLE:Bit SDK. Break-down of the above code:

BLE:Bit Controller and the appropriate callback objects are created
Connection and pairing/security parameters are set
Address & Advertisement packet set
BLE service and characteristics are defined
Setup is finished - Device starts advertising to nearby devices

In the next article we will cover how a central device can be setup so peripheral can exchange data with the central device. No hardware knowledge is needed, as the BLE:Bit tool can be fully controlled by the software and is connected over USB.

In future articles, I will present how you may develop more advanced applications and also communicate with devices such as smartwatches and the like.

For more information about the Bluetooth controller: docs.blebit.io

How to avoid AWS Cloud Security Mistakes

Theodoros Danos — Tue, 29 Mar 2022 21:19:57 +0000

In this post, as with all of my posts, I want to be brief, because its your time I am spending right now and that's precious.

In short, in this post I will explain some of AWS Cloud Security Misconfigurations I often see in the pentests I carry out.

Open S3 Buckets

An S3 Bucket is a cloud storage where the AWS can help you store objects, which are essentially files. The web applications are using the S3 buckets for various reasons including hosting a website through the s3 (static content, using a dynamic API found in another host), host the private files of the user (instead of hosting them in the webserver) or even hosting static files of a website such as images, css or JavaScript files.

Firstly, the buckets have different configuration options in AWS. For buckets that its indented to be used only for private files, you should configure them to disallow any public access for the whole bucket. That means only authorized requests are allowed to access any object within the bucket.

Secondly, you can specify which objects can be public and which can't. Often, people are based in Security through security motto, and hide files in the S3 with the assumption that nobody knows the filename or it is difficult to be assumed.

This is connected with the next issue, which is a overly permissive S3 buckets. By default a bucket doesn't disallow from anyone (outside your organization) to list the bucket files. That means, the files of your bucket can be listed. Therefore, if the files are in public view, anyone can download them. Control who can do what in your bucket by setting up the ACLs and put some resource policies.

Uploading to an S3 Bucket
You should only upload to an S3 bucket only through your webserver. You would wonder why. The reason is because while the AWS may pass on a session token which can be passed to the client-side for uploading directly to the S3 bucket. At a first glance, it may seem fair and safe. However, you must verify that the uploading folder is the right one (as the bucket name is also sent through the client). Not only that, but by default any object uploaded (by ANY user) it overrides any previous file being in the bucket. That means by knowing the other user's filenames can be fatal, as a user may overwrite the files of another user. Due to difficulty in development of such functions I personally recommend to avoid such techniques, and sending the file firstly to the webserver and then forwarding the file to the S3 through the webserver. Make sure the file isn't in the root directory (or any other directory accessible by the user directly as a webshell can be uploaded).

Accessible Metadata

AWS offers an API to its various services which a programmer can perform API requests and retrieve various information. Such information could be a session token.
One may wonder, how one could call such metadata services?

The services can be called internally, when enabled for a particular service, by using the following endpoints:

http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy http://169.254.169.254/latest/user-data http://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE]

More endpoints exist, which can be used for any kind of things. Endpoints which are very useful for an attacker.

So how an external user, may call such metadata services belonging to AWS? To perform such queries one may have access either through a EC2 instance, or through a lambda function. This can be done by exploiting another vulnerability, such as SSRF or RCE.

Due to high number of attacks taking advantage the metadata service, AWS now gives the option of a second version of the service which requires two requests to perform a request. Therefore, an SSRF (which is a single request from a user to an internal node) cannot be used to exploit this misconfiguration. The metadata service is also known as IMDS (Instance Metadata Service). Make sure that your instances, use IMDSv2! If you don't need IMDS, then disable it for the particular instances.

Misconfigured Security Groups

One of the most common mistakes the cloud engineers do, is to have a security group (especially the default one) to be open to the internet by permitting the internet users to access all inbound ports. There are sensitive services which should never be allowed to reach the internet, such as MySQL servers, RDP servers and more. If there is a need to offer a service to a remote host, you can do this through whitelisting the IP address or through CIDR.

I hope the above most-common mistakes are enough for now. Follow me to have a look at the second part which is the most interesting, covering policies and IAM privileged escalation.

Where all DEVs fail in Security

Theodoros Danos — Mon, 28 Mar 2022 21:34:49 +0000

Intro
I have been in security for several years. My work is to test an application or an infrastructure and try to break in.
If you are a developer the following is probably one of the vulnerabilities you may find in your applications. If you are elite in security and dev, then stop and close this thread.

Most developers lack of the proper knowledge of Information Security. In this post I am talking about the access control issues.

Access Controls
When one designs an application, roles and permissions may be given to users. At most of the time, i find vulnerabilities in user elevation of privileges. This is a particular type of an access control issue, where a low-priv user can escalate to an higher-privilege user. Make sure ALL of the functions are protected so low-priv users, even if they can load the UI, do not have the permissions to execute any endpoint which requires higher privileges. You may think, that this may sound too dump. But most of the applications suffer from such vulnerabilities. Moreover, such vulnerabilities can lead to account takeover!

IDORS
Another type of an access control issue is an IDOR one. Many endpoints support numerical parameters. An example is a "pageId", in a GET request. Most of the time, the endpoints have all sort of checks, like for XSS or SQL-Injections, but the developers often forget to check if the ID can be used to access information that doesn't belong to user. Due to the incremental number of ID, most of the time this kind of vulnerability is easy to exploit. Make sure the users can access to information belongs to them by properly enforcing access control rules.

Summary
A great number of developers takes such vulnerabilities as low-risk, but the reality is that such issues are of a high-risk or of critical risk. Imagine the ID to be an order ID, or the low-priv users to be able to set the password of the admin, or even become admin their-self. Such issues happen and I can confirm are happening more than often.

Thanks for reading, take care, and follow me for more tips.