Both Black Hat and Defcon had hacking presentations that impact Manufacturers. I break down the areas of impact here:
Biometrics (mostly Trustzone exploits)
Android General (getting root on Android)
Car (covered mostly in another posting)
Most of the exploits used some form of Return Oriented Programming (ROP). I had identified this in a report three years ago as one of the most dangerous threats to Android security.
It would be good for the security teams to familiarize themselves with both ROP and JOP (Jump Oriented Programming) techniques.
SECTION 1: EVENT BRIEFINGS
Fingerprints On Mobile Devices: Abusing And Leaking
Tao Wei and Yulong Zhang
1. Confused Authorization Attack
The first vulnerability is that all the fingerprint frameworks are prone to the “Confused Authorization Attack”, which has long been overlooked. Authorization grants access rights to resources, while authentication verifies who you are. Security systems often mistakenly treat authorization as authentication, or fail to provide context proof for the authorization objects. Without proper context proof, the attacker can mislead the victim to authorize a malicious transaction by disguising it as an authentication or another transaction. For example, the attacker can easily fake a lock screen to fool the victim to think that he/she is “swiping finger to unlock the device”, but the fingerprint is actually used to authorize a money transfer in the background.
Currently the FIDO Alliance is developing the specification of secure authentication and authorization protocols for the mobile ecosystem. As FIDO describes in the specification : “Basically if a FIDO UAF Authenticator has a transaction confirmation display capability, FIDO UAF architecture makes sure that the system supports What You See is What You Sign mode WYSIWYS . A number of different use cases can derive from this capability EE mainly related to authorization of transactions send money, perform a context specific privileged action, confirmation of email/address, etc .”
FIDO’s specification requires that “the transaction confirmation display component implementing WYSIWYS needs to be trusted”. However, the original fingerprint auth framework has no reliable way to provide the authorization context proof. The framework with TrustZone can be improved to achieve this goal the Trustlet modules in TrustZone can be modified to provide the context proof , but so far June 2015 we haven’t seen any major vendor that implemented this feature.
We need to consider this exploit in both fingerprint and Iris scanning. It would be good to see if it can be executed on our phones.
I have the exploit code and can attempt to execute it against both our fingerprint sensor and Iris scanner. Let me know if you are interested in having me test this.
Exploiting Trustzone on Android
This presentation is referenced by Wei and Zhang. Shen shows that both normal space and TEE space can be compromised.
This presentation targeted an implementation of Trusted Execution Environment(TEE) used by Huawei HiSilicon.
A vulnerability was exploited to gain kernel-level privileges in normal world. Then another one was used for arbitrarily code execution in TEE.
It’s a proof-of-concept that any local application is able to execute shellcode in HiSilicon’s TEE.
These vulnerabilities affected all Huawei devices with Huawei HiSilicon SoC chipset.
Shen found a vulnerability in the /dev/tc_ns_client that allowed him to send malformed SMC (Service Monitor Call) to the TEE.
There was a bounds checking error in the driver.
Once able to write to TEE a syscall in RTOSck was used to patch code that checked if a process had rights to read the fingerprint sensor.
NOTE: This is particular to the Huawei chip and RTOS.
We should look at our Trustzone implementations and see if a similar set of vulnerabilities exist.
ANDROID GENERAL ISSUES
Fuzzing Android System Services
By Guang Gong
What Gong is able to do is get a System shell through MediaServer and SurfaceFlinger. He is able to bypass three important safeguards in Android:
NX (Non-Execute bit, blocking execution) Bypassed by ROP.
ASLR (Address Space Layout Randomization makes finding addresses difficult) Bypassed by leaking address information from Mediaserver.
SELinux (Strict Policies for process behavior) Bypassed by ROP and injection of executable code to get a shell.
The exploit process is outlined in the documentation at
StageFright: Scary code in the Heart of Android
By Joshua Drake
This exploit affects all Manufacturers phones going back to 2010.
Stagefright is a remotely exploitable software bug that affects versions 2.2 (“Froyo”) and newer of the Android operating system, and allows an attacker to perform arbitrary operations on the victim device through remote code execution and privilege escalation.
Security researchers demonstrate the bug with a proof of concept that sends specially crafted MMS messages to the victim device and in most cases requires no end-user actions upon message reception to succeed, while using the phone number as the only target information.
The underlying attack vector exploits certain integer overflow vulnerabilities in the Android’s core component called “Stagefright” which is a complex software library implemented in C++ as part of the Android Open Source Project (AOSP) and used as a backend engine for playing various multimedia formats such as MP4 files.
I watched Joshua use ROP (Return Oriented Programming) to get root on a phone through an MMS message. He was able to get a System level shell using the StageFright exploit.
From the System shell he was able to escalate to root using an exploit from an independent researcher.
Joshua is the main author of the Android Hackers Handbook. I have used some of his tools before.
CERTIFI-GATE: FRONT DOOR ACCESS TO PWNING MILLIONS OF ANDROID DEVICES
This presentation is on the way OEMs (like Manufacturers) use the signing capability in Android to allow third party apps to have escalated permissions.
The apps that Bobrov and Bashan looked at were RSTs (Remote Support Tools) that are downloaded from the Play store or ship on phones.
The research analyzed various RSTs to discover the method by which they gain privileged permissions. Once the method was discovered, a second phase was performed to find any vulnerability that an attacker could exploit to take unauthorized remote control of devices. During the research, the team found certificate verification vulnerabilities in RSTs from the following vendors:
Most of these have hardcoded certificate values that can be extracted and used to create an app with the same signature as the RST. This means that permissions will extend to the created app.
It would be good to look at the way we sign apps that ship on our phones. We need to check if there are hardcoded values that can be used to escalate permissions.
I will cover the car hacks in a separate posting. There are several lessons that OEMs can learn from all of the exploits that have been done against cars in the last several years.
I saw a Tesla hacked through very simple investigation of the Tegra board under the dash. The hackers just poked around until they found the keys stored in memory and used them to authenticate to the system.
What Charlie Miller and his friend did was investigate the vulnerabilities in many vehicles over about three years. Their knowledge helped them to hack several models of Chrysler cars including Charlies own Jeep Cherokee.
I also saw that remote keyless entry (RKE) could be hacked using timing attacks and some math optimization. This also applied to garage doors.
RECOMMENDATIONS FOR IMPROVEMENT
1. It is recommended that we check the CVE database to see the issues before they are headlines.
2. It is recommended that we have a team actively looking at exploits and trying to use them against our devices.
3. It is recommended that we build security into the Software Delivery Lifecycle.
4. It is recommended that we have a “bug bounty” system that rewards employees for finding problems before we launch our software.
5. It is recommended that we run static and dynamic analysis against our code base to find vulnerabilities.
6. It is recommended that the security team attend security conferences where there will be disclosure of exploits that affect our products.
7. If members of the security team cannot attend conferences they should order the videos and download the white papers from the conferences.
Brief Car Recommendations:
1. It is recommended that Security be a part of the development of any car subsystem.
2. It is recommended that someone be in charge of security for car subsystems in Manufacturers business units.
3. It is recommended that there be a security team working on security issues in car subsystems.
4. It is recommended that the team have the necessary tools and training.
5. It is recommended that the team have a mission to find bugs that can become exploited.
6. It is recommended that the team help design security into the products.
7. It is recommended that the team is always looking ahead to discover problems before they become recalls.
Android has many vulnerabilities that are being exploited by hackers. Manufacturers have a responsibility to catch these vulnerabilities and make it difficult for them to be exploited.
Many of this year’s vulnerabilities were known before Black Hat and Defcon. It would be good to check the CVE database to make sure we see what problems before they are headlines.
1. Trustzone is not as secure as it should be.
2. Root is still too easy to get on Android.
3. NX, ASLR and SELinux all have bypasses.
4. ROP and JOP are effective and dangerous techniques.
I will address the car issues in a separate document.
Nepal Reflections Update (May 17, 2015)
My brain hurts…
We had some visitors to Runway to discuss the Nepal situation. Tasaka-san from the Consulate General’s office in San Francisco and his friend Ichikawa-san dropped by to discuss what Japan could do to help in the efforts to rebuild Nepal.
Tasaka-san and I had met recently and we had been planning on having lunch together mostly so that I could practice my Japanese (which has gotten pretty bad since my crew from Fujitsu has gone back to Japan and I don’t speak it that much now). I hadn’t heard from him and assumed that he was busy so it was nice to see him again and try to set something up.
So, Tasaka-san has indeed been busy. The Prime Minister of Japan was visiting recently and Tasaka-san has been working around the clock to support that visit. To put that in perspective, it would be like me saying “sorry about not calling to have lunch, but Obama showed up and I have been busy…”
But now to his friend, Ichikawa-san. Taiki Ichikawa is from Sendai. You may recall that this is the place in Japan that took the brunt of the earthquake and tsunami four years ago. Ichikawa-san has been very involved in helping to rebuild Sendai after the quake.
He has helped to form Social Entrepreneur groups in Sendai and fund projects to rebuild the area. He has also been involved in fund raising efforts for the region and helped to start an Innovation Incubator where Social Entrepreneurs can work on projects in the Sendai area.
Ichikawa-san spent several hours working with us to go over the lessons he learned in rebuilding Sendai. Most of what he presented was in Japanese but Tasaka-san translated.
I was able to barely follow along for most of it, but frankly, the discussion and vocabulary were a bit above my level. Thank goodness for Tasaka-san translating because my brain hurt trying to understand what Ichikawa-san was saying.
We are incredibly fortunate to have a person with the experience and insight of Ichikawa-san. And it is equally impressive for Tasaka-san to patiently translate the important ideas and lessons being expressed in the meeting.
It seems clear that people in Japan, and in particular, Sendai will understand what the Nepali people are going through. I am impressed with the generosity of these people after coming back from a natural disaster like the earthquake and tsunami they experienced.
It is now up to my Nepali friends to put into practice the lessons of Sensei Ichikawa as they begin the long road to rebuilding their country.
For me, there is a promise of lunch all in Japanese so I need to study, study, study. 勉強します, 勉強します, 勉強します.
Nepal Reflections Update (May 9, 2015)
I thought I would summarize our effort at Resource Nepal to link blood donors to hospitals in the Kathmandu area:
Nepal Reflections Update (May 7, 2015)
Here is a small piece of information that came out of a recent analysis I was doing of the Tweets from the Nepal Earthquake. The usual work I do with these Tweets is mine them for pleas for water, food, shelter and medicine but after turning this activity over to volunteers, I have been looking at some of the patterns of Tweets to show how some people are becoming aware of the disaster.
I was able to grab about fifteen thousand tweets in a period from May 6th to May 7th with the hash tag #nepalearthquake. I was looking at who would serve as somewhat of a gateway for information about the quake generating a storm of Tweets that would make the issues more widely known in the ‘Twitterverse’. What I found is not necessarily surprising, but I didn’t expect to see this particular Twitter account as a single node in a graph of fifteen thousand.
Using GraphML and Twitter scraping and Node tools I have been getting some interesting information from the Tweets about the Nepal Earthquake. As mentioned, I have been mostly interested in personal needs and the needs at shelters and hospitals in the Kathmandu area. When you pull the Tweets into a graphing package you get what I call a Twitterverse.
This pattern shows the nodes and edges related to the content of Tweets that we may be interested in. Zooming in you begin to see interesting patterns as well as hubs, spokes and clusters. Your eyes naturally go to large clusters like the one to the left.
With a hub like this single node connected to the large cluster you can begin to see that if there is a mover and shaker in this view of the Twitterverse it is this one point. So who could set off a storm of Tweets, the Red Cross, UN, even the Wall Street Journal?
No – think more Boy Band.
The Tweet in question that pretty much leads to the expanding nebulae of messages in the above Twitterverse is from the account of One Direction.
Nepal Reflections (May 2, 2015)
[Warning, this ain’t 140 characters]
As a Technologist and Engineer, I wanted to pen something about my experiences this past week working on the relief effort of the Nepal Earthquake. My involvement in this activity actually started about a month ago when my friend Bijay from Nepal (a Nepali professional working in the Bay Area) invited me to meet Apa Sherpa at the Runway start-up accelerator in the Twitter building in San Francisco.
As a mountaineer from Alaska that used to do Alpine Style climbing (fully loaded, no Sherpa, light Oxygen), I have always admired what the Sherpa have been able to do. These guys have been my heroes since I was very young and I have tried to emulate them as have my fellow climbers of like mind for most of our mountaineering careers.
Apa Sherpa is really one of the most amazing climbers and individuals I have ever met. He has climbed Mount Everest more times than anyone and has dedicated himself to helping underserved children in his country of Nepal. He also is active in many projects that benefit his country.
He recently trekked with a Google team to do street maps and trail maps of Nepal and capture some of the rich culture of the country. The work this mapping team did was released publically just weeks before the quake and can be seen here:
I am honored to have met Apa Sherpa and to have had the opportunity to spend time sharing stories with him (his were by far more interesting than mine). He inspired me to get involved in some of the efforts of his foundation and so I had been talking with members of the Nepali community in the US to see if I could help with some efforts they have going in Nepal.
One of the efforts that interested me was the amateur radio project to put repeaters throughout the country in case the telecommunications infrastructure was damaged in an earthquake. As a licensed amateur I had helped with a similar effort in Alaska as a radio operator in both base camp mountaineering and mountain rescue work.
So just ahead of the disaster, the stage was set for my involvement.
Fast forward to the Saturday morning after the earthquake. That morning I was going to be totally selfish as I had woken up with the plan to finally begin posting again to Facebook and update my Linkedin profile that had been neglected for way too long and catch up on Tweets.
This was not meant to be, however, because the very first thing I saw on my computer after logging in was news from Nepal about the devastation caused by the earthquake. I immediately called Bijay and he conferenced me into his call to the professional network responding to the event.
By the time I got off the phone I was spearheading the GIS/Mapping tasks for the group working to put data on a map to give workers in Nepal an idea of what the needs were on the ground. I was also tasked with finding resources coming from people all over the Kathmandu area.
Many people from Google began to get in touch with the group I was working with that day and they jumped into Google Hang Outs to lend resources and support. Through people in the network of Nepali professionals in the initial working groups I was able to find some sources of information coming right out of Nepal.
To have a place to post and vet the information we were receiving, we put up a Google Sheet with tabs for Water, Food, Shelter and Medical and opened it to people in both the US and Nepal. As the information began to come in we would find the location of the people and get the pin on the map to show where they were and what need or supply they had.
This was crude but successful until we could hook into other efforts. So our first attempts were to fill in the sheet and use a My Map in Google Maps (personalized map) to show what was going on.
I went searching for more meaningful data and found the map the Nepali government had used to plan for disaster recovery. It had predetermined staging areas and resources so I took this as a layer and built on it using the information coming to me from the sources in Nepal.
Early on Saturday I was told about the Google Crisis team and I attempted to get in touch with them through some of the Googlers I had met from the Nepal mapping expedition with Apa Sherpa. They passed my information along to the team and I began looking at the Google Crisis Map API.
As a geek, I want to get the most out of what I am using so I was impressed with what the Crisis map could do. Unfortunately the beta wasn’t publicly available and I hadn’t heard back from the Crisis team so I jumped into the personal map and had it posted on several prominent Facebook pages and a Google group where I found an old map that contained stale data and had the moderator switch out our map for the old one.
“And evening came and morning followed, the first day….”
On Sunday morning I woke up early (those who know me are aware of the fact that being from Alaska I have no circadian rhythm and sleep about 5 hours a night) so the gap between Saturday and Sunday was brief. Opening my email I was a little stunned to see a plea from a guy on a remote mountainside in Nepal that needed a tent.
Somehow, and experiences throughout the week bear this out, Google Docs and Google Maps leak enough personal information that even some guy on the side of a mountain in Nepal can figure out and use (note to self, talk to Google Security team next time I am on the campus about this). So I went looking for someone that could help this guy. I mean, earlier in my life that could definitely have been me out there so I really want to do something.
But how can a guy in an office in San Francisco help a someone stuck on a mountain in Nepal? Well, I had begun to here of some grass roots information gathering efforts in Nepal and I decided to check them out to see if someone was doing what we were attempting in the US. This led me to a gold mine of data put together by the Kathmandu Living Labs project (KLL).
These guys had used Ushahidi, an open source crisis management tool, to take reports and do Open Street Maps of the areas where the reports came in from. They accepted needs requests, notifications of supplies in certain areas and incidents like building collapses and road blockages.
I saw that I could input the needs of the person that had contacted me and those that we were getting from people in Nepal as reports in KLL’s system. We could also start directing people in Nepal to go to the site and enter reports themselves.
It was on Sunday that volunteers began showing up and helping out. We began putting people to work to scrape social media (Facebook, Twitter and others) for pleas for help as well as resources that people in Nepal were making available.
These were not only entered into the KLL portal but individuals were texting friends to help in the effort to take supplies to people in need in Nepal. We began to realize that there was enough connectivity to be very affective in coordinating individual efforts for helping people.
An entire network of Nepali people in the US was contacting people in Nepal and coordinating needs. This is about as grass roots as it gets.
Our next area of effort on Sunday came about when the Medical Team of the Greater Nepal Professional Network and the American Nepal Medical Foundation tried to put together a form for getting the needs of hospitals in Nepal. I suddenly found myself in a Google Hangout with a PhD candidate from Yale and a Harvard professor going over the questions that should be used on a form for doctors and hospital administrators to fill out.
Now, most of my experience is with emergency medicine as a mountain rescue medic and trauma tech on the volunteer fire fighter unit of the Juneau Fire Department. I think in terms of blood, bandages and drugs.
As a geek, I am also thinking that we need to be able to get the data from the hospitals and put it into a dashboard that NGOs like the ICRC (Red Cross) or USAID can use to quickly triage the needs of clinics and hospitals based on the information. So, as a geek/medic I am wanting to have a label/number when it comes to data.
An example need would be “Blood: AB+ = 200 500ml bags”. But, it was decided to be more general so we ended up with unstructured data in a field with the question “What blood do you need”. I would be able to revisit this later with a more detailed form but we put out a questionnaire to a list of hospital emails that we had.
Once again, we used a Google Form with a spreadsheet backing it and I used GeckoBoard to do the first basic dashboard implementation. We sent this out late Sunday night as the sun was coming up in Nepal and I took my rest.
I wake up Monday and go into Runway where I am a Mentor. I am joined there by my friend Bijay (who works for the parent organization of Runway) and we begin to organize a group to begin working on vetting all the information that is coming into the KLL site as well as the data we are scraping off of social media.
I open the Google Sheet backing the Hospital form and find that half the hospitals that we reached out to have begun to respond to us. I begin to see some of the reports about deaths and injuries and few hospitals were seeing less than 100 deaths.
Most hospitals are reporting many hundreds of traumatic injuries and the medic part of my brain begins to do the calculation on the fact that the numbers in the traumatic injury column will shift to the deaths column as the week progresses. It is a sad truth but efforts on the ground in a crisis like an earthquake are limited due to many factors and injured people frankly die from otherwise non-lethal injuries.
We are now seeing just what the needs are at major facilities around Kathmandu. Blood, drugs and trauma kits are in high demand. Now, how do we get these hospitals what they need?
We decide to input our data to the KLL system and put a call out for any data on blood donors in Nepal. Shortly, our queries are answered by a list shared with us that consists of volunteer names, phone numbers and blood types.
We mobilize to target these individuals and get more data on them so we can get them to the hospitals that we know have a need. We put up yet another Google Form to have the volunteers give us location data and what transportation they have.
We verify their blood type and ask them if they are willing to be our eyes on the ground. This final plea has to do with us deciding that we need more detailed information on the needs of hospitals. What better person to ask to find out what a hospital needs than someone going to the hospital to give blood.
Monday night we put together the form online, and texted all the volunteers on the list to go fill it out so that we can determine where to send them. And off to bed I go for a few hours.
Tuesday I get some GIS help. A PhD graduate back east that is on round four of a marathon interview cycle with Google is going to take time out to help with the mapping. Robin is a very capable individual with some serious chops in mapping.
I am talking grown up maps in ArcGIS/ESRI with a deep understanding of spatial concepts and building everything from scratch. My initial concern in working with him is not his lack of ability, but his depth and breadth of understanding that could lead to over engineering when we are in, frankly, quick and dirty mode.
This turned out to be unfounded as a concern, because Robin quickly began turning CSV data into KML and allowing us to greatly expand our map layers with useful data. He also customized the layers and divided up the information making it more useful for people on the ground.
But what about his interviewing gauntlet this week? Google, being the awesome guys that they are, allowed him to take the week to work with us and support the effort in his native country before being put through the ringer in their interview process.
Tuesday starts with opening up the Google Sheet that backs the volunteer form to find that every single volunteer has filled it out in detail. Some of them agreed to be our eyes on the ground and some of them even have trucks and are available 24/7.
With the volunteers ready and willing to help we now need a more detailed medical form so a call goes out to the Nepali community in the US to get a doctor to help us with this. Answering that call is an endocrinologist…Okay, to be fair, she has extensive trauma experience.
She begins to work through our original form and fill in detail on the questions. I begin to work with her and we start to have the label/number data that will nicely roll up into a dashboard for aid workers.
I am very glad for her input because as we were going through the form she would remember to include things that I completely forgot. An example would be Dextrose. I got Saline and Epinephrine but completely forgot that maybe people injured who were without food might need a jolt of sugar. It has been a while since I have had to think about such things.
As the medical form began to take shape, we began to think about how we might make it easier to get the volunteers to the hospital and include the link to the form in the text that we sent them. We first thought of just using Google Maps to show the hospital near them but we then took a look at what one of the startup companies in Runway was doing with their mapping technology.
MapJam makes customized maps for events and people interested in easily putting more information into their maps that they distribute to friends and attendees of conventions and other activities. These guys were doing some very cool work and I wanted to include them in the mix.
The CEO, Jack Gonzalez, is a very dynamic individual and I knew that his energy and input would be welcome in the team that we put together. It took a few days of back and forth (frankly because we were so busy with the other efforts, Jack was ready to jump right in) but we were finally able with much persistence on Jack’s part to get something put together.
So, another unsung hero in all this is Jack’s business partner. Here is a guy on a business trip to Pittsburgh that along with generating about twelve hundred maps for a customer, took the time at nearly two in the morning, to generate maps for each of the volunteers.
Here is how the MapJam technology works. We were able to put an interactive pin on a map showing the hospital and linking the card information to the hospital information along with our links to the updated medical form. It was optimized for the low bandwidth of our volunteers and allowed us to eliminate a gnarly URL for the map in our text.
Since MapJam is so adept at optimizing their maps, we were able to deliver a mobile version that even someone in Nepal could see on their phones. This was critical to our operations and we really appreciate their efforts.
Now enter the efforts of Kishin. This guy hit the ground running and anyone would be glad to have him working for them. Not only did he come in and get the resourcenepal.org website up in an afternoon, but he manually texted all the volunteers in the first round we sent out.
His contribution for the second round was writing a Twilio (the online texting service) script to get all the texts sent dynamically to the volunteers in Nepal. He was able to get links embedded in the scripts so that we could get the detail medical form to the volunteers, however this was not without its share of pain.
About one in the morning Kishin is working to get the text script done when I realize that the doctor is still editing the form and I may have also sent him a link to the draft version. I go digging through my emails and find that indeed, I sent him the wrong link.
I text him and email him and we finally get on a texting string where we are going back and forth attempting to finalize everything. It is approaching two in the morning when Kishin makes a discovery that changes everything.
After writing the Twilio script he looks over the phone numbers provided by the volunteers and discovers that most of them are land lines. Really? Land lines.
We had asked for email and social media contacts like Facebook and Twitter accounts so we had (or more accurately, Kishin had) to send each request to the individual email and Facebook/Twitter accounts.
The days run together at this point so I am not entirely sure of the order of events.
There comes a time in every SCRUM Sprint where you just have a day when nothing seems to get done. It is not actually the case because progress is being made, but is seems like all that the things you are wanting to accomplish just don’t seem to be getting done.
It also appears that everyone is off doing their own thing and you are not sure what it is or how it fits into the big picture. This is why you have stand up meetings and update the progress on the sprint, etc.
Thursday turned out to be a day when the portal site got mostly up and the volunteer texts almost went out and the hospitals got connected to some but not all of the resources we were working to get to them. However, it was a day of little triumphs and some great work by people in the US coordinating with people in Nepal.
“If you want something done, give it to a busy person….”
It should be noted that during this time I am writing the last of some OCR code on Android for an app for the blind that is being released during this same week into the Google Play store. I am also deploying a server for some colleagues in Japan for a disaster response person finder application that I wrote for Fujitsu that needed to be moved off of my private cluster and on to their cloud.
To add to this I am also digging into some of the ugliest Android email code imaginable on a project and doing a daily 7:30am Scrum call with a development team on the East coast. I am also Skyping Germany on an indoor navigation project using Bluetooth Low Energy for Runway.
So I have spent the week on Boston, Japan, Germany, California and Nepal time.
I do okay with this schedule as long as I get my morning macchiato and bagel. There is also an ample supply of black coffee from several coffee roasters in the lounge at Runway so my old school addiction, caffeine, gets me through the day. However, everything seems to go wrong at two in the morning which is the latest I should hit the sack. Go figure.
I need to do some praise singing for some true heroes in this first week. KLL has done an awesome job of pulling together a great deal of data in the form of individual and institutional requests and reports. You can think of them as the Craig’s List of the Nepal Earthquake and we do describe them that way.
Well, if they are Craig’s list, who are we? I like to say Match.com. Bear with me on this one. If you go into the KLL site, you will see lots of posting that is very informative. What we are trying to do is match those postings with people that can fulfill needs on the ground in Nepal.
We are matching volunteers with hospitals, clinics, shelters and even more commonly, individuals that have a need. We are culling through the data to link up water and food with camps and people in need in the same geographic area.
We are working to be on top of the situation when it comes to hospitals and their needs and, indeed, we are providing Situational Awareness to workers on the ground seeking to understand and help these facilities serve the needs of the victims of the quake.
So, interestingly, up until Friday there is not a single line of compiled code that has been written (on the US side) to accomplish all that we have done. Yes there has been some scripting for Twilio and I have written some OSINT (Open Source Intelligence) scripts for scraping Facebook and Twitter, but there is no Java code or even PHP written in support of our efforts.
For a geek like me, that is both amazing and frustrating at the same time. I mean I know that the KLL guys are modifying PHP and MySQL along with a lot of Open Street Maps code to provide a reporting platform to cope with all the needs and incidents that are going on in Nepal. We in Silicon Valley, however, are an enormous amount of work done with simple tools freely available to anyone, Google Docs, Google Forms, Google Maps, Twilio, GeckoBoard and others.
This is partially due to the fact that most of the people helping us are non-technical and that time has been a major factor in everything that we have done. This, however, was about to change in a very good way.
“Enter the Devs…”
The first contingent of Devs arrived on Friday and we did a Product Backlog that actually contained some tasks involving code. We had guys from SalesForce.com and several start-ups jumping in to put it out to their networks that we needed help. We also did a call with Carnegie Mellon at Moffett Field in the Bay Area and got the interest of a professor and his students.
Saturday had the Devs in full force coming in to tackle the discreet problem of getting blood from volunteers to hospitals. It was a joy to have a guy show up with a fully formed idea in his head that we could turn into programming tasks on the backlog and start a real Sprint to get things done.
Suddenly we had Slack for communication among the development team and lively debate about the merits of using Github over BitBucket (I learned that BitBucket is quite robust and has some features that are desirable but that Github is the weapon of choice for development). I hit Github about seven or eight times a day so I had to concur with this decision, but it is always good to find out something new about a service like BitBucket for future reference.
The web technology was basically chosen as Rails (Ruby) and the database was a real one, PostGres. Heroku (interestingly, owned by SalesForce.com so I believe a discount should be in the offing) was chosen as the hosting platform and we began to migrate the forms into Ruby and deploy them to the cloud.
The interesting problems in the mix was providing a form for volunteers in Nepal, similar to the one we did earlier, but with the added functionality that you could give us your available radius (polygon) on a map and we would give you the choices of hospitals that fall in that radius that match a need for your blood type.
The additional step of having the texting as automatic based on the form completion and we finally close the loop on accountability with a text that they reply to when they are done that hits a restful service logging completion of the task.
The radius generation presented some challenges. Finally, a programming problem. There were simple approaches to solving this problem presented by the developers and some sophisticated ones, but I think we will sort this out in due time and greatly improve our ratio of volunteers that actually go to the hospitals and give blood.
They are also tasked with getting much needed data from hospital administrators and doctors on what the hospital needs.
The next big task is a Crisis Trouble Ticket system to track exactly what volunteers are getting done in Nepal and what supplies and services are being delivered.
I am sure I will write more on this subject and try to address how this could all be formalized into a sort of ‘Lean Crisis Management”, but for now, well, it’s two in the morning and time for me to get my few hours of rest before starting day eight…