rss.xml

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="https://blog.avuln.com"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>AVULN Blog</title>
 <link>https://blog.avuln.com</link>
 <description></description>
 <language>en</language>
<item>
 <title>A couple more common OAuth 2.0 vulnerabilities </title>
 <link>https://blog.avuln.com/article/4</link>
 <description>&lt;div class=&quot;field field-name-body field-type-text-with-summary field-label-hidden&quot;&gt;&lt;div class=&quot;field-items&quot;&gt;&lt;div class=&quot;field-item even&quot; property=&quot;content:encoded&quot;&gt;&lt;p&gt;&lt;strong&gt;TL;DR&lt;/strong&gt; The couple of bugs described below are common across different OAuth 2.0 implementations. The bugs may allow a malicious application to maintain an access to victim&#039;s account even after access revocation performed by the victim. &lt;/p&gt;
&lt;p&gt;&lt;!--break--&gt;&lt;/p&gt;
&lt;p&gt; &lt;/p&gt;
&lt;p&gt;&lt;span style=&quot;font-size: large;&quot;&gt;&lt;strong&gt;1. Race Condition for &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; / &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;refresh_token&lt;/span&gt; generation&lt;/strong&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;According to any OAuth 2.0 API documentation and to &lt;a href=&quot;https://tools.ietf.org/html/rfc6749&quot;&gt;OAuth 2.0 RFC&lt;/a&gt;, when an application (&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;client&lt;/span&gt; in terms of OAuth) obtains &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;code&lt;/span&gt; value from OAuth 2.0 Provider (i.e. the moment when user authorizes an application), this value should be exchanged for &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt;. It seems to be obvious that &lt;strong&gt;one&lt;/strong&gt; &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;code&lt;/span&gt; &lt;strong&gt;value should be exchanged for one&lt;/strong&gt; &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; (or for a single pair of &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; and &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;refresh_token&lt;/span&gt;, if resresh tokens are supported). Also RFC contains quite explicit requirements about that:&lt;/p&gt;
&lt;p&gt;1) &lt;a href=&quot;https://tools.ietf.org/html/rfc6749#section-4.1.2&quot;&gt;https://tools.ietf.org/html/rfc6749#section-4.1.2&lt;/a&gt;:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;                        If an authorization code is used more than&lt;/span&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;   once, the authorization server MUST deny the request and SHOULD&lt;/span&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;   revoke (when possible) all tokens previously issued based on&lt;/span&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;   that authorization code.  The authorization code is bound to&lt;/span&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;   the client identifier and redirection URI.&lt;/span&gt;&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;2) &lt;a href=&quot;https://tools.ietf.org/html/rfc6749#section-10.5&quot;&gt;https://tools.ietf.org/html/rfc6749#section-10.5&lt;/a&gt;:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;   Authorization codes MUST be short lived and single-use.  If the&lt;/span&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;   authorization server observes multiple attempts to exchange an&lt;/span&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;   authorization code for an access token, the authorization server&lt;/span&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;   SHOULD attempt to revoke all access tokens already granted based on&lt;/span&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;   the compromised authorization code.&lt;/span&gt;&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;However, most of OAuth 2.0 providers we&#039;ve tested either didn&#039;t have that mechanism or had a race condition bug in it. Due to that, many of the provides had authorization issues.&lt;/p&gt;
&lt;p&gt; &lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Proof Of Concept&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;0) register an application with OAuth 2.0 provider you&#039;re going to test&lt;/p&gt;
&lt;p&gt;1) open link to authorize the application&lt;/p&gt;
&lt;p&gt;2) log into user (i.e. victim) account and Authorize the application&lt;/p&gt;
&lt;p&gt;3) obtain &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;code&lt;/span&gt; value from callback URL&lt;/p&gt;
&lt;p&gt;4) try to exploit Race Condition for obtaining &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt;:&lt;/p&gt;
&lt;pre class=&quot;brush: php; auto-links: true; collapse: false; first-line: 1; html-script: false; smart-tabs: true; tab-size: 4; toolbar: true; codetag&quot;&gt;#!/bin/bash
for i in {0..20}
do
 curl --data &quot;code=$1&amp;amp;client_id=CLIENT_ID&amp;amp;client_secret=CLIENT_SECRET&amp;amp;redirect_uri=CALLBACK_URL&amp;amp;grant_type=authorization_code&quot; &quot;https://OAUTH_PROVIDER/oauth/token&quot; &amp;amp;
done
# where $1 is code value (first parameter passed to the script)&lt;/pre&gt;&lt;p&gt;5) please note that you may have to do several attempts to explot the race condition &lt;/p&gt;
&lt;p&gt;6) if several &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; values obtained, check whether each of them is valid&lt;/p&gt;
&lt;p&gt;7) go to application settings for victim&#039;s account and revoke access for the application&lt;/p&gt;
&lt;p&gt;8) check whether all &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; values became invalid; if only one &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; has been revoked and all the rest stay active -- this is the worst case&lt;/p&gt;
&lt;p&gt; &lt;/p&gt;
&lt;p&gt;PoC for &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;refresh_token&lt;/span&gt; is similar to the one just described, but on step 4 you may legally obtain &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; and &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;refresh_token&lt;/span&gt; pair. Then you need to exploit Race Condition for&lt;span style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal; line-height: 1.625;&quot;&gt; &lt;/span&gt;&lt;span style=&quot;font-size: 15px; line-height: 1.625; font-family: &#039;courier new&#039;, courier;&quot;&gt;reshresh_token&lt;/span&gt;&lt;span style=&quot;font-size: 15px; line-height: 1.625;&quot;&gt; request the same way:&lt;/span&gt;&lt;/p&gt;
&lt;pre class=&quot;brush: php; auto-links: true; collapse: false; first-line: 1; html-script: false; smart-tabs: true; tab-size: 4; toolbar: true; codetag&quot;&gt;#!/bin/bash
for i in {0..20}
do
 curl --data &quot;refhresh_token=$1&amp;amp;client_id=CLIENT_ID&amp;amp;client_secret=CLIENT_SECRET&amp;amp;redirect_uri=CALLBACK_URL&amp;amp;grant_type=refresh_token&quot; &quot;https://OAUTH_PROVIDER/oauth/token&quot; &amp;amp;
done
# where $1 is refresh_token value (first parameter passed to the script)&lt;/pre&gt;&lt;p&gt;Explotation of Race Condition for &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;refresh_token&lt;/span&gt; is more dangerous than for &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt;, as usually there is no way for an attacker to fail. Each exploitation gives at least one new &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;refresh_token&lt;/span&gt; value that may be used later. So, number of token pairs grows exponentially, if provider is vulnerable.&lt;/p&gt;
&lt;p&gt; &lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Statistics&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;&lt;strong&gt;32&lt;/strong&gt; OAuth 2.0 providers tested&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;26&lt;/strong&gt; out of 32 had race condition bug:&lt;/li&gt;
&lt;ul&gt;&lt;li&gt;&lt;strong&gt;5&lt;/strong&gt; providers returned the same &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; value for successful competing requests -&amp;gt; &lt;strong&gt;good behavior&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;1&lt;/strong&gt; provider generated different &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; values, but only one token is valid -&amp;gt; &lt;strong&gt;not bad behavior&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;20&lt;/strong&gt; providers generated different &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; values and all of them were valid -&amp;gt; &lt;strong&gt;bad behavior&lt;/strong&gt;, as it violates the RFC + unexpected flaws caused by multiple tokens/contexts generation are possible&lt;/li&gt;
&lt;ul&gt;&lt;li&gt;&lt;strong&gt;10&lt;/strong&gt; out of 20 providers had issues with revocation of access (step 8 from the PoC succeeded for them) -&amp;gt; &lt;strong&gt;the worst case&lt;/strong&gt;: a victim sees that access is revoked, but malicious application still has access to victim&#039;s account&lt;/li&gt;
&lt;/ul&gt;&lt;/ul&gt;&lt;/ul&gt;&lt;p&gt; &lt;/p&gt;
&lt;p&gt;&lt;span style=&quot;font-size: large;&quot;&gt;&lt;strong&gt;2. Missing invalidation of authorization &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;code&lt;/span&gt; during access revocation&lt;/strong&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;Another issue which is common for multiple OAuth 2.0 implementations. It is not race condition bug. It is a logical error caused by misunderstanding of some &quot;states&quot; in OAuth 2.0 flow.&lt;/p&gt;
&lt;p&gt;OAuth 2.0 API makes it possible for users to grant access to their accounts to some third-side applications. Of course, users are able to manage such applications&#039; access to their accounts and may deny access for any application. When user denies access for the application, all &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; values (and &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;refresh_token&lt;/span&gt; as well) are being revoked and become invalid. But not only &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token &lt;/span&gt;should be revoked, authorization &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;code&lt;/span&gt; (it is an intermediate token used in OAuth2 Authorization Flow) must be revoked as well. Sadly, most of OAuth2 API implementations do not revoke authorization &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;code&lt;/span&gt; during access revocation. It may be exploited in order to restore access to user&#039;s account by malicious application right after access revocation.&lt;/p&gt;
&lt;p&gt; &lt;/p&gt;
&lt;p&gt;&lt;strong style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;Proof Of Concept&lt;/strong&gt;&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;0) register an application for OAuth 2.0 provider you&#039;re going to test&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;1) open link for authorization of the application&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;2) log into user (i.e. victim) account and Authorize the application&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;3) obtain &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;code&lt;/span&gt; value from callback URL&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;4) obtain &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt;, check its validity if you wish&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;5) open link for authorization again (i.e. repeat step 1)&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;6) most of providers support automatic redirect to callback URL on this stage (also there may be additional parameters for that in URL: like &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;force_approval&lt;/span&gt; or &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;approval_prompt&lt;/span&gt; or some checkbox in applications settings), this makes exploitation easier; otherwise, Authorize the application manually&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;7) copy &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;code&lt;/span&gt; value from callback URL and save it for furture usage&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;8) &lt;span style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal; line-height: 1.625;&quot;&gt;go to application settings page for &lt;/span&gt;victim&lt;span style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal; line-height: 1.625;&quot;&gt;&#039;s account and revoke access for the application&lt;/span&gt;&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;&lt;span style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal; line-height: 1.625;&quot;&gt;9) ensure that &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; obtained on step 4 is invalidated&lt;/span&gt;&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;&lt;span style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal; line-height: 1.625;&quot;&gt;10) exchange &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;code&lt;/span&gt; value from step 7 for new &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt;, check whether new &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt; is valid&lt;/span&gt;&lt;/p&gt;
&lt;p style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal;&quot;&gt;&lt;strong&gt; &lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;span style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal; font-weight: 300;&quot;&gt;If new &lt;/span&gt;&lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;access_token&lt;/span&gt;&lt;span style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal; font-weight: 300;&quot;&gt; is valid, that means &lt;/span&gt;malicious application still has access to user&#039;s account even after revocation of authorization by the user.&lt;/p&gt;
&lt;p&gt; &lt;/p&gt;
&lt;p&gt;For real attack scenario it is important to mention the following:&lt;/p&gt;
&lt;p&gt;a) it seems that step 5 requires interaction from user, actually it is not necessary&lt;/p&gt;
&lt;p&gt;b) authorization code obtained via callback has certain lifetime, but it is not an issue as well&lt;/p&gt;
&lt;p&gt; &lt;/p&gt;
&lt;p&gt;Malicious application that does not want to lose access to the user&#039;s account needs to place on its web site something like:&lt;/p&gt;
&lt;pre class=&quot;brush: php; auto-links: true; collapse: false; first-line: 1; html-script: false; smart-tabs: true; tab-size: 4; toolbar: true; codetag&quot;&gt;&amp;lt;html&amp;gt;
    &amp;lt;img src=&quot;https://OAUTH_PROVIDER/authorize?client_id=CLIENT_ID&amp;amp;client_secret=CLIENT_SECRET&amp;amp;redirect_uri=CALLBACK_URL&amp;amp;scope=SOME_SCOPE&amp;amp;response_type=code&quot;&amp;gt;
&amp;lt;/html&amp;gt;&lt;/pre&gt;&lt;p&gt;Such code will &quot;silently&quot; produce new authorization code each time it has been loaded by the user. Check the traffic or contents of access.log on the callback server while opening a page with the html-snippet listed above:&lt;/p&gt;
&lt;pre class=&quot;brush: php; auto-links: true; collapse: false; first-line: 1; html-script: false; smart-tabs: true; tab-size: 4; toolbar: true; codetag&quot;&gt;root@server:/var/log/nginx# tail -f access.log
&amp;lt;...&amp;gt;
&amp;lt;IP hidden&amp;gt; - - [16/Apr/2015:13:08:56 +0000] &quot;GET /callback?state=0123456789abcdef&amp;amp;code=xlDxVYdnJlsAAAAAAAAFQDUmzla7P8Jg9fM2rNxwP8U HTTP/1.1&quot; 200 14 &quot;-&quot; &quot;Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36&quot;&lt;/pre&gt;&lt;p&gt;As you see, the malicious application has just obtained new &lt;span style=&quot;font-family: &#039;courier new&#039;, courier;&quot;&gt;code&lt;/span&gt; value that would not be revoked when user clicks &quot;Delete Authorization&quot;.&lt;/p&gt;
&lt;p&gt; &lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Statistics&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;&lt;strong&gt;29&lt;/strong&gt; OAuth 2.0 providers tested&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;18&lt;/strong&gt; out of 29 of them had the issue&lt;/li&gt;
&lt;/ul&gt;&lt;p&gt;3 OAuth providers tested for the first issue are not included in statistics for the second one (32 - 29 = 3), as they had even bigger issues with access revocation: it was either not implemented at all or was not accessible by user.&lt;/p&gt;
&lt;p&gt; &lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Summary&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;&lt;span style=&quot;font-size: 15px; line-height: 1.625;&quot;&gt;read and understand RFCs and standards very attentively, many bugs are caused by bad implementation, not by bad requirements&lt;/span&gt;&lt;/li&gt;
&lt;li style=&quot;font-size: 15px;&quot;&gt;&lt;span style=&quot;font-size: 15px; line-height: 1.625;&quot;&gt;be extremely careful when you develop multi-threaded applications&lt;/span&gt;&lt;/li&gt;
&lt;li&gt;&lt;span style=&quot;font-size: 15px; line-height: 1.625;&quot;&gt;being a user, do not grant access to unknown apps &lt;/span&gt;:)&lt;/li&gt;
&lt;/ul&gt;&lt;p&gt; &lt;/p&gt;
&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div class=&quot;field field-name-field-tags field-type-taxonomy-term-reference field-label-above&quot;&gt;&lt;div class=&quot;field-label&quot;&gt;Tags:&amp;nbsp;&lt;/div&gt;&lt;div class=&quot;field-items&quot;&gt;&lt;div class=&quot;field-item even&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/oauth&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;oauth&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item odd&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/oauth20&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;oauth2.0&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item even&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/race-condition&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;race condition&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item odd&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/accesstoken&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;access_token&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item even&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/refreshtoken&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;refresh_token&lt;/a&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</description>
 <pubDate>Mon, 18 Sep 2017 13:58:53 +0000</pubDate>
 <dc:creator>Dor1s</dc:creator>
 <guid isPermaLink="false">4 at https://blog.avuln.com</guid>
 <comments>https://blog.avuln.com/article/4#comments</comments>
</item>
<item>
 <title>AVULNATOR prototype in action!</title>
 <link>https://blog.avuln.com/article/3</link>
 <description>&lt;div class=&quot;field field-name-body field-type-text-with-summary field-label-hidden&quot;&gt;&lt;div class=&quot;field-items&quot;&gt;&lt;div class=&quot;field-item even&quot; property=&quot;content:encoded&quot;&gt;&lt;p&gt;Recently, we have presented the first prototype of AVULNATOR ever. The announcement took place at Positive Hack Days conference in Moscow.&lt;/p&gt;
&lt;p&gt;Now it is time to publish a bit more information about the first prototype of AVULNATOR to our blog. Additional bonus here is Proof-of-Concept video at the end of the article.&lt;/p&gt;
&lt;p&gt;Well, there is no doubts that AVULNATOR is a revolutionary device for home network protection and its prototype should has some touchable appearance. Honestly, its first piece has not incredible design and awesome look &lt;span style=&quot;font-family: &#039;Helvetica Neue&#039;, Helvetica, Arial, sans-serif; font-size: 15px; font-style: normal; line-height: 1.625;&quot;&gt;yet&lt;/span&gt;&lt;span style=&quot;font-size: 15px; line-height: 1.625;&quot;&gt;; however, it looks pretty hardcore right now being packed in our handmade case :)&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;img style=&quot;display: block; margin-left: auto; margin-right: auto;&quot; src=&quot;/sites/default/files/files-storage/avulnator_prototype_1.jpg&quot; alt=&quot;&quot; width=&quot;1200&quot; height=&quot;972&quot; /&gt;&lt;/p&gt;
&lt;p&gt;Speaking about functionality of the AVULNATOR, to use its prototype right now you need just to do the following two steps:&lt;/p&gt;
&lt;ol&gt;&lt;li&gt;&lt;span style=&quot;font-size: 15px; line-height: 1.625;&quot;&gt;Connect AVULNATOR to your home router (or to ISP cable, in case you do not use your own router)&lt;/span&gt;&lt;/li&gt;
&lt;li&gt;&lt;span style=&quot;font-size: 15px; line-height: 1.625;&quot;&gt;Set up your smart electronic devices to be connected to AVULNATOR’s wireless network&lt;/span&gt;&lt;/li&gt;
&lt;/ol&gt;&lt;p&gt;That is all what you need to do. For some smart devices also may be needed to add their models at AVULNATOR’s control panel. Check PoC video at the end of the post to ensure how easy it is.&lt;/p&gt;
&lt;p&gt;Since you connected your devices, AVULNATOR starts to protect them against any possible cyberattacks. According to &lt;strong&gt;OWASP: IoT Security Checklist&lt;/strong&gt; originally contributed by &lt;a href=&quot;https://wallarm.com/&quot;&gt;Wallarm Inc.&lt;/a&gt; experts, AVULNATOR supports all possible threat models considered so far:&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;/sites/default/files/files-storage/competitors_ok.PNG&quot; alt=&quot;&quot; width=&quot;1200&quot; height=&quot;577&quot; /&gt;&lt;/p&gt;
&lt;p&gt;It is a very good point. While choosing any sort of protection, one should clearly understand which kind of attacks and threats he is going to mitigate. Protection against highly theoretical threats (like external attack via direct connection to smart electronics) is meaningless, because in more than 99% of cases such attacks are not possible. As a result, there is no reason to pay for this.&lt;/p&gt;
&lt;p&gt; &lt;/p&gt;
&lt;p&gt;Below is Proof-of-Concept video of how the prototype works. There you can see interface of AVULNATOR&#039;s control panel and demonstration of its protection in action. Initially, protection is turned off (“&lt;em&gt;Security status&lt;/em&gt;” option). Then a public exploit for one of smart devices is used to get root access to the device. Further, we enable security status of AVULNATOR and check exploit again. Enjoy.&lt;/p&gt;
&lt;p style=&quot;text-align: center;&quot;&gt;
&lt;iframe src=&quot;https://player.vimeo.com/video/132646597&quot; frameborder=&quot;0&quot; width=&quot;500&quot; height=&quot;313&quot;&gt;&lt;/iframe&gt;&lt;/p&gt;
&lt;p style=&quot;text-align: center;&quot;&gt;&lt;a href=&quot;https://vimeo.com/132646597&quot;&gt;AVULNATOR: Proof of Concept video&lt;/a&gt; from &lt;a href=&quot;https://vimeo.com/avuln&quot;&gt;AVULN Security Industries&lt;/a&gt; on &lt;a href=&quot;https://vimeo.com&quot;&gt;Vimeo&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt; &lt;/p&gt;
&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div class=&quot;field field-name-field-tags field-type-taxonomy-term-reference field-label-above&quot;&gt;&lt;div class=&quot;field-label&quot;&gt;Tags:&amp;nbsp;&lt;/div&gt;&lt;div class=&quot;field-items&quot;&gt;&lt;div class=&quot;field-item even&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/avulnator&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;avulnator&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item odd&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/internet-things&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;internet of things&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item even&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/iot&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;IoT&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item odd&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/smart-house&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;smart house&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item even&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/home&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;home&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item odd&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/poc&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;PoC&lt;/a&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</description>
 <pubDate>Mon, 06 Jul 2015 11:15:21 +0000</pubDate>
 <dc:creator>Dor1s</dc:creator>
 <guid isPermaLink="false">3 at https://blog.avuln.com</guid>
 <comments>https://blog.avuln.com/article/3#comments</comments>
</item>
<item>
 <title>My home is my castle… or no longer?</title>
 <link>https://blog.avuln.com/article/2</link>
 <description>&lt;div class=&quot;field field-name-body field-type-text-with-summary field-label-hidden&quot;&gt;&lt;div class=&quot;field-items&quot;&gt;&lt;div class=&quot;field-item even&quot; property=&quot;content:encoded&quot;&gt;&lt;p&gt;From ancient times &lt;em&gt;home&lt;/em&gt; is associated with safe and quiet place. Seems like soon it can be changed.&lt;/p&gt;
&lt;p&gt;Recently &lt;em&gt;Forbes&lt;/em&gt; published an article about &lt;a href=&quot;http://www.forbes.com/sites/aarontilley/2015/03/06/nest-thermostat-hack-home-network/&quot;&gt;possible vulnerabilities in Nest Thermostat&lt;/a&gt;. Vulnerability looks unexploitable in practice because physical access to the device is required. However, it is easy to imagine some distributor’s employee or a serviceman getting access to your device and then getting control of it. &lt;/p&gt;
&lt;p&gt;Nest Thermostat is a great device and now treated as one of the most secure, according to Forbes. The same thing cannot be said about other “Internet of Things” stuff:&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;&lt;a href=&quot;https://threatpost.com/researcher-discloses-wi-fi-thermostat-vulnerabilities/108434&quot;&gt;https://threatpost.com/researcher-discloses-wi-fi-thermostat-vulnerabilities/108434&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;http://www.securityfocus.com/archive/1/534774&quot;&gt;http://www.securityfocus.com/archive/1/534774&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;http://www.cheatsheet.com/technology/usb-drive-to-smart-home-which-of-your-devices-can-be-hacked.html/?a=viewall&quot;&gt;http://www.cheatsheet.com/technology/usb-drive-to-smart-home-which-of-your-devices-can-be-hacked.html/?a=viewall&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;and so on&lt;/li&gt;
&lt;/ul&gt;&lt;p&gt;&lt;em&gt;IoT&lt;/em&gt;-era is only raising now. Importance of information security acknowledged now better than ever. Despite that, between comfort and security, we always prefer comfort. Usually comfort has nothing in common with security. It is why creating incredible and high-quality products is so difficult and require many resources for vendors.&lt;/p&gt;
&lt;p style=&quot;text-align: left;&quot;&gt;Currently serious cybersecurity threats for our homes are related not only with innovative devices. Most of all widely spread routers for home    &lt;a href=&quot;http://www.cvedetails.com/vendor/899/D-link.html&quot;&gt;have&lt;/a&gt;    &lt;a href=&quot;http://www.cvedetails.com/vendor/1414/Utstarcom.html&quot;&gt;so&lt;/a&gt;    &lt;a href=&quot;http://www.cvedetails.com/vendor/3447/Asus.html&quot;&gt;many&lt;/a&gt;    &lt;a href=&quot;http://www.cvedetails.com/vendor/1369/Belkin.html&quot;&gt;different&lt;/a&gt;    &lt;a href=&quot;http://www.cvedetails.com/vendor/859/Zyxel.html&quot;&gt;vulnerabilities&lt;/a&gt;.    &lt;a href=&quot;http://www.cvedetails.com/vendor/11936/Tp-link.html&quot;&gt;Yeah&lt;/a&gt;.    Hackers exploit such security holes, as &lt;a href=&quot;http://krebsonsecurity.com/2015/02/spam-uses-default-passwords-to-hack-routers/&quot;&gt;KrebsOnSecurity reports&lt;/a&gt;, and &lt;a href=&quot;https://threatpost.com/lizard-squads-ddos-for-hire-service-built-on-hacked-home-routers/110341&quot;&gt;do it very successful&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;An attacker controlling your router may control all your traffic. Such evil thing affects not only your privacy, but also makes another threats become actual. Sure, you have already heard about &lt;em&gt;HTTPS&lt;/em&gt; (HTTP over SSL/TLS) which made to protect traffic against eavesdropping. News, especially recent news reveal that it is not perfect at all: &lt;a href=&quot;http://heartbleed.com/&quot;&gt;Heartbleed&lt;/a&gt;, &lt;a href=&quot;http://poodlebleed.com/&quot;&gt;POODLE&lt;/a&gt;, &lt;a href=&quot;https://freakattack.com/&quot;&gt;FREAK&lt;/a&gt;, what’s next? Also &lt;a href=&quot;http://thehackernews.com/2015/02/lenovo-superfish-malware.html&quot;&gt;some vendors give good opportunities to hack their customers&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Vulnerabilities in home routers along with software holes in endpoint devices make very easy to steal your money from online-banking or your private photos from cloud storage.&lt;/p&gt;
&lt;p&gt;If somebody is not sure of the possibility of practical implementation of such threats, &lt;a href=&quot;https://ctfcrew.org/writeup/97&quot;&gt;this write-up&lt;/a&gt;, for example, may serve as a proof of concept. It is not a hacking tutorial; it is just solution of one task from a hacking contest. But it really shows step-by-step how to realize attack very similar to the one described above.&lt;/p&gt;
&lt;p&gt;May be it looks hard for a normal user, but actually it is very easy to implement.&lt;/p&gt;
&lt;p&gt;Hackers are thieves. Default-password is like an opened door to your home. Out-of-date software is like an opened window.&lt;/p&gt;
&lt;p&gt;Should we be scared? No. We must be extremely attentive now to prevent our families and folks from trouble. It really matters. We should carefully use opportunities of modern technologies and fully understand (when it’s possible) what we do each time using the Internet.&lt;/p&gt;
&lt;p&gt;To help you with that, we at &lt;em&gt;AVULN Security Industries&lt;/em&gt; are developing &lt;a href=&quot;https://avuln.com/forhome&quot;&gt;AVULNATOR&lt;/a&gt;. The device that will block malicious traffic incoming to your home network and other malware activity. AVULNATOR will be always up-to-dated because of our distributed cloud-based monitoring system. Read more at our &lt;a href=&quot;https://avuln.com/forhome&quot;&gt;AVULNATOR&lt;/a&gt; page.&lt;/p&gt;
&lt;p&gt;&lt;img style=&quot;display: block; margin-left: auto; margin-right: auto;&quot; src=&quot;/sites/default/files/files-storage/protect.png&quot; alt=&quot;&quot; width=&quot;300&quot; height=&quot;300&quot; /&gt;&lt;/p&gt;
&lt;p style=&quot;text-align: center;&quot;&gt;Pre-oder does not require payment, but gives your 10% off discount.&lt;/p&gt;
&lt;p style=&quot;text-align: center;&quot;&gt;Placing pre-order now, you help us make AVULNATOR cheaper.&lt;/p&gt;
&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div class=&quot;field field-name-field-tags field-type-taxonomy-term-reference field-label-above&quot;&gt;&lt;div class=&quot;field-label&quot;&gt;Tags:&amp;nbsp;&lt;/div&gt;&lt;div class=&quot;field-items&quot;&gt;&lt;div class=&quot;field-item even&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/avulnator&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;avulnator&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item odd&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/internet-things&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;internet of things&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item even&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/iot&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;IoT&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item odd&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/smart-house&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;smart house&lt;/a&gt;&lt;/div&gt;&lt;div class=&quot;field-item even&quot; rel=&quot;dc:subject&quot;&gt;&lt;a href=&quot;/tags/home&quot; typeof=&quot;skos:Concept&quot; property=&quot;rdfs:label skos:prefLabel&quot; datatype=&quot;&quot;&gt;home&lt;/a&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;</description>
 <pubDate>Thu, 12 Mar 2015 12:21:43 +0000</pubDate>
 <dc:creator>Dor1s</dc:creator>
 <guid isPermaLink="false">2 at https://blog.avuln.com</guid>
 <comments>https://blog.avuln.com/article/2#comments</comments>
</item>
</channel>
</rss>