Saturday, January 21, 2017

Kano review

Below is a quick review of the Kano computer.

WTF is it?

The kano computer is a raspberry pi based computer that is meant for kids to put together and build themselves.  Looks a bit like this:

propaganda video:

It ships with a nice guide that most kids will be able to follow to get the piece of the Kano computer up and running.  Optionally you can also buy a screen kit where everything can fit all together in a tidy package. The screen kit that houses the raspberry pi and and keyboard is the reason I went with the Kano over just piecing one together for the kids.

Once you get the hardware set up, the KanoOS walks you thru setting up a user account and starts off in story mode where you start off on SD beach and get to explore your computer in a RPG type environment.

You also have menu for kids where they can pick what they want to work on but also has a classic button if you want to get to a more normal Linux experience.

Not shown in the screenshot but definitely present in the menu now is a link to Scratch which this kids love. And of course no computer for kids cant not ship without Minecraft:

The OS is designed to get the kids to go through various quests to learn about the computer and as you complete quests more open up to you. More info around this is available on the Kano developer blog:

The Kano OS is available here:  if you want to throw it in a VM or raspberry pi you have around the house. It is also open source so you can contribute:

The Kano world portal also has fun stuff 

As an added bonus Kano has been sending emails for the kids to experiment with stuff. 

This week's "Secrets of the Computer Kit" included an introduction to the Linux terminal and cowsay!

cowsay, with some Scratch on the other Kano

The kids also got their first real Linux experience by the screen flipping and it still being flipped after a reboot.  We eventually found an option in the menu to flip it back but it was a nice introduction to the hell that is running Linux...good times. Enjoy Linux hell boys I'll be here to help you <3 .="" p="">

Overall extremely pleased.  

Two negative experiences though:

One was the first upgrade process.  It took over 30 minutes to download all the updates. I ended up losing the kids for the nite during that process due to it taking so long.  

Second was the fact the computers showed up one day and the monitors the next!? WTF. I realize Kano doesn't have control of all things shipping but it was a real PITA to have computers and no monitors.  Suggestion: bundle kits should ship together.

Aside from the above, the kids have been enjoying their new computers.

I know it's coming so i'll just address it here: 250 bucks for a raspberry pi?!  Yeah kinda steep...but I did price something comparable out before I bought. Here is what I came up with:   Pi Foundation Display - 7" Touchscreen Display for Raspberry Pi  $79.95  Pimoroni Raspberry Pi 7" Touchscreen Display Case - Noir  $14.95  Pi Model B+ / Pi 2 / Pi 3 Case Base - Clear  $5.00  LID 3.00

SD CARD 32 GB various $10-$20  Full Size Wireless Keyboard with Trackpad  $39.95


Speaker:  ?? 10?

Misc cables to hook it al up ?? 20?

Total ~ $180

or  Pi-Top - GREY - A Laptop Kit for Raspberry Pi B+ / Pi 2 / Pi 3  $274.95

None of the above with the exception of the Pi-Top fit nicely together, I'd end up having build it for the kids and I wanted them to build it themselves.  Plus the Kano comes in fun colors with stickers so they can make it their own.  I'm satisfied with the purchase but you could technically do it for the price of a raspberry pi and SD card if you have the other gear laying around.

In a similar vein is the Piper computer if you are considering things for kids:

Wednesday, January 18, 2017

DevOoops: In-Memory Databases (Redis) Part 2

Doing part 2 first as the altcoin mining stuff is interesting with the mongoDB/elasticsearch ransomware stuff currently going on.

A redis developer dropped an interesting piece of info here

“However, the ability to control the server configuration using the CONFIG command makes the client able to change the working directory of the program and the name of the dump file. This allows clients to write RDB Redis files at random paths, that is a security issue that may easily lead to the ability to run untrusted code as the same user as Redis is running”

He goes on to show how someone could echo over SSH keys and use the config command to write them to the appropriate place if you have permissions.  He used a key name of "crackit" so I thought I'd see how prevalent it was....I checked a few and saw it a good chunk of them.

go go shodan

I did find something interesting while looking thru some open redis boxes.  I found:

A cron job? running a shell script. Can you do that from Redis???

What's in the shell script?!

alt coin mining! sweeeeeet.

I had no idea what an XMR is but I wanted to see how this person was doing with the money making. Thankfully you can just query the payouts for any XMR address. So I did:

They've made around $20,000 USD in BTC. I guess crime does pay :-)

To satisfy my curiosity started a miner up on a linode and was getting around 60 H/s. This person is cranking out 70 KH/s, so they have a few boxes working for them.

Extending the idea that a good hack yields plenty more I stumbled across this gem. with several different ways to get code exec on redis.

I created some gists from the previous link in case the post disappears.


Monday, January 16, 2017

DevOoops: Client Provisioning (Vagrant)

Notes from the 2015 Devoops Talk

Vagrant used to ship with a default keypair and was difficult to rotate.

**fixed with new versions of Vagrant. Finding hosts using the default key still pretty likely.

Did you change your SSH keys?

Default Credentials

root/vagrant  vagrant/vagrant

No pass to sudo :-)

Scanning for the default key using metasploit (ssh_login_pubkey module)

Identify real from fake by ssh version scan

Log in with private key

Friday, January 13, 2017

DevOoops: Client Provisioning (Kickstart Files)

Notes from the 2015 Devoops talk. Posting it so i can remove it from the slide deck but still refer to it.  Also relevant from a common problems with devops theme.

Kickstart Files

3 ways to set root password

1. Enter during installation

2. Crypted hash in the kickstart file
“rootpw --iscrypted”

3. Clear text in the kickstart file
“rootpw --plaintext”


 Kickstart Files Takeaways

Don't leave these files in open shares

Use the crypted password option for files

Have a process to change the password after initialization

Rotate the initial root password regularly

Thursday, January 12, 2017

DevOoops: Client Provisioning (Chef)

Notes on Chef from the 2015 Devoops Talk. Posting it so i can remove it from the slide deck but still refer to it.  Also relevant from a common problems with devops theme.

Chef allows you to define the state your servers (local or cloud) should be in and enforces it.

Web Interface

Environment Leakage


knife is a Chef command line utility. The credentials are stored in data bags. Credentials can be encrypted.


$ knife data bag list

Chef/knife (encrypted data bag)

Chef/knife with path to secret file

Chef Takeaways

Be aware of what you put into chef recipes

Protect secrets/passwords

Info on securing chef:

Wednesday, January 11, 2017

DevOoops: Elasticsearch

Notes from the Devoops talk on Elastic Search

Elasticsearch Provides a distributed, multitenant-capable full-text search engine with a RESTful web interface and schema-free JSON documents.

*GET request to port 9200 will show version
"version" : {
"number" : "1.2.4"

No Authentication (initially)

Can search stored data via HTTP API

Update data with PUT request

Join an open cluster and receive all data

RCE prior to 1.2.0 (CVE-2014-3120)
RCE prior to 1.5.0* (CVE-2015-1427)



Searching via curl/browser is cumbersome...Kibana FTW

Edit config.js to point to open Elasticsearch

Open index.html in local browser or host on a server

Viewing the content of the document

Import your own data and visualize

Elasticsearch solutions:

Apply authentication if possible

Segment elasticsearch from Corp (and the public in general)

Be aware of the data you put in elasticsearch
-->anyone can search it

Logs Logs Logs


Tuesday, December 20, 2016

Hacking Complex Systems

Back in the day, you could download a piece of software, reverse engineer / fuzz it, find bugs, notify the vendor, post on Full Disclosure, watch a patch come out, and move on to the next bug.

These days systems have become very complex. A system might include:
  • A HID (Touch screen, keyboard, other devices)
  • Data Inputs (USB key, Bluetooth, Wireless, Satellite, Cell)
  • Firmware (BIOS or other embedded aspects)
  • OS
  • Applications (both OEM and 3rd party)
  • Media Servers
  • Other control systems
  • Telematics interfaces

This collection of components may be very expensive, on the order of 250k in some cases, or say 10-20k for a car. These components may be made by multiple different vendors, all with NDA's and MSA's between them.

This whole system is then certified and tested by numerous bodies such as FAA, TSA, NHTSA, NAFTA OEMs, Avionics Manufacturers such as Boeing and Airbus, Airlines, etc. There may be regulations and requirements around patch cycle timing, disclosure, and legal.

How in this context, can these systems be tested for security issues in a reliable and effective manner? Right now there are several ways this testing occurs:

1.) Via Testing Contracts.

The vendor puts out a bid or otherwise engages a 3rd party security company to test the system. NDAs and MSAs are exchanged, access to the system is provided, testing performed, and results delivered. Fixes are developed and pushed out according to the schedule and requirements agreed upon by all the organizations outlined above.


Vendor has a level of protection that their reputation won't be tarnished via media disclosures, their IP stolen, etc. Vendor has some assurance the testers are competent and there is a level of service expected.


This process is not public and people outside this framework have little to no insight into what is going on, how testing is done (or if), who is doing it, what fixes have been put in place. etc. This also limits the number of bright people who can see and test the system, almost ensuring that some bugs will be missed.

2.) Bug Bounties.

Vendors make some aspect of the system available publicly for anyone to test and pays a bounty for valid vulnerabilities discovered. In some special cases the vendor may make an entire system accessible for a limited amount of time. (Time limited to offset the cost of the system)


Process is public and many eyes are on the product. Raises the exposure of the product to new testers and approaches. Builds a level of trust in the vendor and assurance that the vendor "cares about security".


Costs the vendor time and effort and often produces little more than noise, or bugs already known about through internal testing. (I'm basing this on my personal discussions with vendors in the real world). Testing quality is often very low. Often the holistic system cannot be tested in this way, only components.

3.) Rogue Testing.

This is sort of where I came up in the industry initially before moving more into 1.) above. The way this works is that a researcher (or team of researchers) and/or a security company gain access to a system in some way. Examples include buying a piece of the system on eBay or in the case of publicly available systems such as avionics, testing it live. A car could be bought as well. This is sort of a black box approach as access to all the back end systems, telematics, source, .etc. will not be available.


A researcher can sort of do whatever they want without constraints. A security company can leverage this for media attention (marking / sales), and it drums up interest for conference talks. Real bugs are found this way and the vendor is technically notified, either as a heads up by the finder or via the media.


No trust is developed between the vendor and the bug finder. In fact the relationship is almost always adversarial by its nature. The public receives an unclear picture of the true threat. Do they trust the finder who is often over hyping to get attention or do they trust the vendor who has a material interest in under hyping and disproving the bug.

I'm sure I am missing other pros and cons to each of these, so please feel free to send me ideas. I'm also sure there are other approaches to testing which is why I am making this post. Here are some questions to consider:

  • Are complex systems such as avionics and automotive substantially the same from a testing perspective as windows hosts or endpoint software?
  • Is live testing on a passenger vehicle really the right way to do security testing?
  • Should only professional security companies with contracts in hand be allowed to test?
  • Are bug bounties in their current incarnation really effective for these types of systems?
My answer to the above questions is probably no.

I propose that we, the security community, collectively try to come up with a better way or framework for doing this. Any ideals will be appreciated and considered. Are you already doing something in this arena that is better than what I have outlined? Is there something you thought would work but have not gotten traction on it?

I'd love to hear from vendors, sec companies, and researchers alike.

I also propose that unethical behavior in our industry be called out. Every time a company brushes up against extortion, over hypes a bug, or claims credit for non-employee's work, just for short term sales, it damages the credibility of all of us and makes our jobs harder. Lets require the best of ourselves. Security has become huge, and is about to become bigger. Over the last year think how many times hacking has been in main stream media. Now contrast that with 10 years ago. This is an industry that is about to explode. Do we really want to be found wanting when the world finally is ready to take us seriously?