DEV Community: J2RGEZ

Web Pentesting Learning - Beginner edition

J2RGEZ — Thu, 01 Sep 2022 09:37:07 +0000

After a couple of years of learning on my own, I created a brief list of the assets I think were most useful for me at the time of learning web pentesting. Hope you find it helpful!

Books

Linux Basics for Hackers: Getting Started with Networking, Scripting, and Security in Kali, by OccupyTheWeb. => Beginner friendly and very well written.
Penetration Testing: A Hands-On Introduction to Hacking, by Georgia Weidman => In my opinion it’s a bit outdated and some parts are difficult to understand but still a very good book.
Web Hacking 101, by Peter Yaworski => A summary of all common web vulnerabilities with examples.
Hands-On Penetration Testing on Windows, by Phil Bramwell => Also focusing on the registry tree and how the most common keys work (such as kerberos keys that handles authentication). Microsoft official docs are good for this.

Twitter accounts

@three_cube a.k.a OccupytheWeb. This is from the author of the first book listed above and also has a very good hacking blog: https://www.hackers-arise.com/
@theXSSrat
@stokfredik =>The coolest hacker ever! He also has a great YouTube channel
@NahamSec
@TheHackersNews
@thecybermentor and @TCMSecurity

Overall #infosec twitter is a very good place to start reading writeups and latest news.

Platforms to get your hands dirty

If you’re just starting, I recommend Tryhackme. It’s amazing! And it has a lot of walkthrough boxes (just be aware of this). Then, I would jump to Hackthebox which has the most realistic machines. In my opinion pentesterlab is a bit expensive for the quality their competitors have for almost half the price, but their certificates are good.

Bug bounty platforms

Bug bounty is about hacking as a freelancer, but it’s nice to read writeups (if public), as these are real business-level vulnerabilities. Also reading about bug bounty will teach you tricks to increase your speed and overall organization, which is one of the key skills you need in this category. Why? Because you want to report your findings before anyone else to get paid and avoid duplicates. Hackerone is one of these platforms: https://hackerone.com/directory/programs?order_direction=DESC&order_field=resolved_report_count

Tools you should know (basic level)

Metasploit
sqlmap
nmap
Burp Suite or any other web scanner alternative
Hydra login cracker
Any hash cracker like john the ripper, hashcat, etc
Shodan: at least to understand what it is, in case you want to use it one day

FAQ

What are writeups? Instructions about how someone hacked something in detail.

I’m most probably missing something here, but I think it’s a nice starting point. Let me know in the comments if you would add anything else to this list and/or what helped you when you started learning pentesting.

Event-sourcing and the event-replay mystery

J2RGEZ — Fri, 06 Nov 2020 09:12:50 +0000

It’s been a while since we first started our way into event-sourcing and, from our experience, we really think that there is still space to dig into what event sourcing is and why it’s useful for modern backend applications. But first...

What’s event-sourcing?

Event-sourcing is a collection of patterns that introduces a new way of thinking, where domain events are the source of truth (domain referring to domain-driven design). We need to fulfill the following contract:

The event store persists the full history of domain events. For example:

UserRegistered
UserChangedPassword
UserPublishedAnArticle
Domain events must be chronologically ordered
Domain events are immutable

Given #1 and #2, we can actually replay domain events. That is, reconstructing the state of your application by running the full history of domain events, which can give you the chance to reconstruct the current state of your system and go back to a specific point in time, allowing the following:

Easily find bugs from the system and reconstruct those bugs in different environments.
Deploy different versions of your backend for testing purposes.
Recover from errors by replaying events from a specific point in your system.

Specifically for microservice architectures, there is one case when this comes in handy: Imagine adding a new service, meaning a new read model (local DB) needs to be created. For this purpose, we need to reconstruct the current state of domain models by replaying domain events from the Event Storage. This operation becomes easier when adding snapshotting to the formula.

Snapshotting for event replaying

Snapshots represent the current state of an entity (or aggregate) at a specific time. Snapshots can be configured to be done whenever you want. For example, every X events, X days, or when something special happens in your system.

Replaying events then becomes easier, because you can start rebuilding your service from a specific point of your events’ timeline, and then run all further events from that point. Check the example below.

As you can see, you don’t have to go back to the first UserRegistered event and run all events, but instead, you just take advantage of snapshotting and rollback the User state just before deleting the article.

Not everything is shiny

Definitely, event sourcing advantages were the ones that motivated us to enter this field, but along the way, we found that things weren’t as easy as the theory says:

With high traffic, what would happen if your application goes down? How are you going to recover from the previous failed events plus keep receiving the new ones?
How do you handle side effects? For example, when replaying events imagine that one of the events calls your email service. In that case, we should check that the email was previously sent, or otherwise while we replay the events, the user could end up with a lot of repeated emails.
When should you store a snapshot? Snapshotting depends a lot on the business needs, so we should be open to leave this as configurable as possible, or just generalize it and snapshot every X events.
Is it better to store snapshots synchronously or asynchronously? Synchronous snapshot persistence could happen if you’re not worried about persistence latency.
How do you handle new events coming while replaying events?
How are you going to manage GDPR? As events must be immutable, theoretically you can’t delete events even if they contain personal data.

These problems can be probably solved by adding more control parameters to your events, adding additional checks (to avoid side effects for example), or having a high available queue system like Kafka/RabbitMQ in the middle of your store and your database (for events queuing and system recovery).

Although, what we’ve missed these years is an event-sourcing standard implementation, where the developer doesn’t have to think about the big complexity it has to develop the majority of useful use cases. That’s what we’ve been trying to do with Booster Framework, and we are really excited about what we’ve currently achieved.

Feel free to join our discord or slack if you want to know more about it!

Booster framework vs Ruby on Rails

J2RGEZ — Fri, 14 Aug 2020 13:39:33 +0000

After all these years, Ruby on Rails is still one of the frameworks we like most. Now that we’ve developed the Booster framework, we’re curious about how it stacks up to Rails in various aspects:

Code: How much code do you need to write to get similar features?
Infrastructure and configuration: What resources are needed? How are they configured? How are they kept up and running in a production environment?
Scalability and costs estimation: What if our application starts to grow? How much effort and cost will there be?

The plan for this comparison is to build a real-time chat application on both frameworks with three models: Chat Room, Messages, and Users. To save time, we’ve gone ahead and built the app with both frameworks. If you want to see the full code, go ahead and check our Ruby on Rails and Booster repos.

Code

To build the Ruby on Rails application, we chose Action Cable and Rails 6. If you’ve worked with Ruby on Rails before, you know the steps we needed to take:

Set up Docker using Redis as our Action Cable adapter.
Configure authentication.
Generate the models, controllers, and views for our app.

Maybe the hardest part was properly configuring the Action Cable client-server interaction. It’s challenging but can be accomplished by reading the docs carefully.

And what about Booster? Before we begin talking about the implementation, we encourage you to check out the Booster architecture documentation.

To begin with this app, we replicated the models from our Ruby on Rails application shared above, with the objective of creating at least one command, event, entity and read-model for each one. We didn’t need to install additional dependencies, and even authorization and authentication is built-in.

Although the objective of this article is not to do a tutorial, we want to show you just one use case:

When I create a chat room, the current user must exist in the system

@Command({ authorize: [User, Admin] }) 
export class CreateChatRoom { 
  public constructor( 
    readonly name: string, 
    readonly description: string, 
    readonly isPrivate: boolean) {} 

  public async handle(register: Register): Promise<void> { 
    if (register.currentUser) { 
      const userProfile = await Booster.fetchEntitySnapshot(
        UserProfile, 
        register.currentUser.email
      ) 
      if (userProfile) { 
        register.events(new ChatRoomCreated(
          UUID.generate(), 
          this.name, 
          this.description, 
          userProfile, 
          this.isPrivate
        )) 
      } else { 
        throw 'Error trying to create a chat room. User not found.' 
      } 
    }          
  }
}

As you can see, by using the Register object, you can retrieve information from the current user. It can also be used to read entities from event-handlers, so you will always have access to existing data in the system by just writing one line of code.

Infrastructure and configuration

Since the code is ready, it’s time to think about where we want to deploy these apps. For the Ruby on Rails application, we just went for the easiest option, which is Heroku.

Still, we’re missing a couple of important components for this infrastructure to be complete: Redis and PostgreSQL. In a Ruby on Rails application, we should configure the environment files (and the action cable one) to point to these services.

The Booster Framework has an AWS-based infrastructure (for now), which depends on DynamoDB, AWS Lambda, API Gateway, and AWS Cognito. Here’s a diagram just in case you’re curious about the infrastructure:

To deploy a Booster application, you just have to type boost deploy -e <environment> on your CLI, and Booster will automatically generate and connect all AWS services mentioned above for that specific environment.

Scalability and costs estimation

Another important point of comparison is cost and scalability. Let’s estimate the relative costs of a production environment for both frameworks:

Heroku production environment:

Performance-M dyno ($250 per month, per dyno)
1GB Redis plan ($100 per month)
Private 0 PostgreSQL plan ($300 per month)

This makes a total of $650 per month, and we didn’t take into account the scalability of the system. As your application starts growing, you will need to increase not just the number of dynos, but to upgrade the PostgreSQL and Redis add-ons.

In the Booster Framework, all deployed services are included in the AWS free tier. After this initial year and depending on your region, you will mostly pay for the resources that you actively use.

So, how much would it cost to create a production environment using Booster? (eu-west-1 region)

DynamoDB: 64GB of capacity, 1 million read and writes on-demand = $220.89
AWS Lambda: 1 million requests, 1500ms request duration, 1GB memory allocated = $25.20
API Gateway:
- REST API: 1 million requests = $3.50
- Websocket API: 1 million requests = $1.14. We will also pay $0.285 per million connection minutes.
AWS Cognito: The first 50,000 monthly active users are free even without the free tier.

These prices would end at a total cost of approximately $249.59 per month, with a maximum of 50,000 active users. Remember that this price may vary depending on your region and your monthly requests and/or data stored.

And what about scalability? The AWS services that Booster uses will scale automatically as your applications start receiving more requests, so you don’t have to worry about any additional configuration!

Conclusions

Developing with Ruby on Rails was very comfortable but the Action Cable part was not as natural and simple as we’d like it to be. Booster, on the other hand, not only has authorization built-in, but we don’t have to worry about dependencies and the code is much easier to read. It felt like we were focusing on business actions and not low-level technical configuration and boilerplate code.

Regarding infrastructure and configuration, Booster takes the lead here. Being able to deploy your entire application by running one single command without any other additional configuration is definitely a huge advantage. In the case of Ruby on Rails, configuring it on Heroku is not a very big deal but still requires you to create the app and connect Redis and PostgreSQL for every environment.

Finally, the cost of running a production environment with Booster is much cheaper than with Ruby on Rails. Furthermore, when scaling your application in Booster you don’t need to worry about any additional or special configurations. Everything is done automatically for you.

Overall based on these criteria, we think that Booster is a better choice. Still, we would be missing the benchmarking side of both apps but that’s for another article so, stay tuned!

Week 3: Introduction to John the Ripper

J2RGEZ — Thu, 02 Apr 2020 20:30:29 +0000

In your way through penetration testing, you will find yourself in situations where passwords or critical information are encoded. When this occurs, you first need to find in which format that hash is and then, try to decode it. For these cases, I like to use John the Ripper, one of the most popular password crackers around. So, let’s begin!

Formats

A format is just the kind of encoding that you’re trying to use. Let’s check how many formats john has by typing john --list=formats. You should see something like this:

j2rgez@myPC:~$ john --list=formats
descrypt, bsdicrypt, md5crypt, md5crypt-long, bcrypt, scrypt, LM, AFS,
tripcode, AndroidBackup, adxcrypt, agilekeychain, aix-ssha1, aix-ssha256,
aix-ssha512, andOTP, ansible, argon2, as400-des, as400-ssha1, asa-md5,
AxCrypt, AzureAD, BestCrypt, bfegg, Bitcoin, BitLocker, bitshares, Bitwarden,
BKS, Blackberry-ES10, WoWSRP, Blockchain, chap, Clipperz, cloudkeychain,
dynamic_n, cq, CRC32, sha1crypt, sha256crypt, sha512crypt, Citrix_NS10,
dahua, dashlane, diskcryptor, Django, django-scrypt, dmd5, dmg, dominosec,
dominosec8, DPAPImk, dragonfly3-32, dragonfly3-64, dragonfly4-32,
dragonfly4-64, Drupal7, eCryptfs, eigrp, electrum, EncFS, enpass, EPI,
EPiServer, ethereum, fde, Fortigate256, Fortigate, FormSpring, FVDE, geli,
gost, gpg, HAVAL-128-4, HAVAL-256-3, hdaa, hMailServer, hsrp, IKE, ipb2,
itunes-backup, iwork, KeePass, keychain, keyring, keystore, known_hosts,
krb4, krb5, krb5asrep, krb5pa-sha1, krb5tgs, krb5-17, krb5-18, krb5-3,
kwallet, lp, lpcli, leet, lotus5, lotus85, LUKS, MD2, mdc2, MediaWiki,
monero, money, MongoDB, scram, Mozilla, mscash, mscash2, MSCHAPv2,
mschapv2-naive, krb5pa-md5, mssql, mssql05, mssql12, multibit, mysqlna,
mysql-sha1, mysql, net-ah, nethalflm, netlm, netlmv2, net-md5, netntlmv2,
netntlm, netntlm-naive, net-sha1, nk, notes, md5ns, nsec3, NT, o10glogon,
o3logon, o5logon, ODF, Office, oldoffice, OpenBSD-SoftRAID, openssl-enc,
oracle, oracle11, Oracle12C, osc, ospf, Padlock, Palshop, Panama,
PBKDF2-HMAC-MD4, PBKDF2-HMAC-MD5, PBKDF2-HMAC-SHA1, PBKDF2-HMAC-SHA256,
PBKDF2-HMAC-SHA512, PDF, PEM, pfx, pgpdisk, pgpsda, pgpwde, phpass, PHPS,
PHPS2, pix-md5, PKZIP, po, postgres, PST, PuTTY, pwsafe, qnx, RACF,
RACF-KDFAES, radius, RAdmin, RAKP, rar, RAR5, Raw-SHA512, Raw-Blake2,
Raw-Keccak, Raw-Keccak-256, Raw-MD4, Raw-MD5, Raw-MD5u, Raw-SHA1,
Raw-SHA1-AxCrypt, Raw-SHA1-Linkedin, Raw-SHA224, Raw-SHA256, Raw-SHA3,
Raw-SHA384, ripemd-128, ripemd-160, rsvp, Siemens-S7, Salted-SHA1, SSHA512,
sapb, sapg, saph, sappse, securezip, 7z, Signal, SIP, skein-256, skein-512,
skey, SL3, Snefru-128, Snefru-256, LastPass, SNMP, solarwinds, SSH, sspr,
Stribog-256, Stribog-512, STRIP, SunMD5, SybaseASE, Sybase-PROP, tacacs-plus,
tcp-md5, telegram, tezos, Tiger, tc_aes_xts, tc_ripemd160, tc_ripemd160boot,
tc_sha512, tc_whirlpool, vdi, OpenVMS, vmx, VNC, vtp, wbb3, whirlpool,
whirlpool0, whirlpool1, wpapsk, wpapsk-pmk, xmpp-scram, xsha, xsha512, ZIP,
ZipMonster, plaintext, has-160, HMAC-MD5, HMAC-SHA1, HMAC-SHA224,
HMAC-SHA256, HMAC-SHA384, HMAC-SHA512, dummy, crypt

Wow, that’s a lot, right? Well, names and/or well-known formats (like MD5 which starts with $1$), could lead you to know which format you’re going to use. So let’s create a new file called my_hash.txt and insert the following hash (in user:password format): root:$1$6ff3402b$2w6aUd7n//XodMXDt84BE1.

Now, to select the decoded format, we type john my_hash.txt --format=md5crypt and check the results:

j2rgez@myPC:~$ john my_hash.txt --format=md5crypt
Using default input encoding: UTF-8
Loaded 1 password hash (md5crypt, crypt(3) $1$ (and variants) [MD5 256/256AVX28x3])
Will run 12 OpenMP threads
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Warning: Only 248 candidates buffered for the current salt, minimum 288 needed for performance.
Proceeding with wordlist:/usr/share/john/password.lst, rules:Wordlist
admin            (root)
1g 0:00:00:00 DONE 2/3 (2020-04-02 20:38) 20.00g/s 90560p/s 90560c/s 90560C/s chacha..OU812
Use the "--show" option to display all of the cracked passwords reliably
Session completed

As you can see, john tried to find a match in its default wordlist and found it! The decoded value is “admin” (let's keep things fast).

There are tons of wordlists around the internet (or you can create your own ones). You can check for example the ones from SecLists repo, and simply type john my_hash.txt --format=md5crypt --wordlist=my_wordlist.txt.

Automating all of this

So, last weekend I was completing some exercises from Pentesterlab when I found this sentence in one of the exercises: Use John by trial and error until you find the format. From the exercise context, you could imagine which format it was, but I was thinking: what if they ask me to do this in the future with a not so obvious format?

So I began my way of automating pentesting processes and created a new repo. Yes, I’m 90% sure that there is a better way (or an existing tool) to automate John the Ripper (or password cracking in general), but I find that it’s also a good way to practice some new programming languages or at least the ones that I don’t use on a day to day basis. So here is the first version of my john_auto_decypher.py script:

import subprocess
import argparse

def decrypt(formats, inputFile):
    keep_string = "Press 'q' or Ctrl-C to abort, almost any other key for status"
    format = ""
    for f in formats:
        try:
            decode_process = subprocess.check_output(["john", inputFile, "--format=" + f], stdout=None)
            if keep_string in decode_process:
                format = f
        except: subprocess.CalledProcessError

    if format:
        print "Found a hash for " + format + " format"
    else:
        print "Couldn't decode, checking for already saved hashes..."

    print subprocess.check_output(["john", "--show", inputFile])

def getArgs():
    parser = argparse.ArgumentParser("john_auto_decypher.py")
    parser.add_argument("file", help="File with encoded passwords to be cracked", type=str)
    return parser.parse_args()

def main():
    inputFile = getArgs().file
    formats = map(lambda str: str.strip(), subprocess.check_output(["john", "--list=formats"]).split(","))
    decrypt(formats, inputFile)

main()

Simple but effective, now by just typing python john_auto_decypher.py <filename> on my CLI, this script will check all formats for me and/or already saved hashes. Of course, there is still a lot to improve, like adding parameters for wordlists and custom rules.

So, that's all for today. Have a very good weekend you all!

Previous weeks:
Week 0: Security blog posts introduction
Week 1: Being conscious about your attack surface
Week 2: Knowing the penetration testing steps

Week 2: Knowing the penetration testing steps

J2RGEZ — Thu, 26 Mar 2020 22:20:37 +0000

Nowadays, organizing yourself is becoming crucial in your everyday life. From diet to training to work, making good planning is key when you’re trying to chase your goals efficiently. In this case, our main goal is to perform a penetration test to a system and there is a well-known way to achieve this in our community:

Information gathering/reconnaissance
Vulnerability scan
Attack phase
Post-exploitation
Reporting

So, let’s describe each one of these.

Information gathering/reconnaissance

As the title says, a penetration tester must gather all information he/she can to be able to effectively jump into the next steps. Knowing your target’s business is very important and you should spend as much time as you can analyzing this.

Imagine that your target is an e-commerce website. In this case, you should take your time and navigate through all the pages (yes, all of them), trying to pay attention to URL formats, existing forms, what is the product, how it is sold, etc. Let’s say that this e-commerce has three plans: free, standard and premium. If possible, you should have an account for each one of these and see what you can do with each one. Remember that every new feature you discover increases the attack surface of the target’s system.

After knowing everything about the product, I would start by identifying open ports, doing brute force directories, search for possible subdomains, check all website’s networking, etc. Usually, you should be asking this kind of questions:

Which endpoints are called and when? Is there a difference in the endpoint when buying as a standard user? And as a premium one?
Which cookies are used and what is the difference between users? Is there any place on the website where I can upload a file? In which format?
What is the framework and libraries this site is using? In which versions are they?
Is there a way that I could find some more info around the internet? Tip: Check this out https://github.com/laramies/theHarvester

Now that you have all the information and you have squeezed all the product and technical knowledge about your target, it’s time to go to the next phase!

Vulnerability scan

Usually performed by using software like BurpSuite, Nessus, Nikto, SearchSploit, and a long etcetera. You’re objective is to check if the current system (that you already know from the first step) has existing vulnerabilities that can be “automatically” exploited (because there is already a script to do it). Also, as a second step, you should try to look for vulnerabilities such as XSS, XXE, SSRF or CSRF on the website and yes, you also have tools to help you with that.

To be honest, if you have the money you should aim to grab a BurpSuite PRO license since it has a bunch of useful tools like a spider, intruder, repeater, plugins, etc. Otherwise, you should look for different options. I’m currently looking for some free (or at least way cheaper) setup that can substitute it so if you know about it, let me know!

Attack phase

As soon as you discover a vulnerability that could make you enter somehow in the system (like uploading a PHP file that has a reverse TCP script in it), you will be entering into the attack phase. In this phase, and if you got access to the system, you must analyze in which state is your user when landing in the target’s console. Now it’s time to gather all the information you can from the current system that you’re connected at:

How many users does the system have and which one are you?
Which services and/or processes are running?
Are IPTABLES configured? Can you check for other devices in the same network?
Very important: Are there any logs and/or backups that could be unencrypted? Maybe a second drive?
Also very important: Are there any cronjobs? public/private keys that you can access?

Post-exploitation

The lasts questions from above (and of course if you find something) make you enter the post-exploitation phase. In this one, your objective is to maintain access to the system. You should be capable of entering that server as many times as you want. Some ideas that come to my mind are:

Using cronjobs + reverse shell (in case the machine is restarted)
Start service with your script
Take advantage of existing automated scripts that you could modify

Reporting

When penetration testing is finished, the last step is collecting all the vulnerabilities you could find and create a report. The format of the report could be a pdf or even a video showing what did you find and it should be as specific as possible. I don’t have much experience writing pentest reports so I won’t dig into this but if you have any tips, just let me know!

Bonus tip

I just want to mention that taking notes is the most important thing you should do when performing a penetration test. You want to avoid repetition as much as possible. For example, you shouldn’t have to run Nmap again to check for open ports if you did it before. Save all the information you can so you can just check it in the future and repeat steps only if you feel that the system has changed.

Acronyms and concepts:

XSS: Cross-Site Scripting
CSRF: Cross-Site Request Forgery
XXE: XML external entity
SSRF: Server Side Request Forgery
Reverse shell: Opening a remote shell from our target machine. Here you have some examples: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet. I’ll talk about this in the future.

Previous weeks:
Week 0: Security blog posts introduction
Week 1: Being conscious about your attack surface

Week 1: Being conscious about your attack surface

J2RGEZ — Thu, 19 Mar 2020 20:14:56 +0000

Nowadays, almost everyone in the world is connected somehow to a piece of software. It doesn’t matter if it’s your smartphone, your PC or just the app you use to talk with your friends. It’s very important to note that although this has made our life easier, every day we will have new access points for an attack to happen.

But getting straight to the point, what is your “attack surface”?. According to Wikipedia, “The attack surface of a software environment is the sum of the different points (the "attack vectors") where an unauthorized user (the "attacker") can try to enter data to or extract data from an environment”. So, whatever application or system you’re using, as I said before, takes part of your attack surface, and it’s your responsibility to keep it as low as possible.

But, how can I identify my attack surface?

Well, as I said before, everything that you’re connected to is a possible access point for an attacker and, more access points means bigger attack surface, for example:

Bluetooth devices: We all use Bluetooth, it doesn’t matter if it’s for your headphones, your portable speaker or any other device.
Laptop: Let’s say you don’t use VPNs to connect to networks and you also don’t care about software updates (or you take too long to do them)
Smartphone: Again, you don’t have a VPN and you always have the wireless ON. And again, you don’t care about software updates.
Human errors: Of course, this is the thing that increases the most your attack surface.

This hypothetic user has a very big attack surface that can be exploitable overtime. In the future, I will talk specifically about different tools or techniques that can help you perform these attacks, but for now, let’s describe what a hacker can do with this:

Being in the same network as a possible attacker (aka anyone) is a very risky thing to do. From the same network, malicious hackers can:
- Redirect you to malicious pages (DNS spoofing). This can lead to phishing attacks, for example.
- Listen and capture your traffic
- Get advantage of nonupdated software versions. There are a lot of places on the internet with the latest exploits available for anyone to check. For example https://www.exploit-db.com/
Also, by having your Bluetooth/Wifi always active, hackers can:
- Try to connect to your Bluetooth devices
- Connect to you via Bluetooth: By “plugin off” your existing devices (i.e. smartwatches) and taking its place
- Open a public network, that your smartphone will log into, and you already know what could happen if you’re in the same network.
Apart from that, and talking about human errors, you should never ignore your antivirus/browser/firewall security warnings (unless you really know what you’re doing). Also, you should be really careful about emails (mostly phishing), images, and links from weird websites. I always try to check the URL from the bottom left corner of my browser to verify that I’m redirected to the desired place.

So, to sum up, these are the things you can do to decrease your attack surface in a local environment:

Disable Wifi and Bluetooth when you’re not using it.
Don’t ignore security warnings from any device/software.
Never connect directly to a public network. You can use a VPN. I personally prefer to connect to my smartphone network (to whatever internet provider you have) via a VPN.
Always update your software. Updates are not only for new features.
Always suspend/shutdown your PC/smartphone if you’re not using it.
Use different passwords in different sites. You can take advantage of password managers like 1password, which also includes password generators (very recommended).
Do not plug your phone into anything that you don’t own. For example, recharge stations in airports, a friend’s laptop, etc.
Nitpicky one: People behind you/watching your screen is always a bad sign. You want to give as little information you can to possible attackers (like watching your keyboard in this case). I will elaborate a bit on dictionary generators in the future, which is kind of related to this.

Developers perspective

Developers are the ones that introduce those new software versions we were talking about before. Software development is not trivial, and because of that, developers can forget about sanitizing certain inputs in your frontend and/or backend applications. I really think that it’s important to note that updating your smartphone applications (as a normal user) and updating your software libraries have the same importance level. Let’s go back to the famous exploit-DB website and let’s look for Spring. For instance, you could use this exploit: https://www.exploit-db.com/exploits/36130. Although this is an old bug, you can see how important is to update your frameworks/libraries. You can keep playing with that website to find other cool vulnerabilities.

Developers attack surface

Apart from versions, developers should be conscious of their system. Do you REALLY need that Redis host for your application? Keep in mind that more infrastructure means a wider attack surface, and also you will spend a lot of time by securing these hosts (by not exposing unnecessary ports, keeping them behind a bastion host, etc).

You may think that all your infrastructure is safe in the eyes of people. “Who will know I’m using Redis? Or that I have a MySQL DB?” you may ask. You can’t imagine the amount of service/domains discovering tools hackers have so knowing what technologies your system is using isn’t, in general, a real challenge. This topic deserves its own post so I’ll keep that for the future.

Apart from that, as a developer, you should know which parts of your company are in use and which not, and you must stop anything that is not used (S3 buckets, old GitHub repositories, unused server instances...). Again, thanks to reconnaissance tools and/or hacker’s expertise, you are just allowing people to know more about your systems.

Reducing human errors

The weakest point in a system is the people that are part of it. From developers to managers to CEOs, everybody is part of your security. It doesn’t matter if a possible ransomware attack started by a manager clicking an email or if a developer inserted a conference gifted USB in one of the company laptops.

The point is that we are all responsible for our security breaches. If a developer setups a server with default credentials (silly but realistic example) and he/she doesn’t know about its consequences, it’s probably because your company is not taking enough care about security. Talk with your people about this periodically, give them some examples of possibles cases were a security breach could happen, train your people. No one is going to do it.

It’s never too late to start, and you don’t want to be that guy that will have to pay 100,000$ to rescue its data (or worst, its clients data). Remember that you are not the target of anyone, yet.

Week 0: Security blog posts introduction

J2RGEZ — Fri, 13 Mar 2020 10:28:08 +0000

Hi! My name is Juanjo and as some of you may know, I’m a Software Developer at The Agile Monkeys. From the last year or so (early 2019), I began my path into the penetration testing world and I have to be honest, I’m loving every piece of it. That’s why today, approximately 1 year after, I decided to write about some stuff I have found interesting during this amazing year (plus new things I will learn of course).

You might be asking what a penetration test is (otherwise just skip this paragraph). A penetration test is a process of studying/analyzing a system with the objective of finding existing vulnerabilities and reporting them back to the system’s owner (so they can fix them). You can check an example of what a penetration test report looks like here: https://www.offensive-security.com/reports/sample-penetration-testing-report.pdf

First of all, I want to clarify that I’m not a penetration tester and I’m not even close to being a pro at all, but I consider that I have studied enough to talk about certain topics or at least the initial/intermediate steps of it. So first of all, I would like to clarify how this is going to be organized:

I will write about a different topic from every Thursday afternoon/evening to the next one. That means that you will have something to read every Thursday.
These posts will not be organized as chapters, and I will probably explain different and unrelated things every time. This is because the beginning part of it could get really tedious to follow.
The objective is not only me teaching you stuff, but you also participating in the comments so we can all share our knowledge. Maybe we can all learn something new!

So, let the write begins!!