Radically Open Security

GAEN Protocol Metadata Deanonymization and Risk-score Inflation Issues

2020-09-30T00:00:00+00:00

Summary

The TX Power value in the metadata in the beacon of the GAEN protocol used by the corona/contact tracing app allows for attackers to influence risk-score calculations in their favor, the same metadata can also be used to deanonymize diagnosed users based on the type of phone they are using.

Intro: GAEN Metadata in a nutshell

The beacon sent out by the protocol contains some metadata. This metadata is encrypted with the Associated Encrypted Metadata Key (AEMK), which is derived from the current TEK as follows:

AEMK = HDKF(TEK, NULL, "EN-AEMK", 16)

The metadata is only 4 bytes in length and is currently specified as follows:

Byte 0 — Versioning. - Bits 7:6 — Major version (01).
                     - Bits 5:4 — Minor version (00).
                     - Bits 3:0 — Reserved for future use.
Byte 1 — Transmit power level. - This is the measured radiated
      transmit power of Bluetooth Advertisement packets,
      and is used to improve distance approximation. The
      range of this field shall be -127 to +127 dBm.
Byte 2-3 — Reserved for future use.

The four bytes of metadata are encrypted like this:

AEM=aes128ctr(AEMK,RPI,Metadata)

Here, AEMK is used as the key, RPI is used as the initialization vector (IV), and Metadata as the plaintext input to an AES128 in a Counter Mode-like construction. Counter Mode acts as a stream cipher in this construction and only uses the first 4 bytes of its output, and thus no padding is needed. However AES in Counter Mode does not provide authenticity of the encrypted content. This means that a re(p)laying attacker can flip bits in a controlled way[1].

[1] https://lasec.epfl.ch/people/vaudenay/swisscovid/swisscovid-ana.pdf p 12, section 3.5

Issue 1: Increasing risk scores by bit-flipping TX Power in the Metadata

The problem is that the TX power value is not uniform furthermore it can be known for transmitting devices and can thus be manipulated through bit-flipping to make re(p)layed beacons appear closer than in reality and thus increasing the risk-score of the victim.

There are multiple variants of this attack based on the knowledge of the attacker about the re(p)layed beacon sending device:

if the attacker knows the exact type of the sending device the TX power value is known, and can thus be safely manipulated to the lowest known valid dB value which is -46dB. With the bulk of android devices having a TX Power value of more than -30dB this is a significant change.
If the attacker knows some probability distribution of possible sending devices it is possible to calculate the odds of bitflips which have a high chance of flipping the TX Power value to a lower but still valid value.
If the attacker has no knowledge of the sending device it is still possible to calculate the most hopeful combination of bitflips leading to an increase in risk-scoring. An example of such a calculation is appended in C source code to this report. In this case there is still a ~65% chance (by flipping bits 2 and 3) to make the received beacons appear closer than they really are - while the manipulated TX power value will flip to a value that is valid for some other device.
If the attacker does not care about TX Power values that do not correspond to existing devices, it is also possible to flip bit 6 of the TX power and thus generate a value that is not associated with any device, but which will with very high probability register as a very close contact.

An attacker may also send multiple attempts flipping various bits; the validation during checking might weed out the invalid ones, and keep the valid but stronger values. This is speculation and depends on the implementation handling multiple Beacons with the same RPI but different AEM values and the validation of these in case they are decrypted with the Diagnosis key.

Impact: A re(p)laying attacker can can improve his attack by influencing the risk-score calculation.

Issue 2: Deanonymizing Diagnosed users based on devices with unique or uncommon TX Power values

The value of the Transmit power level is a device-dependant value[2]; values for Android phones are published by Google[3]. Some of these values are unique to a specific device, as in the case of the Pixel 3a, SM-A510M, SM-G610F, and SM-J510F. This means that diagnosed victims with these devices are easier to deanonymize, if they are known to be in possession of such a device. This attack can be extended to a probabilistic one when combined with statistical information on which devices are in common use in a certain geographic location (for example based on regional sales statistics or local fashion trends).

The GAEN system sets the TX power based on the device and includes this information in the AEM metadata[4][5]. By combining beacons of infected persons in conjunction with an infected person’s diagnosis key it is possible to infer which device these people were using.

TX power distribution of Android devices"

In the bar graph above, the X-axis shows the value of TX power sent, and in the Y-axis shows how many different devices set this value. Devices with low values on the Y-axis are TX values that should be easy to identify. Notably, the Pixel 3a, SM-A510M, SM-G610F and SM-J510F all have unique values. If these values are seen in the Metadata, the sending device can be unambiguously identified.

Impact: Infected persons can be easier (sometimes trivially) deanonymized by entities having collected their beacons based on the TX Power value in the Metadata.

[2] https://developers.google.com/android/exposure-notifications/ble-attenuation-computation [3] https://developers.google.com/android/exposure-notifications/files/en-calibration-2020-06-13.csv [4] https://developers.google.com/android/exposure-notifications/ble-attenuation-overview [5] https://blog.google/documents/70/Exposure_Notification_-_Bluetooth_Specification_v1.2.2.pdf

Timeline

2020 Jun 5 - Vaudenay, Vuagnoux report mentions malleability of Metadata
2020 Aug 27 - Request by client to disclose these issues to Google, Apple and the dutch National Cyber-Security Center (NCSC)
2020 Aug 28 - Full Report shared with Dutch Ministry of Health
2020 Aug 28 - Submitted to the Google Android Security Bugtracker
2020 Aug 28 - Apple acknowledges receipt of report
2020 Aug 31 - NCSC confirmation of receipt
2020 Sep 1 - Google assigns issue to the Android engineering team.
2020 Sep 7 - Google responds to issue I- see below
2020 Sep 29 - Full Report gets published
2020 Oct 05 - Detailed write-up of CVE-2020-24722 gets published

Google Response (2020 Sep 7)

Thanks again for your report. We understand and have analyzed the concern that Associated Encrypted Metadata (AEM) TX (transmit) power could be altered as part of a relay attack. We do not believe that TX power authentication would be a useful defense against relay attacks for the following reasons:

TX power authentication doesn’t protect against the use of a high-power antenna positioned to cover a large area with a signal strength indicative of proximity. This is because the system is designed to be highly tolerant of differences between TX-power and received signal strength indicator (RSSI) caused, for example, by both devices being in-pocket. The Android ecosystem also has a diverse range of hardware: some Android devices transmit signals as much as 30dB weaker than others. The required system tolerance to differences in transmit power means that relaying a packet from such a weak device on a higher transmit power device would already allow the higher power device to appear nearby without altering the TX field.

TX power authentication would not prevent the deployment of malware on phones to perform relay packets; app-store and OS policy are more effective to prevent collection of EN packets by third party apps.

In this context, encrypting the AEM prevents an adversary from joining between RPIs coming from the same device (using device-specific TX power as a source of entropy).

Please see https://github.com/google/exposure-notifications-internals/blob/main/en-risks-and-mitigations-faq.md#additional-considerations for additional information.

Appendix I - example calculation of best bitflips



        #include <stdio.h>
        
        typedef struct {
          char tx;
          int cnt;
        } TX_Count;
        
        // source: https://developers.google.com/android/exposure-notifications/files/en-calibration-2020-06-13.csv
        // cnt is count of all items with the given tx value
        TX_Count calib[] = \{\{-46, 3}, {-45, 2}, {-41, 32}, {-40, 5}, {-39, 1}, {-38, 4}, {-37, 11},
                          {-36, 15}, {-35, 75}, {-34, 11}, {-33, 223}, {-32, 22}, {-31, 83},
                          {-30, 851}, {-29, 76}, {-28, 262}, {-27, 522}, {-26, 1025}, {-25, 1414},
                          {-24, 2075}, {-23, 35}, {-22, 245}, {-21, 67}, {-20, 1037}, {-19, 1371},
                          {-18, 255}, {-17, 14}, {-16, 32}, {-15, 10}, {-14, 2}, {-13, 1}, {-12, 16},
                          {-9, 16}, {-7, 6}, {-6, 27}, {-5, 4}, {-3, 12}, {-2, 5}, {-1, 1}, {0, 27}, {2, 1},
                          {0,0}};
        
        int main(void) {
          int bits[7] = {0};
          int i, j, k, total = 0;
          // calculate total of all cnt values
          for(i=0;calib[i].cnt!=0;i++)
            total+=calib[i].cnt;
          // test each tx_count in calib
          for(i=0;calib[i].cnt!=0;i++) {
            for(j=0;j<(int)sizeof bits;j++) {
              char flipped = calib[i].tx ^ (1 << j);
        #ifdef noisy
              if(flipped < calib[i].tx) bits[j]+=calib[i].cnt;
        #else
              for(k=0;calib[k].cnt!=0;k++) {
                if(calib[k].tx == flipped) {
                  if(calib[k].tx < calib[i].tx) bits[j]+=calib[i].cnt;
                  break;
                }
              }
        #endif
            }
          }
          for(i=0;i<7;i++) {
            printf("bit %d: %d (%2.3f%%)\n", i, bits[i], (bits[i]/(float)total)*100);
          }
          return 0;
        }
        
        // outputs
        // bit 0: 3910 (39.511%)
        // bit 1: 4205 (42.492%)
        // bit 2: 6306 (63.723%)
        // bit 3: 5375 (54.315%)
        // bit 4: 132 (1.334%)
        // bit 5: 74 (0.748%)
        // bit 6: 0 (0.000%)
        // flipping bits 2+3 from 00 to 11 has a chance of: 34.61114745% increasing risk by 12db
        //               2+3 from 10 to 01 has a chance of 29.111852549999995% increasing risk by 4db
        //               2+3 from 01 to 10 has a chance of 19.703852550000004% decreasing risk by 4db
        //               2+3 from 11 to 00 has a chance of 16.57314745% decreasing risk by 12db
        
        
        // flipping bits 2+3 from 00 to 11: 34.61114745% -12db
        //               10 to 01: 29.111852549999995% -4db
        //               01 to 10: 19.703852550000004% +4db
        //               11 to 00: 16.57314745% +12db
        
        // noisy variant
        // bit 0: 3976 (40.178%)
        // bit 1: 4290 (43.351%)
        // bit 2: 6306 (63.723%)
        // bit 3: 5499 (55.568%)
        // bit 4: 514 (5.194%)
        // bit 5: 9486 (95.857%)
        // bit 6: 9868 (99.717%)

Featured in the Volkskrant

2017-07-14T00:00:00+00:00

Radically Open Security's CEO Melanie Rieback was featured in the Dutch newspaper "Volkskrant" in an article "The Honest Hacker" by journalist Gerard Janssen. In the article she talks about cybersecurity, collaboration and transparency about the methods used.

Read the article on the Volkskrant website: http://www.volkskrant.nl/tech/deze-wonder-woman-van-de-computerbeveiligingswereld-hackt-zo-je-bedrijf~a4505208/

In the article she talks about cybersecurity, collaboration and ROS's transparent way of working.

Special thanks to Robert van de Griend from the Volkskrant, Gerard Janssen and Aisha Zeijpveld for the permission to repost the article and photos.

Click on the picture to read the article:

Remote exploit in crashplan backup server

2017-06-22T00:00:00+00:00

We're about to get another CVE to our name.

Let's talk a bit on how we found it. One of our customers commissioned a test of their infrastructure. On of their systems was running the Crashplan backup server from Code42, and we found a remote code execution possibility. As luck would have it (for our customer that is) a setting in their firewalls made it impossible to exploit it in their environment, but naturally we reported it to Code42. Their response was... well, not what we hoped...

Anyway, here's a short write-up of how we found it (and we usually shorthand Radically Open Security into 'ROS' when doing these writeups, so I'll continue that). And when I say "we" I really mean "Erik Bosman" since he's the pentester who did all the work on this one, and he deserves all the credit here.

During a port scan on crashplan.REDACTED.com, ROS found an open port with a service communicating using an unknown binary protocol. The service on TCP port 4282 seemed to be sending Java class names over the wire.

00000000 80 63 00 00 00 41 2d 31 38 37 38 32 7c 63 6f 6d |.c...A-18782|com|
00000010 2e 63 6f 64 65 34 32 2e 6d 65 73 73 61 67 69 6e |.code42.messagin|
00000020 67 2e 73 65 63 75 72 69 74 79 2e 53 65 63 75 72 |g.security.Secur|
00000030 69 74 79 50 72 6f 76 69 64 65 72 52 65 61 64 79 |ityProviderReady|
00000040 4d 65 73 73 61 67 65 b6 a2 00 00 00 22 01 00 bf |Message....."...|
00000050 a9 03 69 25 02 11 8e 7f aa f9 e9 88 14 98 a4 9c |..i%............|
00000060 0e 1c 30 61 73 fa e2 77 9d 10 88 a4 21 6c bb |..0as..w....!l.|
0000006f

Finding class names in a messaging protocol can be indicative of the use of (de)serialization. (De)serialization is the process of translating an object (or a group of objects) in memory to a stream of bytes and back. These objects can then be sent over network or stored on disk. Deserializing arbitrary objects from untrusted data is tricky and can often lead to remote code execution. The main problem is that allowing an untrusted party to create arbitrary objects on a system exposes a lot of normally unreachable code, greatly increasing the attack surface. As an example, the standard way of deserializing objects in Java, using ObjectInputStream can be exploited to gain code execution using publicly available code (Ysoserial: https://github.com/frohoff/ysoserial)

The software running on the host in question turned out to be the code42 backup server. Unfortunately, we failed to obtain a test license from code42, so the source code (for versions 5.3.4 and 5.4.0) was obtained using a download url from a presentation on Youtube and decompiled using CFR. This, however meant that we could not truly test the system locally (and reverse engineering the licence enforcement was way beyond the scope of the pentest.)

Our analysis revealed that code42 uses a number of different ways to serialize and deserialize objects. Objects implementing the IMessage interface, sent over port 4282 are deserialized using one of two methods:

Legacy Messages: A home-brew deserialization method for data objects implementing the IMessage interface
Google Protocol Buffers: A newer method, also employed to (de)serialize IMessage objects. It is up to the sender to decide which method is used.

However, some of these messages have custom deserialization implementations or they contain references to other objects which are not IMessages themselves. ROS found a number of (de)serialization implementations being used:

com.code42.io.TinySerializer: recursively deserializes objects with only primitive types. ROS did not find a way to exploit this deserializer.
com.code42.io.C42WhitelistObjectInputStream: A subclass of the vulnerable java.io.ObjectInputStream, however, this class overloads the resolveClass method to only allow deserialization of a select subset of objects, thwarting exploits generated using Ysoserial.
com.code42.io.CompressUtilityWhitelist: A decompression wrapper around C42WhitelistObjectInputStream
java.io.ObjectInputStream: Some code is still using the directly vulnerable java.io.ObjectInputStream, however, this code did not seem related to network communication and we did not find a way to ObjectInputStream directly on our own data.

While com.code42.io.C42WhitelistObjectInputStream limits the types of objects that can be loaded, it is not immediately clear that it can prevent exploitation alltogether.

First, while it is not possible to create instances of classes outside of the whitelist, due to a loophole, by creating a 'Proxy' class, which partially bypasses the overloaded resolveClass method, it is still possible to load any class, even non-serializable classes, but not to create an instance of it. The act of loading a class alone can result in the execution of code defined in static { ... } sections of classes. We created a program which tried to load all classes in the classpath used by Crashplan. This did yield some interesting results, such as (non-functional) Java GUI windows popping up, and a logger being started. But it did not give us any results which would allow us to exploit the program.

More importantly, the number of classes still allowed is quite large, the whitelist allows objects which match any of the following rules:

Object is an array
Object is serialiable and part of the com.code42 package or any of its sub-packages
Object is serialiable and part of the com.backup42 package or any of its sub-packages
Object is serialiable and part of the java.lang package or any of its sub-packages
Object is serialiable and part of the java.util package or any of its sub-packages
Object is serialiable and part of the com.google.common package or any of its sub-packages
Object is serialiable and part of the com.google.inject.internal; package or any of its sub-packages
Object is of the java.io.File class
Object is of the sun.util.calendar.ZoneInfo class

Since all publicly available exploit code uses classes outside of this whitelist, we needed to look for new ways of creating an exploit payload in this still sizeable list of allowed classes. Given that this would potentially lead to remote code execution on the backup server, a system which presumably gets sent sensitive organization data from lots of different sources, we put a considerable amount of time in trying to find an exploit payload which would work. In the end, we were unable to come up with a useful exploit chain. This is not to say that there might not be one in the future. The whitelist allows for entire subtrees of packages to be deserialized, new classes may added to packages, for example when a new version of Java comes out, or when google updates their java library.

Another avenue that looked interesting, but which we were unable to make work was using the java.lang.invoke.SerializedLambda class. This class implements the recently added lambda expression support in Java. What is special about this is that any lambda expression in the codebase gets serialized as this class and since this class is whitelisted, this means we may be able to deserialize any lambda expression. However, we did not find a suitable expression in the codebase to further our goal.

== Pwned in an instance(?) ==

Being unable to find a suitable exploit for the com.code42.io.C42WhitelistObjectInputStream red herring, we turned our attention to the custom serialization that is at the heart of the message parser that is listening on port 4282.

To save network traffic sending class names, new classes are registered with com.code42.messaging.MessageFactory once, and referred to with a numeric identifier after. The ClassMessage message, when deserialized, uses the classloader to load the class specified in the message, without checking whether this class actually is a valid message, and it isn't bound by any whitelist like C42WhitelistObjectInputStream. Then, when the class is loaded, we can send a message, which is of this class.

com.code42.messaging.MessageFactory will then try to instantiate this message with the following code:

try {
    message = (IMessage)type.newInstance();
}
catch (Exception e) {
    log.error("Unable to instantiate new instance! Missing default constructor? - msgUid={}, type={}", shortUid, type);
}

If type does not implement the IMessage interface, this will ofcourse fail, but not before creating an instance of an arbitrary object with a default constructor. To investigate if this would be a problem, ROS tried to instantiate all objects in the classpath (including the jars that are shipped with crashplan), monitoring network connections, to see if any of them resulted in useful behaviour. In an overnight run of this test, we found that org.apache.commons.ssl.rmi.DateRMI creates a listener socket (on an arbitrary TCP port) upon instantiation. Some further research yields that this listener socket in fact is a Java Remote Method Invocation server. This server in turn is vulnerable to the same deserialization attack we tried to attack before, but without a whitelist. Testing locally, we were able to gain remote code execution using a slightly modified version of Ysoserial on the newly created socket, but due to the unused ports on crashplan.REDACTED.com being filtered, we were unable to exploit this on the REDACTED infrastructure.

However, we still deemed this to be a security risk. If the firewall is ever misconfigured or temporarily turned off, or if an attacker can get behind it, this would lead to arbitrary code execution. It may not be the easiest one to fix, since it requires some serious rethinking of the serialization methods used, but that should not be a reason to shift the responsibility to the customer. Besides, the whitelist is so wide (perhaps call it a widelist instead?) that it's an accident waiting to happen.

Prizes!

2016-08-16T00:00:00+00:00

Radically Open Security has been rolling in prizes, during the last period of time!

Here they are:

Chamber of Commerce - SME Innovation Top 100

Radically Open Security was recognized by the Dutch Chamber of Commerce (KvK) as one of the Top 100 Most Innovative SMEs of 2016!

Inspiring Fifty

Radically Open Security CEO/Co-founder Melanie Rieback was selected for the 'Inspiring Fifty' Netherlands, as one of the 50 most inspiring women in the Dutch technology sector!

Pwnie Award (Blackhat USA) for 'Most Innovative Research' for Erik Bosman

ROS hacker Erik Bosman just won a Pwnie Award for 'Most Innovative Research' at Blackhat USA in Las Vegas last week!

Internet Freedom Festival Tool Showcase (for NetAidKit)

The NetAidKit won several awards at the Internet Freedom Festival Tool Showcase!

ISOC.nl Internet Innovation Award (for NetAidKit)

The NetAidKit won the Internet Innovation Award from ISOC.nl for 2015.

We are super proud of all of this success that we've been having since the very beginning! Thanks again to all of the awesome staff members, customers, and friends in the security/hacker/IT communities who have made all of this possible! :)

Radically Open Security - 2nd Anniversary!

2016-04-28T00:00:00+00:00

Radically Open Security is now officially 2 years old… it's hard to believe what a whirlwind this past year has been!

About our company

The size of our freelancer network has remained fairly stable at ~40 staff members. (3 management, ~10 core staff, ~25 extended network). There is still only 1 internal employee (the Director). Freelancers compose every other part of our organization, including pentesters / project management / R&D folks / tech writers / finance. And it works!
We have made loads of investment in our infrastructure, tooling, automation, and processes. A standard pentest quotation (offerte) used to take us 1-2 weeks to write… now it takes us ~30 minutes!
We have fully embraced Pentesting ChatOps (RocketChat, Gitlab, Hubot) and Kanban (Kanboard). The two integrated methodologies have been a revolution for the way that we work!
We've spent the least time on marketing / sales / PR. (As you can tell from this outdated blog.) This is primarily because word-of-mouth (and occasional conference talks) already brings us almost more new customers than we can handle. And we're growing carefully/organically, so we haven't felt the need to push it! ;-)

About our customers

We have already had ~30 different customers across a wide variety of sectors:

SW development / IT (6)
Government (4)
Non-profit / civil society (4)
Energy + Water (3)
Higher education (3)
Hosting providers/NRENs (3)
Core Internet backbone (2)
Insurance (1)
Law enforcement (1)
Computer security (1)
Media - television (1)

Approx. 30% of these customers are now (quite regular) repeat customers. The customer loyalty is partly rooted in our pentester quality, and is partly due to the 'Peek Over Our Shoulder' option that we offer by default.

And this isn't even accounting for the new customers in the pipeline. Customer demand is currently exploding for us!

Other facts

We made ~1500 commits to our ROS Github repository: https://github.com/radicallyopensecurity This is where we publish our tooling and frameworks… it is our commitment to release as much as possible into the open-source!
Our NetAidKit (w/ Free Press Unlimited) has now won multiple awards: ISOC.nl Internet Innovation Award 2015 + Internet Freedom Festival Tool Showcase. We are busy selling the first 1000 units (with V1.0 firmware) by email request - the webshop (for the general public) should be appearing in 1-2 months from now.
We just won our first large(!) international RFP in the United States (Washington DC).
If current levels of business remain consistent, we anticipate a half million Euros of turnover for 2016. OMG!!!
Due to our unusual non-profit business model and freelancer-only construction (think: Uber/AirBNB model for computer security consultancy), the Stanford Graduate School of Business is halfway through writing a case study on Radically Open Security for their MBA entrepreneurship program!!! That is my personal highlight of the year! I couldn't imagine a better validation of what we're currently doing.

Conclusion

So yeah… it's been a HECK of a year! I think that Year 2 wildly succeeded with turning ROS from a startup into a business. My hopes and ambitions for Year 3 are further maturation of our tooling / process / workflow. And maybe… just maybe… we might be able to generate the first Euros of profit for Stichting NLnet! I dream that this will be the year that we can start fulfilling that promise!

Thanks to everybody (staff, customers, partners) for enabling us to have this amazing journey,

Melanie Rieback

NetAidKit: protect yourself!

2015-10-07T00:00:00+00:00

Many people are aware of it by now: protect yourself when you go online!

This is especially important for journalists and activists, who are regularly targeted by parties who hope to keep the public in the dark. Protecting your sources, colleagues and yourself from prying eyes is of vital importance. But for many people it is not that easy to set up the tools and take the required measures.

That's why Free Press Unlimited and Radically Open Security have teamed up to create the NetAidKit. The NetAidKit is a pocket-sized, USB-powered router that connects everything to everything, designed specifically for non-technical users. The easy-to-use web interface allows you to connect the NetAidKit to a wireless or cabled network and share that connection with your other devices, such as a phone, laptop or tablet. Once the NetAidKit has been hooked up to a wireless or cabled network, you can make it connect to a Virtual Private Network or the anonymising Tor network at the click of a button. Any devices connected to the NetAidKit will automatically use these extra security features, without needing to configure each of the devices separately.

Besides for journalists and activists, this box is also very useful for other non-technical users. Free Press Unlimited is currently developing and marketing the NetAidKit for a wider audience. In 2015, the Netherlands chapter of Internet Society (ISOC.nl) awarded NetAidKit the Internet Innovation Award 2015. We are very proud that ISOC has acknowledged the importance of creating a user-friendly way to secure your internet connection.

To check out the specifics of NetAidKit on Github, go to:

https://github.com/radicallyopensecurity

https://netaidkit.net/

A busy year

2015-10-02T00:00:00+00:00

So it has been a year since our last update. Inexcusable, but we have a great excuse: we were busy! Which is not bad for an ambitious startup like Radically Open Security.

Great new projects, presentations and meetings have kept us off the streets. More and more organizations and companies acknowledge that they are responsible for providing their customer with secures services and communications, and have asked us to test the security of their systems online. By now our client base has grown to include companies like Surfnet, Free Press Unlimited and Amsio.

We are presently collecting case studies of some of our projects. You will be able to find them online soon! And of course, you can find examples of our work on Github.

Melanie Rieback was particularly busy, raising awareness of the need for transparency in the online security sector.

We also developed the NetAidKit in partnership with the Dutch NGO Free Press Unlimited. This award winning easy-to-use tool allows journalists and activists around the globe to use the internet securely and anonymously.

Another exciting project in the pipeline is our Open Source Anti-DDos Solution Project. By developing open source analysis and mitigation software, we want to make the – often expensive and complicated – protection against DDoS attacks affordable and obtainable for smaller companies and non-profit organizations. We have received support from two organisations, first from NLnet Foundation and now recently from SIDN Fonds for this project, for which we are very grateful.

So we spent this year working, not blogging. Radically Open Security has presently grown to 38 staff members. Thirteen of our staff are women - one of whom has been assigned the task of keeping our blog up to date, starting today!

Overview of talks in October 2014

2014-11-01T00:00:00+00:00

Radically Open Security has been busy this past month, presenting at conferences and teaching courses/workshops throughout the Netherlands, and Europe! Here is an overview of our activities in October:

On October 2, ROS CEO Melanie Rieback discussed Radically Open Security at the SURFnet Relatiedagen. SURFnet is a collaborative organization for information and communications technology in Dutch higher education and research.
On October 7, ROS co-founders Jurriaan Bremer and Mark Schloesser gave a Cuckoo Workshop at Security Academy, where they taught how to setup and use Cuckoo Sandbox to analyze suspicious files and interpret any found malicious behavior.
On October 14, ROS CEO Melanie Rieback gave an 'Adventures in DDoS Analysis' presentation at the FIRST Symposium in Tbilisi, Georgia followed by co-teaching a two-day FIRST/TERENA TRANSITS 1 course. TRANSITS is affordable, high-quality training for both new and experienced Computer Security Incident Response Team (CSIRT) personnel.
On October 25, ROS volunteer Harm Boertien gave a presentation at T-Dose, which is a free annual event held in The Netherlands to promote use and development of Open Source Software. He described what Radical Open Security is all about and how volunteers can participate in project S-BOX.
On October 28, ROS co-founder Peter Geissler gave a Cloud Security talk at Holland Strikes Back, a conference highlighting Dutch initiatives against cyber attacks and abuse, organized by NLnet, ISPConnect, Dutch Hosting Provider Association and AlertOnline.

If you would like one of our security experts to talk or teach at your conference or activity, please contact us!

SBox: Usable Privacy and Anonymity for Journalists

2014-10-02T00:00:00+00:00

Radically Open Security is off to a great start! Within months of registering our new company with the Chamber of Commerce, we have 4 client engagements, and even more gigs rolling in! But what we’re happiest about is that those projects mean the start of our organization’s ability to begin giving back to the community via our open source ethos and non-profit business model.

Today I’m excited to let everyone know about a new project to create useful open-source things for the whole community. We’ve been engaged by the Internet Protection Lab - a collaboration between Free Press Unlimited, Hivos and Greenhost - dedicated to preserving press freedom and access to information worldwide. The Internet Protection Lab has asked Radically Open Security to help create technology that allows journalists and activists to connect to the internet safely in an easy way, and we need your help!

What’s this thing we’re working on? We’re still in the specification stages, but let me introduce you to the SBox. We plan to build a low-cost physical device that acts like a wifi hotspot that transparently creates a VPN tunnel or connection to the Tor network for standard end-point devices. As the user, you just connect your device to the hotspot’s Wifi, log in, and begin browsing, sending email, etc. Under the hood, the SBox will then transparently create a VPN tunnel and/or a connection to the Tor network, thus preventing the end user’s communications from being watched, and protecting the users’ identity from observers.

This is a community project.. we’re going to need help to make this happen! Here’s what you can do to help us and Free Press Unlimited protect journalists and other activists:

Security professionals: the security architecture and protocols, and security analysis of the device’s operations and user modes will be a challenge. As usual, key and certificate management will be difficult to get right. We’ll need to ensure that physical compromise of the device doesn’t mean total loss of the journalists’ data, location, and identity. We’ll need to carefully scope what the device can do and CAN’T do. And platform/application security of the SBox itself will need to be audited. We’ll need many many sets of eyes to get these things right...
Devops/Programming experts: we need to create the requirements and specs, and then hunt for an appropriate low-cost (preferably <$50) HW platform on which to build. We’ll have to consider existing open-source SW projects that solve similar problems (i.e. OnionPi, Grugq’s Portal, Safeplug), and see if we can build upon them. And we’ll need to make our platform usable and easy to configure.
Community organizers: We need help spreading the word about this project, recruiting more volunteers to work on it and folks to help us make our in real life events flow smoothly.
Users: As we start to have our first prototypes, we’ll want live feedback from the field about usability and security of the system. We’re looking for feedback from expert technologists and every day users, alike. Bonus points if you have experience as a journalist or activist!

So how can you help?

Come to our first volunteer meetup and hackathon this Friday, October 3rd. We’ll convene from 6-10 PM at the Tech Inc hackerspace in Amsterdam to work on requirements gathering and exploring what technical resources already exist that we can use. If you’re not a coder, no worries! Turn up anyway, as we’ll want a chance to get to know you and figure out where you can best lend your skills in marketing, testing or any other way you’d like to contribute.

Looking forward to seeing you on Friday! If you can’t make it, we’ll have even more hackathons and volunteer meetups coming soon. Stay tuned to this space.

Featured in NRC Handelsblad

2014-03-27T00:00:00+00:00

Radically Open Security's CEO Melanie Rieback was featured in Dutch newspaper "NRC Handelsblad" in an article "Leave the hacking to the women", talking about the need for female role models in cyber defense. The article was written by journalist Laura Wismans

Read the article on the website of NRC

Laat het hacken maar aan de vrouwen over

Typisch vrouwen: niet mee willen doen aan een hackwedstrijd omdat ze denken dat de teams met mannen toch veel beter zijn. Er was wat overredingskracht voor nodig, maar vanaf morgenochtend 10.00 uur gaan twee teams van drie vrouwen er helemaal voor.

Dan begint de Capture the Flag-hackcompetitie op cyber-securityconferentie Hack in the Box in de Amsterdamse Beurs van Berlage. Twee dagen lang gaan ze inlogcodes kraken, documenten decoderen en inbreken op speciaal voor de wedstrijd opgezette websites. Nog nooit eerder deed een vrouwenteam mee aan deze hackcompetitie.

Vorig jaar op Hack in the Box: Zo hack je een vliegtuig.

Technologie is een mannenwereld en cyber security al helemaal. In Europa is zo’n 7 procent van de mensen in de cyber security vrouw – die in marketingposities meegerekend. Dat viel Anouk Vos en Iowa Carels ook op. Daarom richtten ze begin 2013 hun netwerkgroep Women in Cyber Security op.

Voor de gezelligheid, maar ook om anderen duidelijk te maken dat ze bestaan. En dat ze niet onderdoen voor de mannen in hun sector. Hun netwerk bestaat nu uit bijna driehonderd vrouwen, uit Nederland en daarbuiten.

Alle keynotes door vrouwen

Het is niet toevallig dat de vrouwen juist deze conferentie hebben uitgekozen om mee te doen aan Capture the Flag. De organisatoren van Hack in the Box hebben er dit jaar werk van gemaakt om alle keynote speeches door vrouwen te laten doen. Ongekend! De Women in Cyber Security wilden niet achterblijven en dus kregen alle leden een e-mail: wie wil meedoen aan de hackwedstrijd?

Melanie Rieback zei direct ja. Ze ontdekte Capture the Flag (CTF) afgelopen november als nieuwe hobby. Ze heeft haar eigen beveiligingsbedrijf en werkte eerder onder meer op de beveiligingsafdeling van ING. De hackwedstrijden ziet ze als goede aanvulling op haar werk.

Rolmodellen voor meisjeshackers

Pakken vrouwen de opgaven anders aan dan mannen? Nee, denkt Rieback. “Maar vrouwen geven wel sneller op”, zegt een van de vrouwen tijdens een oefensessie. “Ja, die denken eerder dat het toch niet gaat lukken”, zegt hacker Esther (die haar achternaam niet wil geven).

Rieback wil niet van opgeven horen. Ze vindt dat gepraat over vrouwen en mannen eigenlijk ook maar onzin. Vrouwen kunnen hetzelfde als mannen. Het netwerk, en ook de deelname van dit team, vindt ze vooral belangrijk om dat te laten zien. Meisjeshackers moeten vaker rolmodel zijn.

Afgelopen zondag kwamen de vrouwen voor het laatst bij elkaar. De laatste tactieken zijn doorgesproken. Rieback is realistisch en acht de kans op de hoofdprijs niet groot. “Maar dat betekent niet meteen dat we laatste worden hoor”, zegt ze. Deze CTF zien de vrouwen vooral als een startpunt; ze gaan vanaf nu aan meer competities meedoen. Op de trainingsavond mijmeren ze: “zou een internationaal vrouwenteam niet gaaf zijn?”