Thursday, August 2, 2018

Top 100 Ingredients From HomeChef Recipes

I love cooking, I consider it my primary hobby outside of infosec/coding. I had HomeChef for several months and absolutely loved it, I looked forward to each selection every week and always got to try some new techniques/flavors/combinations I probably would never had tried on my own.

Every meal they sent us had a double-sided recipe page to guide you through the process. I noticed something at the bottom of the recipe page:

They have a handy link for each recipe posted on their website, probably so it's easy to share what you made with family/friends. The fact that I saw a number, along with a list of ingredients got my thinking...

If I were to stock my pantry/fridge with "basic" ingredients, what would it look like? How about I count up the occurrences of certain ingredients on each recipe page, that should give me a good idea.

Well after gathering the data over a couple of days (I kept everything slow so as to not cause any problems) I present to you, the top 100 ingredients according to recipes on HomeChef.com

Count Ingredient
609 Garlic Cloves
433 Butter
345 Boneless Skinless Chicken Breasts
320 Green Onions
315 Shallot
219 Lemon
210 Sour Cream
208 Lime
202 Red Onion
186 Grape Tomatoes
178 Red Bell Pepper
170 Parsley Sprigs
158 Yellow Onion
154 Mayonnaise
153 Red Pepper Flakes
152 Honey
149 Liquid Egg
148 Cremini Mushrooms
142 Russet Potatoes
142 Green Beans
138 Jasmine Rice
135 Cilantro Sprigs
134 Sugar
131 Chopped Ginger
125 Baby Arugula
122 Grated Parmesan Cheese
119 Carrot
117 Roma Tomato
114 White Cooking Wine
104 Baby Spinach
102 Grated Parmesan
101 Panko Breadcrumbs
100 Light Cream
100 Shredded Mozzarella
99 Slaw Mix
98 JalapeƱo Pepper
95 Cilantro
95 Shrimp
94 Thyme Sprigs
93 Zucchini
93 Garlic Clove
89 Parsley
88 Sriracha
87 Dijon Mustard
84 Sirloin Steaks
82 Cornstarch
76 Heavy Whipping Cream
76 Light Brown Sugar
75 Seasoned Rice Vinegar
74 Romaine Heart
73 Pork Tenderloin
72 Kale
72 Shredded Cheddar Cheese
72 Asparagus
71 Sweet Potato
71 Flour
69 Roasted Red Peppers
69 Spinach
69 Ground Beef
68 Salmon Fillets
68 Matchstick Carrots
68 Toasted Sesame Oil
62 Brussels Sprouts
62 Soy Sauce - Gluten-Free
61 Carrots
60 Mini Baguette
57 Small Flour Tortillas
57 Persian Cucumber
57 Basil Pesto
56 Green Onion
56 Ground Turkey
54 Teriyaki Glaze
54 Radishes
54 Red Fresno Chile
53 Beef Demi-Glace
52 Ear of Corn
51 Basil Sprigs
51 Roasted Chicken Breast
50 Roma Tomatoes
50 Blue Cheese
50 Canned Evaporated Whole Milk
49 Marinara Sauce
49 Extra Firm Tofu
48 Smoked Paprika
47 Balsamic Vinegar
47 Naan Flatbreads
47 Bacon Strips
47 Chicken Demi-Glace
46 Taco Seasoning
45 Avocado
45 Broccoli Florets
45 Frozen Peas
44 Chives
44 Corn Kernels
44 Plain Greek Yogurt
44 Tilapia Fillets
43 Navel Orange
43 Feta Cheese
43 Bone-in Pork Chops

What would a post be without some code? below is the embarrassing Python script (hey, it worked...) that parses the HTML:

XPATH Notes (how to grep xpath)

XPATH is a querying language for XML document trees. Lots of web scrapers use it since HTML can be represented as XML directly.

Your basic "grep" like XPATH query is something like the following:

  • //*[@itemprop="recipeIngredient"]
Breakdown:

  • // = start at root of tree and include itself in any searches
  • * = any tag, anywhere in the document, otherwise replace with tag name
  • [blah] = evaluate the condition blah inside the brackets
  • @itemprop = This is how you reference attributes instead of tags
  • [@itemprop] = the condition is: if the itemprop attribute exists in some tag
  • [@itemprop="recipeingredient"] = condition is: if itemprop attribute's value is "recipeingredient"
Another example is if I wanted to search anything that references example.com in an XML document, I'd search for any href attribute that contains "example.com" like so:
  • //*[@href='example.com']
Or limit it just to direct hyperlinks like "a" tags
  • //a[@href='example.com]
XPATH has a lot more functionality than this but this is mostly what I need it for.

PS.
The expression in the condition brackets "[blah]" can be used with certain functions: https://www.w3schools.com/xml/xpath_syntax.asp

Wednesday, August 1, 2018

Finding Interesting Files Using Statistical Analysis

I noticed a pattern when scrounging for target data on pentests. Most of the times in which I get valuable data (test creds/log data/unencrypted logs/etc) they are often in files that are in some way different than those around them. Sometimes its their filename, like when you have 400 files named "NightlyLogDATE" and you see a "NightlyLogDATE.bak". It also tends to happen with file sizes. You'll have the same directory and almost every file is around 400-600KB and a couple will be megabytes big or only a couple KB.

These files are "interesting" to me because they differ in some way. These are the outliers. Sometimes they will be temporary backup files where a tech needed to test credit card processing with encryption turned off, or maybe some error pumped traceback/debug output to an otherwise normal file.

I decided to scrounge around online to stitch together a script that will report these outlier files.

The following script will look in the target directory, calculate the median absolute deviation, compare it against a threshold and return the filenames for you to prioritize pillaging.

It's fairly basic so I'm happy to accept any code donations :D


Friday, July 27, 2018

A Review Of Alex Ionescu's Windows Internals For Reverse Engineers

This year (2018) at Recon in Montreal I signed up to take a class from Alex Ionescu called "Windows Internals for Reverse Engineers", the following are my thoughts on the course and experience.

I decided to take this class after being completely demolished at Infiltrate's "Click Here for Ring Zero" course. That course, despite all its faults, told me I wasn't as strong in Windows Internals as I thought I was. I figured, taking the Windows Internals course from one of the guys that literally writes the book would be a good step. Boy, was I right.

I've taken a lot of training and had lots of bad teachers in the past. Some of those teachers were monotone, non-engaged, unable to map new information to existing concepts, unprepared course material, broken labs, etc. Alex and his course was none of these things. I'm going to break down my evaluation of the teacher and course separately since those are the two main components in all training. I'm going to end with any prerequisites, and final thoughts/recommendations.

Teacher - Alex Ionescu
After going through the training (and talking to several other people in the class) I can confidently say that Alex is at the top (or top 2) of my list in effective communication and teaching. Alex has struck a rare combination of technical mastery over a subject (Windows Internals) as well as the ability to map new information to other people's current understanding.

He exhibited many good teacher practices, below are some of the ones that stood out to me:
  • He would give context for the target material by explaining "neighbor" material that was related. Making it easier to understand technical context and draw logical conclusions.
  • He explained the history behind certain design choices in Windows to help eliminate the "Why the hell would they do it that way?" feeling.
  • Extremely well prepared with the hand out material. 
  • Extremely well prepared with presentation material. He had annotation software allowing him to draw data structures and quickly highlight information pertinent to his point. He also had a countdown timer for breaks/lunch so no one ever asked how much time we had left. He always showed up a minute or two before it expired and started on time.
  • Was engaging with humor (poked fun at Microsoft devs several times) and not monotone at all.
  • Almost never read from the slides, all the information was well understood and presented fluidly.
Course - Windows Internals for Reverse Engineers
The course and its materials were inextricably linked with the teacher so its difficult to speak to it in an independent fashion but here goes nothing.

Make no mistake, this course is not for beginners. It is a full blown firehose of information and topics for 4 days straight. He's pretty relentless and if it wasn't for the fact that he's a fantastic teacher, you'd be easily lost on day one. The course material is extremely technical, in depth, and just a whole lot of it too.

Some things you'll learn about:
  • Setting up local and remote kernel debug machines
  • Windbg syntax, functions, and capabilities
  • OS design/decisions for memory and execution models, address space layout, shared data fields (KUSER_SHARED_DATA), functions and capabilities of the hypervisor
  • Secure UEFI boot signing, hypervisor based code integrity, PatchGuard, HyperGuard, memory segmentation
  • Software guard extensions on new CPUs, kernel/etc interrupts, system calls w/wo hypervisor enabled, win32k.sys
  • Windows object manager, the object directory, kernel handle table, sandboxing
That's maybe 10% of the course right there. I just flipped through the handout and wrote down the slide titles and topics I could remember.

For a higher level explanation of the topics you'll cover, Recon's training site was fairly accurate, granted it doesn't give you a sense of the depth. It's deep, yo.

Prerequisites
On the course signup page he mentions the following in "Class Requirements":
IMPORTANT: It’s helpful to understand x86/x64/ARM assembly to take this course, but knowledge of obfuscation, packing, etc., is not required.
Basic knowledge of Windows, processor architecture, and operating systems is helpful – you should have some vague idea of what an interrupt is, and what is the difference between user and kernel mode (ring levels), a bit about virtual memory/paging, etc.
I would add a couple more to that list:
  • Familiarity with C++ notation/syntax (he uses it a lot in windbg)
  • An understanding of certain programming concepts such as common data structures, type casting, overloading, modules, macros, memory paging, kinds of linked lists, etc.
I personally recommend you give the latest Windows Internals book a read through before coming to this class. It will help tremendously in not being lost.

Areas of Improvement
I'm really reaching here since honestly if nothing changed about this course, it would still be towards the top of my list. I'd say the only thing I wish could change would be more hands on labs and perhaps some reference material in the back of the handout, things like common WinDBG commands, the C++ notation he uses, and other commonly referenced information. I'd also recommend maybe cutting out some pieces he feels aren't as necessary to distill the content a bit more. But like I said, I'm reaching pretty hard here. If you are ready for the course, take it. I extremely recommend it.

Recommendation
If you feel you are the point in your career where you need a better understanding of Windows Internals to be more effective, and you meet the prerequisites, I strongly recommend this course. While its marketed towards reverse engineers (which I am not) it does help the more senior pentester/red teamer who is looking to branch out into custom Windows malware.

If I could go back in time to my previous self trying to make the decision on whether or not to take this course, I'd tell him to definitely take it. But I'd also tell him to read more of the Windows Internals book before he started class :D

PS.
People pronounce windbg in many ways, "win-dee-bee-jee", "win-debug", etc. He pronounces it "wind-bag" which I find too weird for my tastes. I believe I've discovered the true sentiment and feeling of the tool by pronouncing it my own way: "win-deebag".

Wednesday, July 25, 2018

Setting Up A Kali Interception VM

Twice now I've had to setup an interception proxy for testing protocol implementations. Below are the steps I took to configure the Kali VM as my main MITM box. I decided to not use a MITM attack like ARP Spoofing but instead setup Kali as a middling router. The networking setup is rather simple:
TargetDevice (over USB Ethernet adapter)-> Kali VM (Bridged Mode) -> Laptop's Wifi


  1. Download/install Kali as a virtual machine
  2. Set the VM in bridged mode (VMware breaks some things)
  3. Follow the guide here to get Internet sharing configured on Kali: http://itfanatic.com/?q=node/84
  4. Create an iptables rule to redirect your target traffic to your proxy software. Here i'm redirecting all traffic over 443 to 2020 (where striptls is listening): iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 2020
  5. Download striptls from github
  6. Run it locally with something like: ./striptls.py -s --listen 0.0.0.0:2020 --remote exampletarget.com:443
Running striptls is obviously not mandatory since step 3 configured a working middle machine. I just used it in my testing to strip the TLS command from XMPP and HTTPS. You now have a machine all traffic is flowing through and is at your disposal to do with as you wish.

Thursday, July 12, 2018

Noritake VFD Setup

I recently got my hands on a Noritake CU24025ECPB-U1J Vacuum Florescent Display. I always enjoyed the retro 80s/90s feel of VFDs and wanted to gain some experience with with one. Below is a picture of the back for reference:


The model VFD I got comes with its own driver board so its super easy just to send it the text you want over the parallel lines and the VFD driver takes care of the rest. Lots of Noritake's models state that there is a 5 or 6 pin serial port on the driver board allowing you to use sync/async serial instead of parallel. Well I must have been the unlucky one since apparently all I have is a parallel connection (on the far right of the above image). Luckily thats no big deal because Noritake's documentation and sample files make life quite easy.

There are several parts to getting this VFD to work.
  1. Hookup
  2. Downloading the Noritake Arduino Library
  3. Uploading the sample code
  4. Enjoying the VFD
The Hookup
Hookup was relatively easy once you found the proper documentation to tell you what the pins are.
The only thing even close to a datasheet for my exact model of VFD was off of DigiKey's website: https://media.digikey.com/pdf/Data%20Sheets/Noritake%20PDFs/CU24025ECPB-U1J.pdf
There you can see the pin layout towards the bottom of the page:

If you are using the sample code outlined later in this post, the connections for the parallel connector to the Arduino are below:

VFD -> Arduino Pin
1 (GND) > GND
2 (VCC) > VCC
3 (Not Connected)
4 (RS)    > 9
5 (RW)  > 10
6 (E)      > 11
7 (D0)   > 12 //Originally it was 0 but it causes problems with uploading the sketch, so I switched it.
8 (D1)   > 13 //Originally it was 1 but it causes problems with uploading the sketch, so I switched it.
9 (D2)   > 2
10 (D3) > 3
11 (D4) > 4
12 (D5) > 5
13 (D6) > 6
14 (D7) > 7


Now that you have it hooked up, double check your connections so it looks like this:


Downloading The Library

Download the Zip, add it to your Arduino Libraries by going to Sketch > Include Libraries > Add .Zip Library. Once I did that it didn't show up in the menu listing of my libraries but did show up if you clicked "Manage Libraries" as "cuu".

Uploading The Sample Code
Below is the code I used/modified to get it working for my board. I only changed the mode I was using and the pin configurations but other than that its basically the same as the sample code Noritake provides on their QuickStart guide:

 
#include <CUU_Interface.h>
#include <CUU_Parallel_I80.h>
#include <CUU_Parallel_M68.h>
#include <CUU_Serial.h>
#include <Noritake_VFD_CUU.h>
/*VFD > Arduino
1GND > GND
2VCC > VCC
3NC
4RS > 9
5RW > 10
6E > 11
7DBO > 12
8DB1 > 13
9DB2 > 2
10DB3 > 3
11DB4 > 4
12DB5 > 5
13DB6 > 6
14DB7 > 7
 */
 
//Changed D0, D1 from Arduino0,1 to Arduino12,13 so it will upload the sketch fine.
//Apparently it cant upload if there is anything connected to 0,1 on upload :/
CUU_Parallel_M68 interface(9,10,11, 12,13,2,3,4,5,6,7);//RS,WR,RD,D0-D7
 
Noritake_VFD_CUU vfd;
 
void setup() {
  _delay_ms(500);      // wait for device to power up
  vfd.begin(20, 2);    // 20x2 character module
  vfd.interface(interface); // select which interface to use
 
  vfd.CUU_init();      // initialize module
 
  vfd.print("O HAI THERE :D"); // print some text
}
 
void loop() {
}


Enjoying The VFD


And enjoying it, I am. Noritake made it relatively easy to get up and running quite quickly, so I greatly appreciate that.

Now the next step is to modify the code so it takes input from a serial connection so I can control it using a python script. Maybe a retro twitter scroller? I dunno :D

References For Reference :)

Wednesday, May 9, 2018

A Method For Battling Procrastination

I discovered a technique that has helped me battle my own procrastination for getting tasks done. The procrastination most often happened when I had to write my pentest reports.

I found myself, often, avoiding the report and doing something else. Regardless of whatever reason I could come up with I knew it was a psychological reason I was not accomplishing this task. Rarely, if ever was there a concrete reason for holding off writing.

The trick I discovered was when I thought, "maybe I don't want to do it because it feels large and imposing. It feels like I couldn't accomplish it and so I don't even want to start". Thats when I started to break the task down...and down...and so far down that no person in the world could say "I can't do that".

So the last on my to-do list would simply say something like:
  • Write <CLIENT> report
Anxiety/procrastination sets in, so I break it down:
  • Write <CLIENT> report
    • Write executive summary
    • Write narrative
    • Write findings
Nope, still got that procrastination, lets take it to the extreme:

  • Write <CLIENT> report
    • open the file
    • change filename, dates and title
    • Write executive summary
      • summarize important findings
      • etc
    • Write narrative
      • start with explaining pentest network position
      • write recon perspective and returned ports/OSs
      • start writing chronologically the attack timeline
      • etc
    • Write findings
      • Write findings you remember from your notes
      • Gather screenshots/evidence from logs
      • Select the finding templates or make your own
      • etc
    • Send report to QA
Breaking it out this far helped my brain to feel that no matter how big this project is, all I had to do was focus on the singular next piece. No matter how much I wanted to procrastinate, I could at least open the file, I could at least change the dates.

Starting, I found, is the most important step. Motivation to complete something arises AFTER starting that something.

Good luck in life, I hope this technique can help you too.

PS.
This is a general technique, applicable to anything from pentest reports to woodwork projects to picking investments, apply liberally, rinse and repeat.

Wednesday, April 4, 2018

Contributing to Github Projects

The following are some personal notes on the basic workflow for contributing to a project on Github. 

  1. Visit the project's repo page (https://github.com/someguy/nice_project), click on "Fork" in the upper right corner.

  2. Clone your newly forked repo to your local machine
  3. git clone https://github.com/you/nice_project

  4. Set an "upstream" remote so you can pull down "someguy"s code whenever you need to.
  5. git remote set-url upstream https://github.com/someguy/nice_project
    

  6. Create a branch of the master or dev or whatever so you can start making your changes. Give it a meaningful name:
  7. git branch bugFix-UTFencoding
    git checkout bugFix-UTFencoding
    #or all in one with:
    git checkout -b bugFix-UTFencoding

  8. Make your changes, add the files and make a commit:
  9. git add lib/some_file
    git commit -m 'fixed the UTF encoding errors'

  10. Push your changes to your forked repo. Typically known as the 'origin' remote:
  11. git push origin bugFix-UTFencoding
    

  12. Log into Github and you should see a notification on your forked repo
  13. Click on the "Compare & pull request"

  14. Fill out the pull request, and then hit "Create pull request"


  15. Now you just wait on comments, requests, ridicule, or anything else. Once they are happy with your contributions they will "merge" your changes into their branch.

  16. Once its accepted you can delete that branch either through the Github website or at the CLI:
  17. git checkout master #it complains if you try to delete a branch you are on
    git branch -D bugFix-UTFencoding
    

  18. Now you can pull down the updated upstream to see your changes in someguy's repo:
  19. git pull upstream master
    

  20. If you'd like you can update your GH repo by pushing what you recently pulled down:
  21. git push origin master
    

Congrats on getting your pull request accepted and contributing to something. You will now feel slightly less like a leech.

Rinse and repeat lines 4-10 on the same project or the whole thing for a new project.

Bonus: If you want to pull down a specific branch from a remote upstream, you can easily do it with "git checkout -b up-master upstream/master"

Friday, March 23, 2018

Resume Your Script After Canceling It

Several times in the past I had to write a script that iterates over a dictionary file, or brutes something on a web login or whatever. Often you like to make modifications to the script forcing you to cancel it, edit it, and start it over. The starting over part is what I hate. It took me a while to realize this (I has the dumb) but you can easily create a resume-like function in your scripts. Just use a counter!

For example your original function is something like this:
for thing in things:
    result = haxor_the_thing(thing)
    print("{} resulted in {}".format(thing,result))

Which is your basic for loop in python, nothing new here. But lets say you ran that for a while and it outputted a couple hundred lines. You don't want to start all over again right? You need to make an edit, so you ctrl-c it, edit it, and also add in this little bit:
count = 0
for thing in things:
    if count < 243:
        result = haxor_the_thing(thing)
        print("{} resulted in {}".format(thing,result))
    count += 1

That's it. The "243" is just the number of times it ran and where it should start off again. So what happens here is the script begins, sees the count = 0 and doesnt run the "haxor_the_thing()" function. It won't run it until it sees a value higher than 243, thereby skipping the first 243 entries and restarting the function on the 244th entry.

If I have to cancel it again, I do a quick copy paste of the output, count lines in ST3, and just add "if count < 243 + 534:". This is obviously not the _best_ way to do this, but it sure as hell is fast.

I mean, this may seem obvious to certain people but this makes a person's life much easier.

Monday, March 19, 2018

Convert IP Notation - (X.X.X.X-X.X.Y.Z -> Individual IPs)

I was provided a list of IPs and ranges, most of them were in the format of 1.1.1.1-1.1.1.4. Nmap doesnt like this format, nmap likes the format of 1.1.1.1-4. This is easy if everything is a /24. Most of my ranges were not. I used the iptools python module written for Django to parse the IPs. All I had to do was supply a file formatted properly (no spaced in between the dash) and boom, each possible IP was spit out: