CORS Misconfigurations On A Large Scale

Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers.

The issue: CORS misconfiguration

Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misconfigurations which can potentially be exploited. For more technical details on the issues read the this fine blogpost.

Misconfiguation	Description
Developer backdoor	Insecure developer/debug origins like JSFiddler CodePen are allowed to access the resource
Origin reflection	The origin is simply echoed in ACAO header, any site is allowed to access the resource
Null misconfiguration	Any site is allowed access by forcing the null origin via a sandboxed iframe
Pre-domain wildcard	notdomain.com is allowed access, which can simply be registered by the attacker
Post-domain wildcard	domain.com.evil.com is allowed access, can be simply be set up by the attacker
Subdomains allowed	sub.domain.com allowed access, exploitable if the attacker finds XSS in any subdomain
Non-SSL sites allowed	An HTTP origin is allowed access to a HTTPS resource, allows MitM to break encryption
Invalid CORS header	Wrong use of wildcard or multiple origins,not a security problem but should be fixed

The tool: CORStest

Testing for such vulnerabilities can easily be done with curl(1). To support some more options like, for example, parallelization we wrote CORStest, a simple Python based CORS misconfiguration checker. It takes a text file containing a list of domain names or URLs to check for misconfigurations as input and supports some further options:

usage: corstest.py [arguments] infile

positional arguments:
  infile         File with domain or URL list

optional arguments:
  -h, --help     show this help message and exit
  -c name=value  Send cookie with all requests
  -p processes   multiprocessing (default: 32)
  -s             always force ssl/tls requests
  -q             quiet, allow-credentials only
  -v             produce a more verbose output

CORStest can detect potential vulnerabilities by sending various Origin request headers and checking for the Access-Control-Allow-Origin response. An example for those of the Alexa top 750 websites which allow credentials for CORS requests is given below.

Evaluation with Alexa top 1 Million websites

To evaluate – on a larger scale – how many sites actually have wide-open CORS configurations we did run CORStest on the Alexa top 1 million sites:

$ git clone https://github.com/RUB-NDS/CORStest.git && cd cors/
$ wget -q http://s3.amazonaws.com/alexa-static/top-1m.csv.zip
$ unzip top-1m.csv.zip
$ awk -F, '{print $2}' top-1m.csv > alexa.txt
$ ./corstest.py alexa.txt

This test took about 14 hours on a decent connection and revealed the following results:

Only 29,514 websites (about 3%) actually supported CORS on their main page (aka. responded with Access-Control-Allow-Origin). Of course, many sites such as Google do only enable CORS headers for certain resources, not directly on their landing page. We could have crawled all websites (including subdomains) and fed the input to CORStest. However, this would have taken a long time and for statistics, our quick & dirty approach should still be fine. Furthermore it must be noted that the test was only performed with GET requests (without any CORS preflight) to the http:// version of websites (with redirects followed). Note that just because a website, for example, reflects the origin header it is not necessarily vulnerable. The context matters; such a configuration can be totally fine for a public sites or API endpoints intended to be accessible by everyone. It can be disastrous for payment sites or social media platforms. Furthermore, to be actually exploitable the Access-Control-Allow-Credentials: true (ACAC) header must be set. Therefore we repeated the test, this time limited to sites that return this header (see CORStest -q flag):

$ ./corstest.py -q alexa.txt

This revealed even worse results - almost half of the websites supporting ACAO and ACAC headers contained a CORS misconfigurations that could be exploited directly by a web attacker (developer backdoor, origin reflection, null misconfig, pre-/post-domain wildcard):

The Impact: SOP/SSL bypass on payment and taxpayer sites

Note that not all tested websites actually were exploitable. Some contained only public data and some others - such as Bitbucket - had CORS enabled for their main page but not for subpages containing user data. Manually testing the sites, we found to be vulnerable:

• A dozen of online banking, bitcoin and other payment sites; one of them allowed us to create a test account so we were able to write proof-of-concept code which could actually have been used to steal money
• Hundred of online shops/e-commerce sites and a bunch of hotel/flight booking sites
• Various social networks and misc sites which allow users to log in and communicate
• One US state's tax filing website (however, this one was exploitable by a MitM only)

We informed all sites we manually tested and found to be vulnerable. A simple exploit code example when logged into a website with CORS origin reflection is given below.

The Reason: Copy & Paste and broken frameworks

We were further interested in reasons for CORS misconfigurations. Particularly we wanted to learn if there is a correlation between applied technology and misconfiguration. Therefore we used WhatWeb to fingerprint the web technologies for all vulnerable sites. CORS is usually enabled either directly in the HTTP server configuration or by the web application/framework. While we could not identify a single major cause for CORS misconfigurations, we found various potential reasons. A majority of dangerous Access-Control-* headers had probably been introduced by developers, others however are based on bugs and bad practices in some products. Insights follow:

• Various websites return invalid CORS headers; besides wrong use of wildcards such as *.domain.com, ACAO headers which contain multiple origins can often be found; Other examples of invalid - but quite creative - ACAO values we observed are: self, true, false, undefined, None, 0, (null), domain, origin, SAMEORIGIN
• Rack::Cors, the de facto standard library to enable CORS for Ruby on Rails maps origins '' or origins '*' into reflecting arbitrary origins; this is dangerous, because developers would think that '' allows nothing and '*' behaves according to the spec: mostly harmless because it cannot be used to make to make 'credentialed' requests; this config error leads to origin reflection with ACAC headers on about a hundred of the tested and vulnerable websites
• A majority of websites which allow a http origin to CORS access a https resource are run on IIS; this seems to be no bug in IIS itself but rather caused by bad advises found on the Internet
• nginx is the winner when it comes serving websites with origin reflections; again, this is not an issue of nginx but of dangerous configs copied from "Stackoverflow; same problem for Phusion Passenger
• The null ACAO value may be based on programming languages that simply return null if no value is given (we haven't found any specific framework though); another explanation is that 'CORS in Action', a popular book on CORS, contains various examples with code such as var originWhitelist = ['null', ...], which could be misinterpreted by developers as safe
• If CORS is enabled in the crVCL PHP Framework, it adds ACAC and ACAO headers for a configured domain. Unfortunatelly, it also introduces a post-domain and pre-subdomain wildcard vulnerability: sub.domain.com.evil.com
• All sites that are based on "Solo Build It!" (scam?) respond with: Access-Control-Allow-Origin: http://sbiapps.sitesell.com
• Some sites have :// or // as fixed ACAO values. How should browsers deal with this? Inconsistent at least! Firefox, Chrome, Safari and Opera allow arbitrary origins while IE and Edge deny all origins.

Related word

• Growth Hacking Marketing
• Hacking Web
• Escuela Travel Hacking
• Elladodelmal
• Hacking With Swift
• Hacking Wifi
• Hacking Tor Funciona
• Hacking Etico Certificacion
• Hacking Etico 101 Pdf
• Hacking Food
• Python Hacking

Playing With TLS-Attacker

In the last two years, we changed the TLS-Attacker Project quite a lot but kept silent about most changes we implemented. Since we do not have so much time to keep up with the documentation (we are researchers and not developers in the end), we thought about creating a small series on some of our recent changes to the project on this blog.

We hope this gives you an idea on how to use the most recent version (TLS-Attacker 2.8). If you feel like you found a bug, don't hesitate to contact me via GitHub/Mail/Twitter. This post assumes that you have some idea what this is all about. If you have no idea, checkout the original paper from Juraj or our project on GitHub.

TLDR: TLS-Attacker is a framework which allows you to send arbitrary protocol flows.


Quickstart:
# Install & Use Java JDK 8
$ sudo apt-get install maven
$ git clone https://github.com/RUB-NDS/TLS-Attacker
$ cd TLS-Attacker
$ mvn clean package

So, what changed since the release of the original paper in 2016? Quite a lot! We discovered that we could make the framework much more powerful by adding some new concepts to the code which I want to show you now.

Action System

In the first Version of TLS-Attacker (1.x), WorkflowTraces looked like this:

	<workflowTrace>
	<protocolMessages>
	<ClientHello>
	<messageIssuer>CLIENT</messageIssuer>
	<extensions>
	<EllipticCurves>
	<supportedCurvesConfig>SECP192R1</supportedCurvesConfig>
	<supportedCurvesConfig>SECP256R1</supportedCurvesConfig>
	</EllipticCurves>
	<ECPointFormat>
	<pointFormatsConfig>UNCOMPRESSED</pointFormatsConfig>
	</ECPointFormat>
	</extensions>
	<supportedCompressionMethods>
	<CompressionMethod>NULL</CompressionMethod>
	</supportedCompressionMethods>
	<supportedCipherSuites>
	<CipherSuite>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</CipherSuite>
	<CipherSuite>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</CipherSuite>
	<CipherSuite>TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA</CipherSuite>
	</supportedCipherSuites>
	</ClientHello>
	<ServerHello>
	<messageIssuer>SERVER</messageIssuer>
	</ServerHello>
	<Certificate>
	<messageIssuer>SERVER</messageIssuer>
	</Certificate>
	<ECDHEServerKeyExchange>
	<messageIssuer>SERVER</messageIssuer>
	</ECDHEServerKeyExchange>
	<ServerHelloDone>
	<messageIssuer>SERVER</messageIssuer>
	</ServerHelloDone>
	<ECDHClientKeyExchange>
	<messageIssuer>CLIENT</messageIssuer>
	</ECDHClientKeyExchange>
	<ChangeCipherSpec>
	<messageIssuer>CLIENT</messageIssuer>
	</ChangeCipherSpec>
	<Finished>
	<messageIssuer>CLIENT</messageIssuer>
	</Finished>
	<ChangeCipherSpec>
	<messageIssuer>SERVER</messageIssuer>
	</ChangeCipherSpec>
	<Finished>
	<messageIssuer>SERVER</messageIssuer>
	</Finished>
	</protocolMessages>
	</workflowTrace>

view raw tls-attacker1.0.trace.xml hosted with ❤ by GitHub

Although this design looks straight forward, it lacks flexibility. In this design, a WorkflowTrace is basically a list of messages. Each message is annotated with a <messageIssuer>, to tell TLS-Attacker that it should either try to receive this message or send it itself. If you now want to support more advanced workflows, for example for renegotiation or session resumption, TLS-Attacker will soon reach its limits. There is also a missing angle for fuzzing purposes. TLS-Attacker will by default try to use the correct parameters for the message creation, and then apply the modifications afterward. But what if we want to manipulate parameters of the connection which influence the creation of messages? This was not possible in the old version, therefore, we created our action system. With this action system, a WorkflowTrace does not only consist of a list of messages but a list of actions. The most basic actions are the Send- and ReceiveAction. These actions allow you to basically recreate the previous behavior of TLS-Attacker 1.x . Here is an example to show how the same workflow would look like in the newest TLS-Attacker version:

	<workflowTrace>
	<Send>
	<messages>
	<ClientHello>
	<extensions>
	<ECPointFormat/>
	<EllipticCurves/>
	</extensions>
	</ClientHello>
	</messages>
	</Send>
	<Receive>
	<expectedMessages>
	<ServerHello/>
	<Certificate/>
	<ECDHEServerKeyExchange/>
	<ServerHelloDone/>
	</expectedMessages>
	</Receive>
	<Send>
	<messages>
	<ECDHClientKeyExchange/>
	<ChangeCipherSpec/>
	<Finished/>
	</messages>
	</Send>
	<Receive>
	<expectedMessages>
	<ChangeCipherSpec/>
	<Finished/>
	</expectedMessages>
	</Receive>
	</workflowTrace>

view raw tls-attacker2.0.trace.xml hosted with ❤ by GitHub

As you can see, the <messageIssuer> tags are gone. Instead, you now indicate with the type of action how you want to deal with the message. Another important thing: TLS-Attacker uses WorkflowTraces as an input as well as an output format. In the old version, once a WorkflowTrace was executed it was hard to see what actually happened. Especially, if you specify what messages you expect to receive. In the old version, your WorkflowTrace could change during execution. This was very confusing and we, therefore, changed the way the receiving of messages works. The ReceiveAction has a list of <expectedMessages>. You can specify what you expect the other party to do. This is mostly interesting for performance tricks (more on that in another post), but can also be used to validate that your workflow executedAsPlanned. Once you execute your ReceiveAction an additional <messages> tag will pop up in the ReceiveAction to show you what has actually been observed. Your original WorkflowTrace stays intact.

	<Receive>
	<executed>true</executed>
	<connectionAlias>client</connectionAlias>
	<messages>
	<ChangeCipherSpec>
	<completeResultingMessage>
	<originalValue>01</originalValue>
	</completeResultingMessage>
	<ccsProtocolType>
	<originalValue>1</originalValue>
	</ccsProtocolType>
	</ChangeCipherSpec>
	<Finished>
	<completeResultingMessage/>
	<type>
	<originalValue>20</originalValue>
	</type>
	<length>
	<originalValue>12</originalValue>
	</length>
	<verifyData>
	<originalValue>1B 54 13 E1 4D 97 8F 31 AD 5B 6B 6C</originalValue>
	</verifyData>
	</Finished>
	</messages>
	<expectedMessages>
	<ChangeCipherSpec/>
	<Finished/>
	</expectedMessages>
	</Receive>

view raw executed_action.xml hosted with ❤ by GitHub

During the execution, TLS-Attacker will execute the actions one after the other. There are specific configuration options with which you can control what TLS-Attacker should do in the case of an error. By default, TLS-Attacker will never stop, and just execute whatever is next.

Configs

As you might have seen the <messageIssuer> tags are not the only thing which is missing. Additionally, the cipher suites, compression algorithms, point formats, and supported curves are missing. This is no coincidence. A big change in TLS-Attacker 2.x is the separation of the WorkflowTrace from the parameter configuration and the context. To explain how this works I have to talk about how the new TLS-Attacker version creates messages. Per default, the WorkflowTrace does not contain the actual contents of the messages. But let us step into TLS-Attackers point of view. For example, what should TLS-Attacker do with the following WorkflowTrace:

	<workflowTrace>
	<Send>
	<messages>
	<RSAClientKeyExchange/>
	</messages>
	</Send>
	</workflowTrace>

view raw invalid_example.xml hosted with ❤ by GitHub

Usually, the RSAClientKeyExchange message is constructed with the public key from the received certificate message. But in this WorkflowTrace, we did not receive a certificate message yet. So what public key are we supposed to use? The previous version had "some" key hardcoded. The new version does not have these default values hardcoded but allows you as the user to define the default values for missing values, or how our own messages should be created. For this purpose, we introduced the new concept of Configs. A Config is a file/class which you can provide to TLS-Attacker in addition to a WorkflowTrace, to define how TLS-Attacker should behave, and how TLS-Attacker should create its messages (even in the absence of needed parameters). For this purpose, TLS-Attacker has a default Config, with all the known hardcoded values. It is basically a long list of possible parameters and configuration options. We chose sane values for most things, but you might have other ideas on how to do things. You can execute a WorkflowTrace with a specific config. The provided Config will then overwrite all existing default values with your specified values. If you do not specify a certain value, the default value will be used. I will get back to how Configs work, once we played a little bit with TLS-Attacker.

TLS-Attacker ships with a few example applications (found in the "apps/" folder after you built the project). While TLS-Attacker 1.x was mostly a standalone tool, we currently see TLS-Attacker more as a library which we can use by our more sophisticated projects. The current example applications are:

• TLS-Client (A TLS-Client to execute WorkflowTraces with)
• TLS-Server (A TLS-Server to execute WorkflowTraces with)
• Attacks (We'll talk about this in another blog post)
• TLS-Forensics (We'll talk about this in another blog post)
• TLS-Mitm (We'll talk about this in another blog post)
• TraceTool (We'll talk about this in another blog post) 

TLS-Client

The TLS-Client is a simple TLS-Client. Per default, it executes a handshake for the default selected cipher suite (RSA). The only mandatory parameter is the server you want to connect to (-connect).

The most trivial command you can start it with is:

java -jar TLS-Client.jar -connect somehost.com:443

view raw command1.sh hosted with ❤ by GitHub

Note: The example tool does not like "https://" or other protocol information. Just provide a hostname and port

Depending on the host you chose your output might look like this:

	12:48:36 [main] INFO : DefaultWorkflowExecutor - Connecting to somehost.com:443
	12:48:36 [main] INFO : SendAction - Sending messages (client): CLIENT_HELLO,
	12:48:36 [main] INFO : ReceiveAction - Received Messages (client): SERVER_HELLO, CERTIFICATE, SERVER_HELLO_DONE,
	12:48:36 [main] INFO : SendAction - Sending messages (client): RSA_CLIENT_KEY_EXCHANGE, CHANGE_CIPHER_SPEC, FINISHED,
	12:48:36 [main] INFO : ReceiveAction - Received Messages (client): CHANGE_CIPHER_SPEC, FINISHED,

view raw output1 hosted with ❤ by GitHub

or like this:

	12:48:23 [main] INFO : DefaultWorkflowExecutor - Connecting to somehost.com:443
	12:48:23 [main] INFO : SendAction - Sending messages (client): CLIENT_HELLO,
	12:48:25 [main] INFO : ReceiveAction - Received Messages (client): SERVER_HELLO, CERTIFICATE, ECDHE_SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE,
	12:48:25 [main] INFO : SendAction - Sending messages (client): RSA_CLIENT_KEY_EXCHANGE, CHANGE_CIPHER_SPEC, FINISHED,
	12:48:25 [main] INFO : ReceiveAction - Received Messages (client): Alert(FATAL,DECODE_ERROR),

view raw output2 hosted with ❤ by GitHub

So what is going on here? Let's start with the first execution. As I already mentioned. TLS-Attacker constructs the default WorkflowTrace based on the default selected cipher suite. When you run the client, the WorkflowExecutor (part of TLS-Attacker which is responsible for the execution of a WorkflowTrace) will try to execute the handshake. For this purpose, it will first start the TCP connection.
This is what you see here:

12:48:36 [main] INFO : DefaultWorkflowExecutor - Connecting to somehost.com:443

view raw output5 hosted with ❤ by GitHub

After that, it will execute the actions specified in the default WorkflowTrace. The default WorkflowTrace looks something like this:

	<workflowTrace>
	<Send>
	<messages>
	<ClientHello>
	<extensions>
	<ECPointFormat/>
	<EllipticCurves/>
	<SignatureAndHashAlgorithmsExtension/>
	<RenegotiationInfoExtension/>
	</extensions>
	</ClientHello>
	</messages>
	</Send>
	<Receive>
	<expectedMessages>
	<ServerHello/>
	<Certificate/>
	<ServerHelloDone/>
	</expectedMessages>
	</Receive>
	<Send>
	<messages>
	<RSAClientKeyExchange/>
	<ChangeCipherSpec/>
	<Finished/>
	</messages>
	</Send>
	<Receive>
	<expectedMessages>
	<ChangeCipherSpec/>
	<Finished/>
	</expectedMessages>
	</Receive>
	</workflowTrace>

view raw default_workflow_trace.xml hosted with ❤ by GitHub

This is basically what you see in the console output. The first action which gets executed is the SendAction with the ClientHello.

12:48:23 [main] INFO : SendAction - Sending messages (client): CLIENT_HELLO,

view raw output7 hosted with ❤ by GitHub

Then, we expect to receive messages. Since we want to be an RSA handshake, we do not expect a ServerKeyExchange message, but only want a ServerHello, Certificate and a ServerHelloDone message.

12:48:36 [main] INFO : ReceiveAction - Received Messages (client): SERVER_HELLO, CERTIFICATE, SERVER_HELLO_DONE,

view raw output6 hosted with ❤ by GitHub

We then execute the second SendAction:

12:48:36 [main] INFO : SendAction - Sending messages (client): RSA_CLIENT_KEY_EXCHANGE, CHANGE_CIPHER_SPEC, FINISHED,

view raw output8 hosted with ❤ by GitHub

and finally, we want to receive a ChangeCipherSpec and Finished Message:

12:48:36 [main] INFO : ReceiveAction - Received Messages (client): CHANGE_CIPHER_SPEC, FINISHED,

view raw output9 hosted with ❤ by GitHub

In the first execution, these steps all seem to have worked. But why did they fail in the second execution? The reason is that our default Config does not only allow specify RSA cipher suites but creates ClientHello messages which also contain elliptic curve cipher suites. Depending on the server you are testing with, the server will either select and RSA cipher suite, or an elliptic curve one. This means, that the WorkflowTrace will not executeAsPlanned. The server will send an additional ECDHEServerKeyExchange. If we would look at the details of the ServerHello message we would also see that an (ephemeral) elliptic curve cipher suite is selected:

12:48:25 [main] INFO : ReceiveAction - Received Messages (client): SERVER_HELLO, CERTIFICATE, ECDHE_SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE,

view raw output10 hosted with ❤ by GitHub

Since our WorkflowTrace is configured to send an RSAClientKeyExchange message next, it will just do that:

12:48:36 [main] INFO : SendAction - Sending messages (client): RSA_CLIENT_KEY_EXCHANGE, CHANGE_CIPHER_SPEC, FINISHED,

view raw output8 hosted with ❤ by GitHub

Note: ClientKeyExchangeMessage all have the same type field, but are implemented inside of TLS-Attacker as different messages

Since this RSAClientKeyExchange does not make a lot of sense for the server, it rejects this message with a DECODE_ERROR alert:

12:48:25 [main] INFO : ReceiveAction - Received Messages (client): Alert(FATAL,DECODE_ERROR),

view raw output11 hosted with ❤ by GitHub

If we would change the Config of TLS-Attacker, we could change the way our ClientHello is constructed. If we specify only RSA cipher suites, the server has no choice but to select an RSA one (or immediately terminate the connection). We added command line flags for the most common Config changes. Let's try to change the default cipher suite to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:

java -jar TLS-Client.jar -connect somesever.com -cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

view raw command2.sh hosted with ❤ by GitHub

	13:48:36 [main] INFO : DefaultWorkflowExecutor - Connecting to someserver.com:443
	13:48:36 [main] INFO : SendAction - Sending messages (client): CLIENT_HELLO,
	13:48:36 [main] INFO : ReceiveAction - Received Messages (client): SERVER_HELLO, CERTIFICATE, ECDHE_SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE,
	13:48:36 [main] INFO : SendAction - Sending messages (client): ECDH_CLIENT_KEY_EXCHANGE, CHANGE_CIPHER_SPEC, FINISHED,
	13:48:36 [main] INFO : ReceiveAction - Received Messages (client): CHANGE_CIPHER_SPEC, FINISHED,

view raw output3 hosted with ❤ by GitHub

As you can see, we now executed a complete ephemeral elliptic curve handshake. This is, because the -cipher flag changed the <defaultSelectedCiphersuite> parameter (among others) in the Config. Based on this parameter the default WorkflowTrace is constructed. If you want, you can specify multiple cipher suites at once, by seperating them with a comma.

java -jar TLS-Client.jar -connect someserver.com -cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

view raw command3.sh hosted with ❤ by GitHub

We can do the same change by supplying TLS-Attacker with a custom Config via XML. To this we need to create a new file (I will name it config.xml) like this:

	<Config>
	<defaultSelectedCipherSuite>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</defaultSelectedCipherSuite>
	</Config>

view raw config_example.xml hosted with ❤ by GitHub

You can then load the Config with the -config flag:

java -jar TLS-Client.jar -connect somehost.com -config config.xml

view raw command4.sh hosted with ❤ by GitHub

For a complete reference of the supported Config options, you can check out the default_config.xml. Most Config options should be self-explanatory, for others, you might want to check where and how they are used in the code (sorry).

Now let's try to execute an arbitrary WorkflowTrace. To do this, we need to store our WorkflowTrace in a file and load it with the -workflow_input parameter. I just created the following WorkflowTrace:

	<workflowTrace>
	<Send>
	<messages>
	<ServerHello/>
	</messages>
	</Send>
	<Receive>
	<expectedMessages>
	<ServerHello/>
	<Certificate/>
	<ServerHelloDone/>
	</expectedMessages>
	</Receive>
	</workflowTrace>

view raw double_server_hello.xml hosted with ❤ by GitHub

As you can see I just send a ServerHello message instead of a ClientHello message at the beginning of the handshake. This should obviously never happen but let's see how the tested server reacts to this.
We can execute the workflow with the following command:

java -jar TLS-Client.jar -connect google.com -workflow_input trace.xml -workflow_output out.xml

view raw command5.sh hosted with ❤ by GitHub

	14:13:13 [main] INFO : DefaultWorkflowExecutor - Connecting to localhost:443
	14:13:14 [main] INFO : SendAction - Sending messages (client): SERVER_HELLO,
	14:13:14 [main] INFO : ReceiveAction - Received Messages (client): Alert(FATAL,UNEXPECTED_MESSAGE),

view raw output4 hosted with ❤ by GitHub

The server (correctly) responded with an UNEXPECTED_MESSAGE alert. Great!

Output parameters & Modifications

You are now familiar with the most basic concepts of TLS-Attacker, so let's dive into other things TLS-Attacker can do for you. As a TLS-Attacker user, you are sometimes interested in the actual values which are used during a WorkflowTrace execution. For this purpose, we introduced the -workflow_output flag. With this parameter, you can ask TLS-Attacker to store the executed WorkflowTrace with all its values in a file.
Let's try to execute our last created WorkflowTrace, and store the output WorkflowTrace in the file out.xml:

java -jar TLS-Client.jar -connect google.com -workflow_input trace.xml -workflow_output out.xml

view raw command7.sh hosted with ❤ by GitHub

The resulting WorkflowTrace looks like this:

	<workflowTrace>
	<Send>
	<executed>true</executed>
	<messages>
	<ServerHello>
	<completeResultingMessage>
	<originalValue>
	02 00 00 28 03 03 91 2F DD C9 60 B4 20 BB 38 51
	D9 D4 7A CB 93 3D BE 70 39 9B F6 C9 2D A3 3A F0
	1D 4F B7 70 E9 8C 00 00 0A 00 00 00
	</originalValue>
	</completeResultingMessage>
	<type>
	<originalValue>2</originalValue>
	</type>
	<length>
	<originalValue>40</originalValue>
	</length>
	<extensionBytes>
	<originalValue/>
	</extensionBytes>
	<extensionsLength>
	<originalValue>0</originalValue>
	</extensionsLength>
	<protocolVersion>
	<originalValue>03 03</originalValue>
	</protocolVersion>
	<unixTime>
	<originalValue>91 2F DD C9</originalValue>
	</unixTime>
	<random>
	<originalValue>
	91 2F DD C9 60 B4 20 BB 38 51 D9 D4 7A CB 93 3D
	BE 70 39 9B F6 C9 2D A3 3A F0 1D 4F B7 70 E9 8C
	</originalValue>
	</random>
	<sessionIdLength>
	<originalValue>0</originalValue>
	</sessionIdLength>
	<sessionId>
	<originalValue/>
	</sessionId>
	<selectedCipherSuite>
	<originalValue>00 0A</originalValue>
	</selectedCipherSuite>
	<selectedCompressionMethod>
	<originalValue>0</originalValue>
	</selectedCompressionMethod>
	</ServerHello>
	</messages>
	<records>
	<Record>
	<cleanProtocolMessageBytes>
	<originalValue>
	02 00 00 28 03 03 91 2F DD C9 60 B4 20 BB 38 51
	D9 D4 7A CB 93 3D BE 70 39 9B F6 C9 2D A3 3A F0
	1D 4F B7 70 E9 8C 00 00 0A 00 00 00
	</originalValue>
	</cleanProtocolMessageBytes>
	<completeRecordBytes>
	<originalValue>
	16 03 03 00 2C 02 00 00 28 03 03 91 2F DD C9 60
	B4 20 BB 38 51 D9 D4 7A CB 93 3D BE 70 39 9B F6
	C9 2D A3 3A F0 1D 4F B7 70 E9 8C 00 00 0A 00 00
	00
	</originalValue>
	</completeRecordBytes>
	<contentMessageType>HANDSHAKE</contentMessageType>
	<maxRecordLengthConfig>1048576</maxRecordLengthConfig>
	<protocolMessageBytes>
	<originalValue>
	02 00 00 28 03 03 91 2F DD C9 60 B4 20 BB 38 51
	D9 D4 7A CB 93 3D BE 70 39 9B F6 C9 2D A3 3A F0
	1D 4F B7 70 E9 8C 00 00 0A 00 00 00
	</originalValue>
	</protocolMessageBytes>
	<computations>
	<authenticatedMetaData>
	<originalValue>00 00 00 00 00 00 00 00 16 03 03 00 2C</originalValue>
	</authenticatedMetaData>
	<mac>
	<originalValue/>
	</mac>
	<nonMetaDataMaced>
	<originalValue>
	02 00 00 28 03 03 91 2F DD C9 60 B4 20 BB 38 51
	D9 D4 7A CB 93 3D BE 70 39 9B F6 C9 2D A3 3A F0
	1D 4F B7 70 E9 8C 00 00 0A 00 00 00
	</originalValue>
	</nonMetaDataMaced>
	<padding>
	<originalValue/>
	</padding>
	<paddingLength>
	<originalValue>0</originalValue>
	</paddingLength>
	<plainRecordBytes>
	<originalValue>
	02 00 00 28 03 03 91 2F DD C9 60 B4 20 BB 38 51
	D9 D4 7A CB 93 3D BE 70 39 9B F6 C9 2D A3 3A F0
	1D 4F B7 70 E9 8C 00 00 0A 00 00 00
	</originalValue>
	</plainRecordBytes>
	<sequenceNumber>
	<originalValue>0</originalValue>
	</sequenceNumber>
	<unpaddedRecordBytes>
	<originalValue>
	02 00 00 28 03 03 91 2F DD C9 60 B4 20 BB 38 51
	D9 D4 7A CB 93 3D BE 70 39 9B F6 C9 2D A3 3A F0
	1D 4F B7 70 E9 8C 00 00 0A 00 00 00
	</originalValue>
	</unpaddedRecordBytes>
	</computations>
	<contentType>
	<originalValue>22</originalValue>
	</contentType>
	<length>
	<originalValue>44</originalValue>
	</length>
	<protocolVersion>
	<originalValue>03 03</originalValue>
	</protocolVersion>
	</Record>
	</records>
	</Send>
	<Receive>
	<executed>true</executed>
	<messages>
	<Alert>
	<completeResultingMessage>
	<originalValue>02 0A</originalValue>
	</completeResultingMessage>
	<level>
	<originalValue>2</originalValue>
	</level>
	<description>
	<originalValue>10</originalValue>
	</description>
	</Alert>
	</messages>
	<records>
	<Record>
	<cleanProtocolMessageBytes>
	<originalValue>02 0A</originalValue>
	</cleanProtocolMessageBytes>
	<completeRecordBytes>
	<originalValue>15 03 01 00 02 02 0A</originalValue>
	</completeRecordBytes>
	<contentMessageType>ALERT</contentMessageType>
	<protocolMessageBytes>
	<originalValue>02 0A</originalValue>
	</protocolMessageBytes>
	<computations>
	<authenticatedMetaData>
	<originalValue>00 00 00 00 00 00 00 00 15 03 01 00 02</originalValue>
	</authenticatedMetaData>
	<initialisationVector/>
	<mac>
	<originalValue/>
	</mac>
	<nonMetaDataMaced>
	<originalValue>02 0A</originalValue>
	</nonMetaDataMaced>
	<padding>
	<originalValue/>
	</padding>
	<paddingLength>
	<originalValue>0</originalValue>
	</paddingLength>
	<plainRecordBytes>
	<originalValue>02 0A</originalValue>
	</plainRecordBytes>
	<sequenceNumber>
	<originalValue>0</originalValue>
	</sequenceNumber>
	<unpaddedRecordBytes>
	<originalValue>02 0A</originalValue>
	</unpaddedRecordBytes>
	</computations>
	<contentType>
	<originalValue>21</originalValue>
	</contentType>
	<length>
	<originalValue>2</originalValue>
	</length>
	<protocolVersion>
	<originalValue>03 01</originalValue>
	</protocolVersion>
	</Record>
	</records>
	<expectedMessages>
	<ServerHello/>
	<Certificate/>
	<ServerHelloDone/>
	</expectedMessages>
	</Receive>
	</workflowTrace>

view raw full_double_server_hello.xml hosted with ❤ by GitHub

As you can see, although the input WorkflowTrace was very short, the output trace is quite noisy. TLS-Attacker will display all its intermediate values and modification points (this is where the modifiable variable concept becomes interesting). You can also execute the output workflow again.

java -jar TLS-Client.jar -connect somehost.com -workflow_input out.xml

view raw command8.sh hosted with ❤ by GitHub

Note that at this point there is a common misunderstanding: TLS-Attacker will reset the WorkflowTrace before it executes it again. This means, it will delete all intermediate values you see in the WorkflowTrace and recompute them dynamically. This means that if you change a value within <originalValue> tags, your changes will just be ignored. If you want to influence the values TLS-Attacker uses, you either have to manipulate the Config (as already shown) or apply modifications to TLS-Attackers ModifiableVariables. The concept of ModifiableVariables is mostly unchanged to the previous version, but we will show you how to do this real quick anyway.

So let us imagine we want to manipulate a value in the WorkflowTrace using a ModifiableVariable via XML. First, we have to select a field which we want to manipulate. I will choose the protocol version field in the ServerHello message we sent. In the WorkflowTrace this looked like this:

	<protocolVersion>
	<originalValue>03 03</originalValue>
	</protocolVersion>

view raw version_original.xml hosted with ❤ by GitHub

For historical reasons, 0x0303 means TLS 1.2. 0x0300 was SSL 3. When they introduced TLS 1.0 they chose 0x0301 and since then they just upgraded the minor version.

In order to manipulate this ModifiableVariable, we first need to know its type. In some cases it is currently non-trivial to determine the exact type, this is mostly undocumented (sorry). If you don't know the exact type of a field you currently have to look at the code. The following types and modifications are defined:

• ModifiableBigInteger: add, explicitValue, shiftLeft, shiftRight, subtract, xor
• ModifiableBoolean: explicitValue, toggle
• ModifiableByteArray: delete, duplicate, explicitValue, insert, shuffle, xor
• ModifiableInteger: add, explicitValue, shiftLeft, shiftRight, subtract, xor
• ModifiableLong: add, explicitValue, subtract, xor
• ModifiableByte: add, explicitValue, subtract, xor
• ModifiableString: explicitValue

As a rule of thumb: If the value is only up to 1 byte of length we use a ModifiableByte. If the value is up to 4 bytes of length, but the values are used as a normal number (for example in length fields) it is a ModifiableInteger. Fields which are used as a number which are bigger than 4 bytes (for example a modulus) is usually a ModifiableBigInteger. Most other types are encoded as ModifiableByteArrays. The other types are very rare (we are currently working on making this whole process more transparent).
Once you have found your type you have to select a modification to apply to it. For manual analysis, the most common modifications are the XOR modification and the explicit value modification. However, during fuzzing other modifications might be useful as well. Often times you just want to flip a bit and see how the server responds, or you want to directly overwrite a value. In this example, we want to overwrite a value.
Let us force TLS-Attacker to send the version 0x3A3A. To do this I consult the ModifiableVariable README.md for the exact syntax. Since <protocolVersion> is a ModifiableByteArray I search in the ByteArray section.

I find the following snippet:

	<byteArrayExplicitValueModification>
	<explicitValue>
	4F 3F 8C FC 17 8E 66 0A 53 DF 4D 4E E9 0B D0
	</explicitValue>
	</byteArrayExplicitValueModification>

view raw explicit_byte_array_modification.xml hosted with ❤ by GitHub

If I now want to change the value to 0x3A3A I modify my WorkflowTrace like this:

	<workflowTrace>
	<Send>
	<messages>
	<ServerHello>
	<protocolVersion>
	<byteArrayExplicitValueModification>
	<explicitValue>
	3A 3A
	</explicitValue>
	</byteArrayExplicitValueModification>
	</protocolVersion>
	</ServerHello>
	</messages>
	</Send>
	<Receive>
	<expectedMessages>
	<ServerHello/>
	<Certificate/>
	<ServerHelloDone/>
	</expectedMessages>
	</Receive>
	</workflowTrace>

view raw double_server_hello_with_modification.xml hosted with ❤ by GitHub

You can then execute the WorkflowTrace with:

java -jar TLS-Client.jar -connect somehost.com -workflow_input trace.xml

view raw command6.sh hosted with ❤ by GitHub

With Wireshark you can now observe  that the protocol version got actually changed. You would also see the change if you would specify a -workflow_output or if you start the TLS-Client with the -debug flag.

More Actions

As I already hinted, TLS-Attacker has more actions to offer than just a basic Send- and ReceiveAction (50+ in total). The most useful, and easiest to understand actions are now introduced:

ActivateEncryptionAction

This action does basically what the CCS message does. It activates the currently "negotiated" parameters. If necessary values are missing in the context of the connection, they are drawn from the Config.

	<workflowTrace>
	<ActivateEncryption/>
	</workflowTrace>

view raw activate_encryption_action.xml hosted with ❤ by GitHub

DeactivateEncryptionAction

This action does the opposite. If the encryption was active, we now send unencrypted again.

	<workflowTrace>
	<DeactivateEncryption/>
	</workflowTrace>

view raw deactivate_encryption.xml hosted with ❤ by GitHub

PrintLastHandledApplicationDataAction

Prints the last application data message either sent or received.

	<workflowTrace>
	<PrintLastHandledApplicationData/>
	</workflowTrace>

view raw print_last_applicationdata.xml hosted with ❤ by GitHub

PrintProposedExtensionsAction

Prints the proposed extensions (from the client)

	<workflowTrace>
	<PrintProposedExtensions/>
	</workflowTrace>

view raw print_proposed_extensions.xml hosted with ❤ by GitHub

PrintSecretsAction

Prints the secrets (RSA) from the current connection. This includes the nonces, cipher suite, public key, modulus, premaster secret, master secret and verify data.

	<workflowTrace>
	<PrintSecrets/>
	</workflowTrace>

view raw print_secrets.xml hosted with ❤ by GitHub

RenegotiationAction

Resets the message digest. This is usually done if you want to perform a renegotiation.

	<workflowTrace>
	<Renegotiation/>
	</workflowTrace>

view raw renegotiation_action.xml hosted with ❤ by GitHub

ResetConnectionAction

Closes and reopens the connection. This can be useful if you want to analyze session resumption or similar things which involve more than one handshake.

	<workflowTrace>
	<ResetConnection/>
	</workflowTrace>

view raw reset_connection_action.xml hosted with ❤ by GitHub

SendDynamicClientKeyExchangeAction

Send a ClientKeyExchange message, and always chooses the correct one (depending on the current connection state). This is useful if you just don't care about the actual cipher suite and just want the handshake done.

	<workflowTrace>
	<SendDynamicClientKeyExchange/>
	</workflowTrace>

view raw dynamic_client_key.xml hosted with ❤ by GitHub

SendDynamicServerKeyExchangeAction

(Maybe) sends a ServerKeyExchange message. This depends on the currently selected cipher suite. If the cipher suite requires the transmission of a ServerKeyExchange message, then a ServerKeyExchange message will be sent, otherwise, nothing is done. This is useful if you just don't care about the actual cipher suite and just want the handshake done.

	<workflowTrace>
	<SendDynamicServerKeyExchange/>
	</workflowTrace>

view raw dynamic_server_key.xml hosted with ❤ by GitHub

WaitAction

This lets TLS-Attacker sleep for a specified amount of time (in ms).

	<Wait>
	<time>1000</time>
	</Wait>

view raw wait_action.xml hosted with ❤ by GitHub

As you might have already seen there is so much more to talk about in TLS-Attacker. But this should give you a rough idea of what is going on.

If you have any research ideas or need support feel free to contact us on Twitter (@ic0nz1, @jurajsomorovsky ) or at https://www.hackmanit.de/.

If TLS-Attacker helps you to find a bug in a TLS implementation, please acknowledge our tool(s). If you want to learn more about TLS, Juraj and I are also giving a Training about TLS at Ruhrsec (27.05.2019).

Related links

1. Mind Hacking
2. Tools Hacking
3. Hacking Net
4. Hacking To The Gate
5. Hacking Iphone
6. Hacking Books
7. Curso Seguridad Informatica
8. Life Hacking
9. Curso De Ciberseguridad Y Hacking Ético
10. El Mejor Hacker
11. Tecnicas De Ingenieria Social
12. Phishing Hacking

Resolución De ExpedientesX De Código

Hoy me he topado con algo bastante gracioso que puede liarte unos minutos:

python
>>> import re
>>> a='owjf oasijf aw0oifj osfij 4.4.4.4 oasidjfowefij 192.168.1.1'


ok, pues ahora copy-pasteais cada una de estas:
re.findall('[0-9]̣̣',a)
re.findall('[0-9]',a)

Son exactamente iguales, pero si paseteais una da resultados diferente a si pasteais la otra :)

Pasteamos la primera:
>>> re.findall('[0-9]̣̣',a)
[]

Pasteamos la segunda:
>>> re.findall('[0-9]',a)
['0', '4', '4', '4', '4', '1', '9', '2', '1', '6', '8', '1', '1']


o_O, he repasado caracter a caracter y son visualmente iguales, si mirais en un editor hexa vereis que realmente no lo son, lógicamente no se trata de un expedienteX.

La cuestion es que según la fuente que tengais, debajo de la comilla o debajo del ] hay un punto microscópico :)

Esto es como cuando me emparanoie de que gmail cuando llevas un rato escribiendo un email y se hace auto-save, aparece una especie de acento raro en la pantalla :)

En estos casos, la metodología tipica de copypastear un trozo de la primera sentencia con el resto de la segunda sentencia, te lleva a los 2 caracteres que varían, pero no aprecias (segun la fuente que tengas) la diferéncia.



6572 662e 6e69 6164 6c6c 2728 305b 392d cc5d cca3 27a3 612c 0a29
6572 662e 6e69 6164 6c6c 2728 305b 392d 275d 612c 0a29

Son dígitos unicode, sabe Dios de que pais, y sabe Dios también como los escribí con mi teclado,
se me ocurren bromas de código fuente que se pueden hacer con esto :D, pero vamos, si tenemos metodología de reaccién ante expedientesX, sobretodo aquello de divide y vencerás dicotómico, en pocos minutos se resuelven este tipo de problemas.

More information

• Hacking Apps
• Hacking Movies
• Hacking Youtube

Recovering Data From An Old Encrypted Time Machine Backup

Recovering data from a backup should be an easy thing to do. At least this is what you expect. Yesterday I had a problem which should have been easy to solve, but it was not. I hope this blog post can help others who face the same problem.

The problem

1. I had an encrypted Time Machine backup which was not used for months
2. This backup was not on an official Apple Time Capsule or on a USB HDD, but on a WD MyCloud NAS
3. I needed files from this backup
4. After running out of time I only had SSH access to the macOS, no GUI

The struggle

By default, Time Machine is one of the best and easiest backup solution I have seen. As long as you stick to the default use case, where you have one active backup disk, life is pink and happy. But this was not my case.

As always, I started to Google what shall I do. One of the first options recommended that I add the backup disk to Time Machine, and it will automagically show the backup snapshots from the old backup. Instead of this, it did not show the old snapshots but started to create a new backup. Panic button has been pressed, backup canceled, back to Google.

Other tutorials recommend to click on the Time Machine icon and pressing alt (Option) key, where I can choose "Browse other backup disks". But this did not list the old Time Machine backup. It did list the backup when selecting disks in Time Machine preferences, but I already tried and failed that way.

YAT (yet another tutorial) recommended to SSH into the NAS, and browse the backup disk, as it is just a simple directory where I can see all the files. But all the files inside where just a bunch of nonsense, no real directory structure.

YAT (yet another tutorial) recommended that I can just easily browse the content of the backup from the Finder by double-clicking on the sparse bundle file. After clicking on it, I can see the disk image on the left part of the Finder, attached as a new disk.
Well, this is true, but because of some bug, when you connect to the Time Capsule, you don't see the sparse bundle file. And I got inconsistent results, for the WD NAS, double-clicking on the sparse bundle did nothing. For the Time Capsule, it did work.
At this point, I had to leave the location where the backup was present, and I only had remote SSH access. You know, if you can't solve a problem, let's complicate things by restrict yourself in solutions.

Finally, I tried to check out some data forensics blogs, and besides some expensive tools, I could find the solution.

The solution

Finally, a blog post provided the real solution - hdiutil.
The best part of hdiutil is that you can provide the read-only flag to it. This can be very awesome when it comes to forensics acquisition.

To mount any NAS via SMB:

mount_smbfs afp://<username>@<NAS_IP>/<Share_for_backup> /<mountpoint>

To mount a Time Capsule share via AFP:

mount_afp afp://any_username:password@<Time_Capsule_IP>/<Share_for_backup> /<mountpoint>

And finally this command should do the job:

hdiutil attach test.sparsebundle -readonly

It is nice that you can provide read-only parameter.

If the backup was encrypted and you don't want to provide the password in a password prompt, use the following:

printf '%s' 'CorrectHorseBatteryStaple' | hdiutil attach test.sparsebundle -stdinpass -readonly

Note: if you receive the error "resource temporarily unavailable", probably another machine is backing up to the device

And now, you can find your backup disk under /Volumes. Happy restoring!

Probably it would have been quicker to either enable the remote GUI, or to physically travel to the system and login locally, but that would spoil the fun.

Related articles

1. Hacker Profesional
2. Aprender Hacking
3. Hacking Ético Curso
4. Wifi Hacking
5. House Hacking
6. Ethical Hacking Curso
7. Ingeniería Social El Arte Del Hacking Personal
8. Hacking Hardware
9. Hacking Linkedin

August Connector

*|MC_PREVIEW_TEXT|*

OWASP Connector   August 2019 Communications | Projects | Events | Community | Membership COMMUNICATIONS Letter from the Vice-Chairman: Dear OWASP Community,   I hope you are enjoying your summer, mines been pretty busy, getting married, traveling to Vegas and the board elections. August has been quite a busy month for the foundation. Attending BlackHat and DefCon as part of our outreach program, the upcoming elections ( I have to add, there were some really good questions from the community) and planning for the next two Global AppSec Conferences in September, it's been crazy. We the board would like to thank the staff and without naming any names (Jon McCoy) for their efforts during BlackHat and DefCon. I was there, on the stand, he did a good job of representing our community. Two days prior to BlackHat and Defcon the board met as part of our second face to face meeting of the year. This was two days well spent, collaborating on some of the burning topics, but also how to move forward. At the beginning of the year, we set out our strategic goals. Even though these goals are part of our everyday OWASP life we decided to put a name against them to champion them, below are our goals and who will be championing them going forward: Marketing - Chenxi Membership - Ofer Developer Outreach - Martin Project Focus - Sherif Improve Finances - Gary Perception - Martin  Process Improvement - Owen Consistent ED - Done!  Community Empowerment - Richard If you are interested in getting involved in or would like to hear more about any of these strategic goals, please reach out to the relevant name above.  Some of the Global board members will be attending both our Global AppSec Conference in Amsterdam but also in DC. We will hold our next public board meeting during the Global AppSec Conference in Amsterdam if you haven't already done so I would encourage you to both attend and spread the word of the conference. There are some great keynotes/ speakers and trainers lined up.  Regards Owen Pendlebury  Vice-Chairman of the OWASP Global Board of Directors DC Registration Now Open                                   Amsterdam Registration Now Open Congratulations to the Global AppSec Tel Aviv 2019 Capture the Flag Winners   For two full days, 24 competitors from around the world attacked various challenges that were present within the CTF activity held at Global AppSec Tel Aviv 2019. The competition began with a handful of competitors running neck and neck with two competitors, 4lemon and vasya, at the top, slowly gathering more points in their race hoping to win it all. At the last moment, they were overtaken by Aleph who swooped in and took away the victory for himself with a total score of 29 points!  We would like to thank all of the individuals who participated and once again, congratulations to the top 3. 1st Place Winner: Aleph (29 points) 2nd Place: 4lemon (24 points) 3rd Place: vasya (24 points) EVENTS  You may also be interested in one of our other affiliated events: REGIONAL EVENTS Event Date Location OWASP Portland Training Day September 25, 2019 Portland, OR OWASP Italy Day Udine 2019 September 27, 2019 Udine, Italy OWASP Poland Day October 16,2019 Wroclaw, Poland BASC 2019 (Boston Application Security Conference) October 19,2019 Burlington, MA LASCON X October 24 - 25,2019 Austin, TX OWASP AppSec Day 2019 Oct 30 - Nov 1, 2019 Melbourne, Australia German OWASP Day 2019 December 9 - 10, 2019 Karlsruhe, Germany AppSec California 2020 January 21 - 24. 2020 Santa Monica, CA OWASP New Zealand Day 2020 February 20 - 21, 2020 Auckland, New Zealand PARTNER AND PROMOTIONAL EVENTS Event Date Location it-sa-IT Security Expo and Congress October 8 - 10, 2019 Germany PROJECTS Project Review Results from Global AppSec - Tel Aviv 2019 The results of the project reviews from Global AppSec Tel Aviv 2019 are in!  The following projects have graduated to the indicated status: Project Leaders Level Mobile Security Testing Guide Jeroen Willemsen, Sven Schleier Flagship Cheat Sheet Series Jim Manico, Dominique Righetto Flagship Amass Jeff Foley Lab Please congratulate the leaders and their teams for their achievements! If your project was up for review at Global AppSec Tel Aviv 2019 and it is not on this list, it just means that the project did not yet receive enough reviews.  And, if you are interested in helping review projects, send me an email (harold.blankenship@owasp.com). Project Showcases at the Upcoming Global AppSecs The Project Showcases for Global Appsec DC 2019 and Global AppSec Amsterdam 2019 are finalized.  For a complete schedule, see the following links: Global AppSec - DC 2019 Project Showcase Global AppSec - Amsterdam 2019 Project Showcase Google Summer of Code Update Google Summer of Code is now in the final stages.  Final Evaluations are due by September 2nd.   The Mentor Summit will be in Munich this year; congratulate the OWASP mentors who were picked by raffle to attend and represent OWASP: Azzeddine Ramrami & Ali Razmjoo. Google Summer of Code Update THE OWASP FOUNDATION HAS SELECTED THE TECHNICAL WRITER FOR GOOGLE SEASON OF DOCS by Fabio Cerullo The OWASP Foundation has been accepted as the organization for the Google Seasons of Docs, a project whose goals are to give technical writers an opportunity to gain experience in contributing to open source projects and to give open-source projects an opportunity to engage the technical writing community. During the program, technical writers spend a few months working closely with an open-source community. They bring their technical writing expertise to the project's documentation, and at the same time learn about open source and new technologies. The open-source projects work with the technical writers to improve the project's documentation and processes. Together they may choose to build a new documentation set, or redesign the existing docs, or improve and document the open-source community's contribution procedures and onboarding experience. Together, we raise public awareness of open source docs, of technical writing, and of how we can work together to the benefit of the global open source community. After a careful review and selection process, the OWASP Foundation has picked the primary technical writer who will work along the OWASP ZAP Team for the next 3 months to create the API documentation of this flagship project. Congratulations to Nirojan Selvanathan! Please refer to the linked document where you could look at the deliverables and work execution plan. https://drive.google.com/open?id=1kwxAzaqSuvWhis9Xn1VKNJTJZPM2UV20 COMMUNITY   Welcome New OWASP Chapters Tegucigalpa, Honduras Johannesburg, South Africa   CORPORATE SPONSORS   Join us Donate Our mailing address is: OWASP Foundation  1200-C Agora Drive, #232 Bel Air, MD 21014   Contact Us Unsubscribe

This email was sent to *|EMAIL|* why did I get this?    unsubscribe from this list    update subscription preferences *|LIST:ADDRESSLINE|*