« March 2014 | Main | May 2014 »

3 posts from April 2014

Apr 25, 2014

Presenting HTML5 security at OWASP AppSec APAC 2014

Hi. This is Yoshinori Matsumoto from Watch and Warning Group.


After JPCERT/CC’s publication of a technical research report on HTML5 last October, our group has been working intensively to raise awareness on security issues of web applications utilizing HTML5. We have been given opportunities to speak at various security conferences on this topic, and one of them was my colleague’s presentation at "CODE BLUE" introduced on this blog earlier. This time, I would like to share some of the technical highlights of my presentation on this topic delivered at “OWASP AppSec APAC 2014


OWASP and OWASP Global AppSec

If you are a security-minded web developer, I am sure you have heard about Open Web Application Security Project (OWASP). OWASP Global AppSec is an international software security conference which deals with web application security. It is organized and held by the OWASP Foundation 4 times a year in various regions, and this time it was held in Japan for the first time from March 17 to 20. You can tell from the number of participants that the locals were very excited about this event - around 400 including developers, researchers, information governance officers, business managers, etc. joined the event.


My Presentation

Under the title “HTML5 Security for Web Application Development”, I referred to the presence of the security issues of web applications using HTML5, along with some demonstrations on functions/elements which inherent risks XMLHttpRequest (XHR) Level2 and HTML5 new input type form and also on the injection attack mitigation measure (Content-Security-Policy HTTP header).


The first demonstration was on XMLHttpRequest (XHR) Level2, an extended functionality of the XHR object. While XHR Level1 supports only same-origin requests, XHR Level2 supports both same-origin and cross-site requests. I showed a case study by using a client browser that supports XHR Level 2. When this client browser is requested to connect in a cross-site manner, there is a possibility that the user may be redirected to a malicious website. Since the URLs which the browser can access is not specified in JavaScript, it allows the so-called Cross-Site Scripting (XSS) attack. I also showed another case study on a user of a file uploader which is vulnerable to Cross-Site Request Forgery (CSRF). Even if the website is not using HTML5, this security issue will take place with the web browsers which supports XHR Level2.


The next demonstration was on <input type="email">, a new input type form in HTML5. This is intended to allow better input control and validation, which restricts the input strings entered from the user only to the email address format. However, this input type can be easily altered by editing the source HTML or sending a request directly to the website. In fact, I showed how this can be simply done by editing the source HTML with a web development tool, namely, Firebug. Thus, this input type is not recommended as a security measure.


The last demonstration was on Content-Security-Policy HTTP header, which mitigates content injection vulnerabilities such as XSS attacks. By implementing this header, it allows website owners to create a white-list of trusted contents and instructs the web browsers to only execute or render resources from those contents. I demonstrated how this can be taken as a safety net for client-side by sending a JavaScript for cross-site request, which successfully ended up preventing the execution.


A photo of me speaking at OWASP AppSec (taken by koyhoge)


For more information about my presentation, please refer to the slides here.



Research report (in English) on HTML5 security to be published

HTML 5 has given us the opportunity to create richer and interactive websites. However, utilization of HTML5 without understanding its inherent risks may cause unintended results. Therefore, we need to carefully understand about HTML5 security issues upon using them. JPCERT/CC’s research report on this matter intends to provide basic references for web security researchers and developers. It is only in Japanese now, but the English version will be coming up in the end of May. We will let you know via this blog, so stay tuned!


Thank you!

- Yoshinori Matsumoto

Apr 18, 2014

Source Port Randomization for Caching DNS Servers Requested, yet again.

Hello, this is Moto Kawasaki, a new member of Global Coordination Division.


Alerts from JPRS and JPCERT/CC

On April 14th 2014, JPRS (Japan Registry Services Co., Ltd.) and JPCERT/CC concurrently published the alerts on DNS cache poisoning attack.


     Alert from JPRS

     http://jprs.jp/tech/security/2014-04-15-portrandomization.html (Japanese version)


     Alert from JPCERT/CC

     https://www.jpcert.or.jp/english/at/2014/at140016.html (English version)

     https://www.jpcert.or.jp/at/2014/at140016.html (Japanese version)


Now I'd like to elaborate on the key points and share my views on the case by reading between the lines of these alerts.


The effect of Source port randomization against cache poisoning

According to the alert issued by JPRS, they made a request for DNS server administrators to randomize the UDP source port number from which caching DNS servers send out query packets as a mitigation against cache poisoning attacks.


Cache poisoning attack is a long-lasting threat on caching DNS servers, injecting arbitrary entry and diverting users to malicious web sites, mail servers, and so forth.

Dan Kaminsky disclosed, in 2008, his method to attack disabled TTL (Time-To-Live) protection by using "not cached data" as query name. This news astonished people because it enabled continuous attack, in fact, from “once in several hours” to “almost anytime”.


On the other hand, source port randomization is considered as the first-choice and mandatory mitigation. Because it increases difficulty for attackers to predict to which port in the range of randomized source port they should send malicious packets, source port randomization reduces the probability of successful attack by one over a few ten-thousands. This is the reason why JPRS recommends source port randomization.


But why did we re-emphasize the risk of cache poisoning attack and importance of source port randomization? JPRS described in their alert by referring to the two recent findings.

One is that JPRS had been informed by large ISPs in Japan that they are observing the increase of cache poisoning attacks with Kaminsky's method.

The other is that JPRS found that approximately 10% of source IP addresses, among the senders of DNS query to JP DNS Servers, did NOT randomize their source port yet.

JPRS kindly supplied a graph (Figure 1) which describes the proportion of the source port randomization observed. We can find several cliffs, swells and overall decline tendency. One of the cliffs might be the aftereffects of Kaminsky’s presentation or from the release of DNS software with randomized source port by default. And at last, 10% of the IP addresses still send queries from static (fixed) or limited (predictable) source ports.


Figure 1 Transition of source port randomization status (Apr-2006 to Apr-2014) by JPRS. 

Trasition_of_source_port_randamizatSource: JPRS (http://jprs.jp/tech/security/2014-04-15-portrandomization-status-e.pdf))


These findings imply, I think, a large number of caching DNS servers are still vulnerable to cache poisoning. This can escalate into domain name hijacking, etc. for the users of such caching DNS servers.


Our gratitude and action in the near future

Based on the list of vulnerable caching DNS servers provided by JPRS, JPCERT/CC is going to notify administrators to fix their setting. And it is our great pleasure to cooperate with other parties, just like we did with JPRS for handling this case.


Finally, I hope this blog entry will help address the issue and make the world of randomized source port :-)


Thank you.

Moto Kawasaki

Apr 04, 2014

APCERT DAY at APRICOT and Open Resolver Check Site Launched by JPCERT/CC

Hello, I am Yukako (Yuka) Uchida from APCERT Secretariat. I am a new Liaison Officer of the Global Coordination Division since last December.


From 18th to 28th February, APRICOT 2014 (https://2014.apricot.net/) had been held in Petaling Jaya, Malaysia. APRICOT, which stands for Asia Pacific Regional Internet Conference on Operational Technologies, is an annual meeting for internet engineers in the region. They have kindly offered APCERT a one-day slot on 26 February to hold the “APCERT DAY”, where speakers from some APCERT Teams (CERT Australia, ID-SIRTII/CC, JPCERT/CC, KrCERT/CC and MyCERT) delivered presentations on their efforts to help create a safe, clean and reliable cyber space in the Asia Pacific region.


The following presentations were given at the workshop. All the filmed contents are currently available on APRICOT program page. (https://2014.apricot.net/program)


Keynote Presentation: “Regional Cyber Security Risk Reduction Approach and Network Operators Network Clean-up Collaboration”

Yurie Ito (APCERT Chair, JPCERT)


“SCADA Security Assessment: The Malaysian Experience”

Ruhama Mohammed Zain (CyberSecurity Malaysia)


“Open DNS Resolver Check Site – Towards a Robust Cyber Space”

Takahiro Ishikawa (JPCERT/CC)


“Cleaning up the Internet – Case Study from Australia”

Scott Brown (CERT Australia)


“Major Internet Incidents and Response – Example from Korea”

Hongsoon Jung (KrCERT/CC)


“Network Metrics – Measuring Network Health”

Yurie Ito (JPCERT/CC)


Plenary Session and Closing: “Collaboration between Network Operators, Registry Services and CERTs on Cyber Risk Reduction and Measurement.”

- Moderator: Yurie Ito (APCERT Chair)

- Panellist: David Conrad (Virtualized), John Crain (ICANN), Yoshinobu Matsuzaki (IIJ)



Facing Open DNS Resolver – JPCERT/CC’s Project


My colleague, Takahiro Ishikawa from Incident Response Team, delivered a presentation about the “Open DNS Resolver Check Site”. It is an online tool released by JPCERT/CC last year, which allows the visitors to check if a DNS server configured on their PC/network device connecting to the site is running as an open DNS resolver or not.


An open DNS resolver, as many of the readers may well know, is a publicly accessible name server that provides a recursive name resolution for unspecified IP addresses. It has been reported that a number of open DNS resolvers are being exploited to participate in massive distributed denial of service (DDoS) attacks – the so called “DNS amplification attack”.


Diagram 1: DNS Amplification Attack Method

(Source: JPCERT/CC)


Here is the attack method. The attacker sends a DNS query - usually requests for as much zone information as possible to maximize the amplification effect - to DNS servers with open resolvers. The source address is spoofed to be the target’s (victim's) address - as in (1) in the diagram. When the DNS servers send the DNS responses (2), they are sent to the target (victim) system and make the victim overwhelmed by excessively large-sized packets in response to the small queries (3).



JPCERT/CC’s Motivation for the Check Site


Takahiro explains that the motivation for launching this tool was actually driven from the statistics published by a private company in early 2013 – that Japan had the largest number of open DNS resolver hosts in the Asia Pacific region at that time. His team was concerned that the open resolver issue is not widely recognised by many internet users and system administrators, and in many cases they are not even aware of running open DNS resolvers on their own. Sometimes it was difficult for the team to reach a contact person that can properly address the issue. They wish that this tool would be helpful in raising awareness towards the problem and in reducing the number of open DNS resolvers.


The Open DNS Resolver Check Site developed by JPCERT/CC offers an easy and simple method to check open DNS resolvers just by accessing the site and giving a few clicks. Please visit the following URL to give it a try:



In addition, his team has also provided a command line tool for those who cannot check using a web browser (e.g. “wget” command). Try using command lines at the following URL:



In case it turns out that you are running an open DNS resolver, you will be provided with some suggested solutions.


JPCERT/CC is willing to keep collaborating with any global partners to address this problem and make the cyber space cleaner and more secure.


Thank you!

-Yukako Uchida