Saturday, 15 February 2020

(Women-in-Tech)++

So many times I've been asked how do we increase the number of women in tech roles and for years I've had no idea what the answer was - I had no idea why I was the only female in my teams. However, I've more recently paid attention to the tech teams that are 100% male vs the tech teams that have a good diverse balance, and I think I know what is different.

Technical Female Leadership

So much focus goes into women in management leadership roles, however if your organisation has no senior female technical leads, then you will never be able to tip the balance.


  • You can't be what you can't see. This mantra has been repeated so many times it almost hurts to write, yet to be honest - it hasn't stuck for the technical fields. The simple fact is, a female is much more likely to sidestep into a non-technical role if there is no obvious pathway for her in her career. Or worse, not even join your organisation in the first place. And really, who'd blame her?
  • Female technical leaders are less likely to have unconscious bias and are more likely to mentor and drive both males and females equally. They will have high expectations of both genders. Therefore, your female techs will be given the same difficult projects and same training opportunities. A female tech isn't there to meet your quota, she wants the same work as the guys and if she's not given the same opportunities - she will leave.
  • Female technical leads have a vested interest in improving the gender diversity problem. She wants to tip the scales and see more women in tech. So she will actively grow a diverse team for you.
  • A female senior technical lead is likely part of multiple women in tech communities and groups. (I joined my first one in 1995 at ANU before starting engineering and have been in at least a dozen since). She's flying your banner just by being in those groups and showing that your organisation is diverse. She knows technical women and as a leader, she knows she can encourage them to apply for tech roles when they are advertised.
Can a senior male technical lead do a good job of mentoring and growing a diverse technical team? Possibly - though there is less evidence of this.

If you're reading this and already formulating excuses for why you don't have female tech leads, I've heard them all before.  "There is no pipeline, the women leave tech roles before reaching this level" or my (sic) favourite "We'd have to drop the standard to recruit female technical leads"

I want you to stop, pause, think about the attitude and biases you're projecting with these excuses. Consider whether you genuinely want change or you just want to look like you want change. If you seriously want change - then make change.

Wednesday, 23 October 2019

Segment Routing


Segment Routing (SR) is a proposed solution to replace MPLS in the wireline networks which is picking up a lot of traction.

RFC 8402 is the Segment Routing Architecture standard which was accepted & published in July last year, it had been worked on for around 5 years before becoming an RFC. It is considered a relatively new protocol. There are currently 42 draft IETF standards in progress for various features around the SR architecture. Lots of information can be found on SR at https://www.segment-routing.net/

It works currently by leveraging either MPLS or IPv6 to represent segments in a network.
A segment can be a network link, the link between two router. It can be a node, identifying the router itself, or it can represent a service – which is essentially the customer network.

Each segment in the network is represented by a Segment Identifier or SID. As you can see in the diagram below, Segment routing works together with an IGP. IGP stands for Interior Gateway Protocol, which is an umbrella term for the routing protocols that share routing information within a common routing domain. Segment Routing currently leverages  IGPs to spread information of the SIDs throughout the network. The two IGPs that SR can use at the moment are OSPF and IS-IS. When SR uses OSPF, the SIDs are distributed in the extended prefix Link State Advertisements. When using IS-IS they are distributed using the router capability advertisements




In SR, every node has a unique identifier called the node SID. This identifier is globally unique and would normally be configured on a loopback address on the device.
In IPv4 networks, the SID is encoded as a standard MPLS label, whereas in IPv6 it is encoded as an IPv6 address associated with the segment.

I’m going to work through an example that focuses on SR-MPLS. This has been done in VIRL and I will attach the VIRL file at the end of this blog post.

You can see in this network the SID allocated to each of the routers.

There is a concept of the global block in  segment routing which begins at 16000, in my case I’ve kicked the numbering off at 19000, just because I could. The last digit of the SID corresponds to the router number in this network.
By default in this network, when a router goes into the ingress router it will take the best path through the network as determined by IS-IS. In this case, it is vi R1, R2, R3 and finally through R4.
To demonstrate one of the features of SR, I’m going to force a packet to go via R5.

In the configuration below I’ve set up a tunnel through to R4 which an explicit path titled SIDLIST1.
In the example you can see I’m explicitly stating the pathway to be 19002, 19003 and then 19005 before going to 19004.

  interface tunnel-te1
    ipv4 unnumbered Loopback0
    autoroute destination 100.0.0.4
    destination 100.0.0.4
    path-option 1 explicit name SIDLIST1 segment-routing
  explicit-path name SIDLIST1
    index 10 next-label 19002
    index 20 next-label 19003
    index 30 next-label 19005
    index 40 next-label 19004

The options for defining path are fairly extensive. It can be configured to avoid a router, to always go through a particular router and many other options. But for now we’ll see what happens when we apply this to the lab network.

I have the explicit SID list configured and what I’ve done is tapped each link and opened the traffic in wireshark so we can see exactly what the packet looks like as it goes through a segment routed network.

I have set up a ping from R7 to R8 across the SR network. The packet goes straight into the ingress router. The router will look up the route and then put the appropriate stack of segments within the packet and forward to the next router. This is were I first tap it.



Here (above) between R1 and R2 you can see the stack of MPLS labels indicating the segment route to take.
The active segment is on the top and is the segment that the router inspects when it arrives at R2. In this case R2 will see 19003 and will forward the packet on to R3. Before forward it will remove the top label.

Between R2 and R3 (above) we can see that stack is slightly smaller and the active SID is now 19005. This means R3 will forward the packet to R5, once again removing one of the labels.


Between R3 and R5 (above) we see the active SID is now 19004, meaning that R5 will forward to R4 removing the SID before doing so.


Above we see between R5 and R4 all the SIDs have been removed, there is just a final label which represents the customers vrf, and so R4 knows to forward to R8.

In summary, we can see how segment routing uses the MPLS labels to represent SIDS and how it is possible to configure explicit routes through the providers network.

Click here for the VIRL demo file






Tuesday, 29 January 2019

0x001A

I completed a Bachelor of Engineering with Honours specialising in Telecommunications and Digital Systems between 1995 - 1999.
I worked as a Design and then Senior Engineer in Network Development and Optimisation for OnAir Networks and then later in Terminal Interworking within Cellular Engineering. I loved it.
After 9 months of maternity leave I tendered my resignation to care for my 3 children that I opted to have within 3.5 years to ensure I wasn't too long out of work.
I completed a Masters in Computer Networking, multiple Cisco certifications and a couple of security certifications.
I've worked as a Network & Security specialist from 2009 until current.
I am currently working as the Director of a highly technical section.
This is my history and here is what I've learnt from spending the last 0x001A years as a minority in my career.

  • My view of women in STEM events has evolved throughout my career. I've had times I hated them. Times I thought they achieved nothing and were a waste of time. I still see my former thoughts echo'd back in other tech women that just want to do their jobs. Today - they are not everything, but they raise awareness that there is a lack of women in tech roles and if only one more female is enabled from an event, then they are worth it. 
  • When you meet another woman in tech, it can sometimes feel awkward. I'm so used to working with men that when I get to work with a female, I'm not so sure how to act. Some women love having an ally others will see you as competition. And some people will compare the only two women on the team, with comments like "Jenny is more technical than Sally". Don't compete with other women. We have enough to deal with.
  • When you start a new role, its harder to get credibility than a male. Not getting good projects, not being given full TACACS access, questioned on new engagements - it happens. As a female, its easier not to move around as much. Because once you've proven yourself and its understood you know your job very well - its easier to stay where you are. But don't. Put yourself out there - believe in yourself. 
  • You will be mansplained to - multiple times. It's frustrating when that tech director painfully explains how to use ls on a linux system. This isn't a reflection on you, this is a reflection on them. This is their embarrassment not yours. Don't take this responsibility on, its not yours. Move on and ignore them.
  • There is an expectation that because you are female that you have better social skills, higher emotional intelligence and can represent and lead other generations. This is sexist. I had someone tell me that as a female I had a duty to behave better, kinder and nicer than everyone else. I don't. I'm shy, I'm introvert and I don't owe any more to the community than any other person doing their job in tech.
  • Take credit for your work. For many years I would allow other people to take credit for my work. When my name was forgotten in the credits, I would dismiss it and say it was okay. It's not okay. Don't be modest and accepting - women have the right to be as proud of their work as men do. If they say, "Sorry we forgot to give you credit", don't say its okay - tell them to correct the situation and do the right thing. Women are adverse to boastfulness. Don't be afraid of being proud of your work.
  • Remember why you're doing it. You will have bad days. You will be undermined and minimised. You will be talked over and mansplained. You will be dismissed as attending the "partners program" at tech conferences - the partners program being for wives and girlfriends of attendees. Forget all that and remember why you are here. When this happens, I put on my headphones, I sit at my computer and I lose myself in my tech. Because no matter what people say or think - this is my job, this is what I love doing and this is what I will continue doing.
Now get out there and do your tech jobs ladies!!

Sunday, 24 June 2018

OzSecCon 2018

On 2-3rd of June 2018 I attended OzSecCon in Melbourne. I'm not really a locksport enthusiast by any stretch of the imagination, I'm happy to fiddle with a lock and pick during social night - but I don't go out of my way to find the locksport village at a conference. However - the atmosphere at OzSecon was overall amazing. Notwithstanding, it is hosted by Topy - the Australian who has lugged his locksport stores up, down, east and west across Australia, at his own personal expense, hosting the locksport villages at AusCert, Ruxcon, PlatypusCon, BSides Canberra and probably many more I'm forgetting. He is the drive behind growing Locksport in Australia - so if you are remotely into Locksport, OzSecCon is where you should be.

I've done a brief writeup of the talks and workshops I attended below.

DAY ONE

‘Keynote: Red Teaming’, by Jek Hyde



Jek works on Walmart Red team. She made it clear that her position on the red team is to achieve physical access - not work on computers. She referred to herself as a “Professional burglar”. She discussed secure facilities syndrome - in which facilities tend to be very hard to get into but once in, is all soft and squishy on the inside due to wanting to promote a good culture. She did a walkthrough of a pentest she did in Canada. Started with dumpster diving. Found out about meeting, made a fake pass, wore fake pregnant belly, used a Bose cloner to clone a pass and got in.
Installed keyloggers, Dropbox, rubby ducky & listening devices. Heard a lady going out for lunch and used her office to gain access to systems. Key takeaway point was that physical and logical are treated separately when they affect each other so much and should be looked at together.

‘Manipulation aids in opening safe locks’, by Jaakko Fagerlund

 Jaakko is from Finland and is a machinist by trade and loves breaking all things mechanical.
Discussed through the techniques of cracking dial combination safes. The wheels within the dial can be different shapes and graphing (turning the wheel through each number). Right contact point (sloped) is the one that is most useful to measure. Showed graphs on the non-roundness of wheels - 0.5mm deviation at some points. Exploits are based on dialing tolerances, cheap electronics, reading wheels in the order W3, W2, W1.
Advanced exploits use electronics to graph the wheel pack, ultimate way is a manipulation robot (autodialler with a microphone - softdrill)

 

‘Cognitive biases and how to be less wrong’, by Alex Hogue


Alex discussed base rate rejection. He explained that people are more likely to look at the evidence without looking at the base rate. Eg. creaks in a plane == evidence of impeding crash despite base rate of crashes being low
He also discussed confirmation bias. Eg. Verifying your hypothesis only with tests that will result in positive confirmation. This can be beaten by using null hypothesis - proving yourself wrong.
Availability Heuristic - if there are more examples in public media, then people assume it is more common eg. Ransomware. Leads to “after a disaster we prepare more”
Others: scarcity bias, loss aversion, sunk-cost fallacy, the halo effect, outcome bias, inattentional blindless, bias bias, cognitive dissidence creates more bias.
Alex concluded with a very entertaining slight of hand routine done to a volunteer from the audience.

‘Tamper resistance bypasses’, by Connor and Emily Morrison

Covered different types of tamper evident seals with some recorded demos of removing them

 

 

 

 

 

 

 

 

‘How to disappear completely’, by Attacus

Atticus provided an overview of “Senseface” - which is a product that detects faces. She showed an admin interface of a Westfield Info booth that records faces estimating gender and age for advertising purchases. Atticus discussed Detection vs Recognition. Detection is allowed without consent because it doesn’t relate to personal or sensitive information. She spoke about the Identity-matching Services Bill 2018 - the Capability will be provided to Home Affairs for national security, identity safety etc. She noted that the Attorney-General's department is in discussion about selling facial records to private companies.
Second part of talk moved to techniques of avoid facial recognition. Talked about how facial recognition worked and old school mitigation techniques include, wearing a balaclava, wearing sunglasses or pulling weird faces to avoid facial recognition.
cvdazzle.com - Adam Harvey, ahprojects.com provides solutions to avoiding facial recognition.

‘Back in time: Finnish lock industry’, by Thomas Covenant

Thomas covered off the history of locks in Finland, which is a leading region of lock production because of the rockiness of the country.
Karelian locks (a region ceded to the Soviet Union from Finland) date back to medieval Finland.
She talked through wooden locks, development of metal and ornamental locks and the spiritual beliefs around locks keeping people safe.
1920s industrialisation heralded Abloy locks in Finland. Designed by Finnish man who repaired a cash till, and saw the rotating disks. 1918 patent registered, sold in 1919 for 34 euros




DAY TWO


‘The ALC Galaxy Lock: an in-depth look’, by Adam Foster

Adam talked about how he bought and disassembled a galaxy lock, released by the Australian Lock Company (ALC). He discussed how it worked and possible ways to attack it. He stated that he had managed to pick it but he hadn't recorded it and couldn’t replicate.

‘Challenge locks’, by nullwolf

Nullwolf started off explaining reasons why you would build challenge locks - Reddit lock-picking awards profile flair for building challenge locks. He covered off on the rules for building a challenge lock eg. At least 6 modifications, working key
Covered shopping list required.
Using a dremel to do pin sculpting

 

 






Impressioning Workshop

I attempted the impressioning workshop... twice! I was terrible at it. But I learnt a lot about the technique and skill involved to impression a key.
 


 

 

 

 

 

 

 








Milling your own cutaway lock 

This is when I realised the value of OzSecCon being run at Melbourne Polytech. Access to all the machining tools allowed a live demo of creating cut away locks (plus many more machining demos that I missed). @anarchy_won did the demo and was patient and willing to answer any questions we had on mill types, techniques and other hints. It was fantastic seeing his passion and knowledge.















As well as the talks and workshops, OzSecCon had an inclusive and welcoming environment. I was greeted with friendliness and helpfulness the whole conference. I attended the female lunch and the Friday night party - both were really enjoyable. The party was catered with Turkish and a neverending bartab!


Overall, I've heard the locksport community likened to what the computer hacker community was 20 years ago. A little edgy and considered borderline inappropriate. However, like the trailblazers that made computer hacking mainstream, OzSecCon is breaking down barriers and making this important topic visible and accessible to everyone. Well done Topy & the OzSecCon Crew!!

Monday, 28 May 2018

BGP route injection - extending VIRL externally


This simulation a demonstration of route injection in a BGP network with 6 AS' - which I demonstrated at CrikeyCon 2018. However, at that time I hadn't been able to extend outside of the VIRL environment so had to browse via wget commands on the server CLI.

Today I had the time to configure my VIRL instance to extend to outside the environment to external devices (in this case a Windows VM).

In retrospect, this wasn't very difficult. But there is very little clear documentation on how to do this. The steps to achieve this were.

1. Configure the flat network under the VIRL Web GUI. Here we specify the IP address range of the external network and the interface on the VIRL VM/machine that we want to link to the external connection. Note down the flat network address.



3. On the VIRL CLI we now find the bridged interface that has been allocated the flat IP Address 172.16.1.254

 virl@virl:~$ ifconfig
br1       Link encap:Ethernet  HWaddr 00:0c:29:37:1c:0e
          inet addr:172.16.1.254  Bcast:172.16.1.255  Mask:255.255.255.0


4. Then make sure eth1 has been associated to the appropriate bridge

virl@virl:~$ brctl show
bridge name     bridge id               STP enabled     interfaces
br1             8000.000c29371c0e       no              dummy1
                                                        eth1


if this isn't the case use the command brctl addif br1 eth1 and check again

5. Add a flat device to your simulation. If connecting to a linux server and wanting to access the rest of the network, make sure you enable routing (ipv4_forward & iptables rules).


6. Ensure the network is configured to use the flat network that you've just setup


7. When the simulation starts you should be able to attach to eth2 however you intend to, and ping/ssh to every device in your simulation (provided you have setup routing within the simulation to enable this)



I wish someone had walked me through this last Feb when I was fairly time poor - but now it's done. I hope it helps someone. Happy simulating!!

Sunday, 6 May 2018

Getting Familiar with Scapy

Getting Familiar with Scapy

https://blogs.sans.org/pen-testing/files/2016/04/ScapyCheatSheet_v0.2.pdf

Navigating Classes/Layers:

Check the details of each class/layer using ls():

>>> ls(IP)
version    : BitField             = (4)
ihl        : BitField             = (None)
tos        : XByteField           = (0)
len        : ShortField           = (None)
id         : ShortField           = (1)
flags      : FlagsField           = (0)
frag       : BitField             = (0)
ttl        : ByteField            = (64)
proto      : ByteEnumField        = (0)
chksum     : XShortField          = (None)
src        : Emph                 = (None)
dst        : Emph                 = ('127.0.0.1')
options    : PacketListField      = ([])


Check commands available using lsc()

Format is command(packet)

Sending a Packet:


>>> pkt=IP(dst="google.com")/ICMP()

sr - send & receive
srp - send & receive layer 2

>>> sr1(pkt)
Begin emission:
..................Finished to send 1 packets.
........................................................................................................................................................................................................................................................................................................................................................................................................................^C
Received 426 packets, got 0 answers, remaining 1 packets

sr1 = send and receive 1 packet, will send one and wait for one response

Using just send will just send and not wait for a response
>>> send(pkt)
.
Sent 1 packets.


Using sendp will send the packet at layer 2 (all classes with p are at the layer 2 level)
>>> sendp(pkt)
.
Sent 1 packets.

To see the result, sr always has tuples
>>> (ans,unans) = sr(IP(dst='google.com')/ICMP())

Iterations:
>>> pkts = IP(dst='192.168.0.0/28')
>>> [pkt for pkt in pkts]
[<IP  dst=192.168.0.0 |>, <IP  dst=192.168.0.1 |>, <IP  dst=192.168.0.2 |>, <IP  dst=192.168.0.3 |>, <IP  dst=192.168.0.4 |>, <IP  dst=192.168.0.5 |>, <IP  dst=192.168.0.6 |>, <IP  dst=192.168.0.7 |>, <IP  dst=192.168.0.8 |>, <IP  dst=192.168.0.9 |>, <IP  dst=192.168.0.10 |>, <IP  dst=192.168.0.11 |>, <IP  dst=192.168.0.12 |>, <IP  dst=192.168.0.13 |>, <IP  dst=192.168.0.14 |>, <IP  dst=192.168.0.15 |>]
>>>
 

Reading/logging traffic:


Sniff packets on the interface:

>>> pkts = sniff(count=24)>>> pkts
<Sniffed: TCP:19 UDP:4 ICMP:0 Other:1>






Write the packets to a pcap file:

>>> wrpcap('./cap.pcap', pkts)
 

Write the pcap file back to a rpkts variable:

>>> rpkts = rdpcap('./cap.pcap')
>>> rpkts
<cap.pcap: TCP:19 UDP:4 ICMP:0 Other:1>








Use str() and hexdump() to also see the raw packet


Fuzzing:

verify which fields will be fuzzed by doing something similar to:




>>> (IP(dst='8.8.8.8')/fuzz(UDP()/BOOTP())).show()


State machine!!
http://www.secdev.org/projects/scapy/doc/advanced_usage.html#automata


Photo Journey


2016 - Opening Ceremony of the first BSides Canberra

2016 - Opening Ceremony of the first BSides Canberra

2015 - Sydney CCIE bootcamp:



2012 - Participating in my first CTF - Ruxcon

2012 - Participating in my first CTF - Ruxcon

1995 - ANU hosting Women in Engineering

Me on far left in black