KiwiCon is the annual hacker conference in Wellington NZ. This year it became KAWAiiCon to reflect Sput taking over the lead from Metlstorm. Below are the notes I took for the sessions on Day 1.
These are very much notes to self, but might give others a reminder or a prod so I've decided to blog them.
Hey Look Ma, We Made It
Runa Sandvik @runasand
Interesting talk on path into the industry and some of the challenges of running security for a newsroom.
In this industry we've bee able to create the jobs we want
Some surprising similarities between journalism and hacking, work out how things work get to the bottom of things etc
Needed to get to know the journalists, ran phishing campaign, published results by desk created competition between desks which got the conversation going.
Deadline driven, cannot bock the story
If they can't do it without your assistance it's not going to work
Problem with the perception of work / life balance vs confirming to expectations on the life you should have
Is what I'm doing now inline with what I want to achieve? Then it's fine.
Automotive Control Systems Security: Where and I going and why am I in this handbasket?
Interesting talk, summary is that automotive engineering is all about dependability, i.e. fault tolerance and continued reliability in the face of faults. Also need to look at the economics, where's the money coming from for car-hacking? Nowhere. So crypto is the wrong answer. Access control is good and should be done!
Car should be thought of as a distributed control system made up of a lot of different micro-controllers connected to the "head unit" which is the stereo etc and the driver controls.
The real hacking risks come from the head unit which is complex, runs Bluetooth and other stuff. Runs Bluetooth at high power because we don't want audio drooping out so range is actually quite high.
Dependability is the critical aspect in automotive, that a fault doesn't propagate into an event and cause a failure, need error boundaries, double checks and recovery strategies.
Cryptography has the opposite properties, we want a single bit fault to cause complete failure.
What's needed is access control, Head unit should have read only access to the control system. Limit to what's actually needed, use data diodes and similar techniques
The economics of car hacking for profit don't stand up:
- Nuisance crimes like deleting a playlist == no money
- Ransomware, takes to long to get the money, people will take to the dealer and reflash == no money
- Messing with breaks etc, must be in the locality, not remote and is murder / attempted murder in the same jurisdiction that you're actually in. Risk profile is too high for people wanting to make money.
Endpoint Protection - Don't Believe Everything You Read
Lidia Giuliano @pink_tangent
Interesting talk on how Lidia performed her tests of various EDR solutions that resulted in her "damn lies" talk at blackhat.
A trigger was comment from vendor that installing EDR on the file server and not on the client machines would prevent ransom ware (wrong).
Much of the focus from vendors and customers is on the tech, Need to focus on:
- what you need vs what you want
- your requirements, not a big feature list from the tool
E.g. think about what OSes your actually running. Do you have legacy systems on old windows? EDR solutions probaby wont run on those.
Went into quite a lot of detail on the tests, interesting bits I noted:
- Malware runs differently on different virtualisation so may get different results in AWS than on virtualbox
- Need to consider the "Holiday Test" such as what happens when the EDR solution is disconnected from server side components
- At time of test some tools didn't trigger on mass storage, or power shell execute. Interesting
- Sentinal 1 seems to have been particularly responsive to fixing stuff discovered, positive sign
At best was 85% effective at stopping malware, you can't catch everything so tracing and response elements are crucial.
Gotta consider your business NFRs, one test was to run without any malware and see what false positives were flagged.
Sounds like some vendors were problematic about the results.
The mechanics of being good to each other
Courtney Eckhardt @hashoctothorpe
Fascinating talk about how to facility incident response (and really any) retrospective. Used the example of floating bridge sinking that is generally misunderstood.
Must consider WHY something made sense to someone, what is the world where this is true, must understand where the person is coming from.
Going to post longer version of the talk, worth looking up
Book Recommendation: Gentle Art of Verbal Self Defence
Avoid "Why" questions, they're "agentive" language, leads to questions of the form X did Y which leads to blame.
Unlike Most meetings, want to get the longest answer, not the shortest. Need to look for remediation items and contributing factors. Focusing on a single root cause is wrong for complex system failures, focusing on trying to find a single cause means you don't see the others.
Specific items for me:
- Share note taking, whoever is taking notes cannot participate so much in the discussion.
- Pay attention to who's talking ad who's not.
- Stop the meeting and ask "Does anyone who hasn't spoken want to add anything" then wait till it's really uncomfortable. People need time to get there thoughts in order
- Avoid jokes, Comedy == tragedy + time, there has not been enough time when you're running the retro
- To lighten mode, be kind, thank people, call out success
- If you get something wrong (in the meeting) apologise and move on, don't wallow, don't allow others to wallow
Gargoyle hunting: Detecting 'Gargoyle' code-hiding via automated Windows kernel analysis
Aliz Hammond @AlizTheHax0r
Deep dive into low level kernel detection of "Gargoyle" technique for executing code from non executable memory to avoid memory scanning security tools.
Technique involves using windows timers to briefly mark memory executable then execute, then mark back. Relies on Return Orientated Programming (must look into this)
In terms of working out how to defined / detect. Started with first principles of "what artefacts must exist" then went from there through to what could be detected.
Good thoughts on automation, don't take control away from the human, focus on automating detection of objective facts, leave "what that means" to the human.
Tool to look at: Unicorn engine. Execution sandbox based on QEMU
Capstone binary dissembler.
Internet Voting - From bad idea to poor execution
Chris Culnane @chrisculnane
Short version, it's a terrible idea and worse than you thought.
Break voting into supervised and unsupervised:
- Supervised fundamentally means the cost for fair, un-coerced elections on state
- Unsupervised includes postal, means it's on the citizen, far less likely to be non-discriminatory
So much focus given to availability that it's distracting from the other crucial parts of election security.
Verifiability is crucial, not just "its been tested" but demonstrate the production run of the election was done right. Important for orderly transfer of power.
Victoria did an electronic, supervised, fully verified, open source trial. Went well. Decided not to continue because election board thought it was too complicated
Internet voting significantly worse than postal, securing the client much harder, scope of compromise much bigger.
All the arguments in favour of Internet Voting are BS, but we keep pushing it out anyway, census update DOWN 10%.
Coercion is often passive. Don't want the person next to you on the couch to argue, change vote. Don't want child helping elderly vote to think worse of parent, change vote
3 kinds of verifiability:
- Individual - is my vote correct
- Universal - is the overall election result correct
- Eligible - verify that people who voted were eligible to (not technically hard but politically difficult as is perceived as vote tracing)
Also need to be "Receipt Less" so you can't have proof for selling your vote or coercion. I.e. must have nothing that proves to others what your vote was while still proving to you that your vote is correct.
Scytl builds the system usde in Aus, nobody knows who owns it, this is fine.
Availability bias, people have been using TLS decrypting proxy for DoS protection, compromising secrecy.
If we can't manage to do supervised electronic voting well we shouldn't be talking about internet
Black Swans: How to prepare for the unexpected
Wade Winright @vashta_nerdrada
Really good talk about how to prepare for unexpected scenarios like a 0 day attack. Mostly I took photos of the slides so hopefully Wade posts the talk. Some key take aways I noted:
Trying to predict black swans leaves you more venerable to the ones you didn't predict.
Instead focus on being prepared for the unknown.
85% invest in known good practice, 15% in what if
This is horrifying. Software Defined Networking breaches that means you don't get the protections you expect.
The detail was a bit beyond me so the notes are far from complete, but essentially lots of escalation into the control plane of this particular SDN system which basically meant full access to the network.
(Not) hacking your biology
Sophia Frentz @SophiaFrentz
Not much new to me here having worked on clinical software so long, but excellent call to action and summary for those that haven't the experience
There is not an info sec culture. Tech doesn't solve existing social problems, just magnifies them. Talking about patient info in the hallway is a social problem.
Paper records have impacts too
Physical Access Control on Sesame Street
Fascinating dive through hacking RFID access control cards.
Didn't take many notes since it was a lot of detail on the particular RFID card formats etc.
Key takaways were:
- Low freqency RFID cards are totally insecure and clonable
- High fequence cards are only secure if you don't use the default encryption key. Turns out virtually everyone uses the default encryption key
- If you don't disable low frequency, people can still use it even if you're issuing high frequency cards
Securing people that don't look like you... yet
Laura Bell @lady_nerd
Independence assessment equivalent to Katz for digital life. Need to dig into this some more but really good idea, See https://github.com/open-security-nz/sage
The key focus is that what works for us doesn't work for everyone, need to look at the needs and what actually works for their threat model. E.g. the classic "notebook of passwords is a reasonable solution for people who mainly use a single computer and where physical security is good enough".
Humans are not good at perceiving what their future selves will be, so we don't tend to make good assumptions about what will work for the elderly online, but at this point access to digital resources is a human right that you need to survive in society.
You can't make assumption based on age, people age differently so one 90 year old may be more aware and capable than a 60 year old, need to look at people as individuals, work out what they're individually capable of and where they need support.
Looking at the Age Concern Recipe for Life gives 15ish things that you need in your life to have a fulfilling life, many of us actually fufill some of these needs partially or fully digitally, why would that be any different for the elderly? We must provide access not tell them to delete facebook.
This leads to a diagnostic framework (Sage) for assessing how much support people need in what categories. This is based off the existing assessments we use for physical independence and other such factors.
+Bell Instrumental Activities of Digital Living+
There are ethical and legal issues we haven't dealt with yet. If people need assistance from carers to act for things like online banking is that allowed? Need Power of Attorney / Digital Guardians type concepts. Need to reflect delegated authority not just login with someone else's account. These are unresolved issues we need to start thinking about as a society.
Also launching https://opensecurity.nz which is an initiative to get more sharing of tools whether software, templates or other things in the security community in NZ.