양자컴퓨터... 지금 현존하는 컴퓨터의 계산능력을 초월한 동시계산량을 가지는 컴퓨터라고 한다. 2017년 49큐비트 프로세스로 2의 49승의 동시계산을 수행하는 컴퓨터가 IBM과 구글에서 발표하였다. 


우리가 아는 암호기술은 풀지 못하는 문제가 아니라 푸는데 오랜 시간이 걸리는 문제 인데 이런 양자컴퓨터가 상용화가 된다면 기존의 암호화는 더이상 안전하지 않을것 이라고 이야기 한다.


여기벌써 처음 들어보는 단어가 나왔다.


큐비트(quantum bit, qbit) 

물질의 최소 단위인 양자 정보의 단위다. 일반 컴퓨터가 정보를 0과 1 비트 단위로 처리하고 저장한다면, 양자 컴퓨터는 1과 0의 상태를 동시에 가지는 큐비트를 단위로 쓴다. 


아욱... 수십년 0과 1로만 데이터 처리를 이해하고 있는 사람으로서는 어떻게 1과 0을 동시에 가지지 라고 생각할 수 있다.


아래 그림은 양자 컴퓨터의 특징을 설명하고 있는 그림이다. 


[그림출처] KISA 양자컴퓨팅 환경에서의 암호기술 이용 안내서 



현재의 반도체는 트랜지스터를 기반으로 전류가 흐르면 1, 전류가 흐르지 않으면

 0으로 처리된다. 이 트랜지스터는 점점 작아져서 현재는 더 이상 물리적으로

작게 만들 수 없을 만큼 작게 반도체에 집적된 상태이다.


기존 컴퓨터의 한계를 극복하기 위한 컴퓨터가 양자 컴퓨터이다.


양자 컴퓨터는  작은 에너지 덩어리인 양자가가 가진 중첩과 얽힘이라는 특성을 사용하는 것인데. 이러한 특성 때문이 한개의 입자속에 여러속성을  중첩된 형태로 가질 수 있다. 그리고 이 속성들이 고정된 형태가 아니라 서로 영향을 주고 받으며 얽히는 특성을 가지고 있어 우리의 기존 상식으로 이해하기 어려운 물리 현상이다.



큐비트는 0이면서 동시에 1일수도 있기 때문에 2개의 큐비트는 00,01,10,11 등 4개의 값을 동시에 가질 수 있다. 


이러한 특성으로 큐비트가 표시하는 정보량은 큐비트가 3개일때 8, 4개 일때 16식으로 2의 거듭제곱 형태로 기하급수적으로 늘어나게 된다.


즉, 양자 중첩을 통해 양자 컴퓨터는 기존 컴퓨터와 다르게 병렬계산이 가능해 진다. 양자 컴퓨터의 능력은 슈퍼컴의 36배 이상의 처리 능력을 가진다고 한다. 즉 몇일이 걸리 작업을 한시간이면 가능하다는 것이다.


그래서 미국과 영국, 중국은 수천억달러의 기술 개발비를 투입하면 사활은 건 전쟁을 수행하고 있다.


현재 한국은 삼성이 IBM의 진영에 합류하고 양자컴퓨터 개발에 박차를 가하고 있으며, 구글은 머신러닝, 자율주행, 양자컴퓨터를 묶어서 세계를 제패하려고 하고 있다.


이러한 어마어마한 컴퓨팅 파워는 현재 소인수 분해의 계산 시간이 오래 걸림을 사용하는 암호화 방식이 무용지물이 될 수 있게 할 수 있다.



양자 컴퓨팅 환경에서 권고 되는 양자내성암호 알고리즘은 크게 5가지로 구분 하고 있다. 


[그림출처] KISA 양자컴퓨팅 환경에서의 암호기술 이용 안내서 



양자내성암호별 최적화된 오픈소스 라이브러리가 배포되고 있는 사이트 주소이다.

[그림출처] KISA 양자컴퓨팅 환경에서의 암호기술 이용 안내서 



미리 미리 준비해야 하지 않을까 싶다.

좀 더 시간을 내서 양자내성암호 알고리즘을 하나씩 하나씩 파헤쳐 봐야 겠다.



양자컴퓨팅이란 무엇인가? 를 쉽게 설명하고 있는 동영상이 있어서 링크 걸어본다.

https://www.youtube.com/watch?v=8gWU0KLimNU


"KISA 양자컴퓨팅 환경에서의 암호기술 이용 안내서" 다운로드 링크도 걸어본다.

https://www.kisa.or.kr/public/laws/laws3_View.jsp?cPage=1&mode=view&p_No=259&b_No=259&d_No=96&ST=total&SV=



열공~~~ 화팅!!!!



블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

[그림출처] 엔비디아가 제시하는 인공 지능과 머신 러닝, 딥 러닝의 차이



인공지능: 인간의 지능을 기계로 구현한다.


1956년 인간의 지능과 유사한 특성을 가진 컴퓨터를 만드는 것이 꿈이었다.

인간의 감각, 사고력을 가진 인간처럼 생각하는 인공지능을 우리는 일반 AI(General AI) 라고 한다. 하지만 현재 기술 발전 수준에서 만들어 낼 수 있는 인공지능은( 좀더 좁게 이미지 분류라던가 얼굴인식이라던가) 특정 작업에서 인간 이상의 능력을 보여주는 특징을 가지고 있으며 이를 구분하여 좁은AI(Narrow AI)라고 한다.



머신러닝: 인공지능을 구현하는 구체적 접근 방식


기본적으로 알고리즘을 이용하여 데이터를 분석하고, 분석을 통해 학습하며, 학습한 내용을 기반으로 판단이나 예측한다. 즉 의사 결정의 기준은 소프트웨어에 직접 코딩하는 것이 아니라 대량의 데이터와 알고리즘을 통해 컴퓨터 자체를 학습 시켜 작업을 수행하는 방식이다.




딥러닝:  완전한 머신 러닝을 실현하는 기술


인공신겨앙에서 발전한 형태의 인공지능으로 뇌의 뉴런과 유사한 정보 입출력 계층을 활용해 데이터를 학습한다. 2012년 구글과 스탠퍼드대 앤드류 응(Andrew NG)교수는 16,000개의 컴퓨터로 약 10억개 이상의 신경망으로 이뤄진 '심층신경망(Deep Neural Network)'을 구현했다. - 이 연구는 컴퓨터가 영상에 나온 고양이의 형태와 생김새를 인식하고 판단 하는 과정을 스스로 학습하여 유튜브 동영상에서 사람과 고양이 사진을 분휴하는데 성공하였다.


딥러닝으로 훈련된 시스템의 이미지 인식능력은 이미 인간을 앞서고 있으며, 이 외에도 혈액의 암세포, MRI 스캔에서 종양식별등에서도 인간의 능력을 앞서고 있다. 


딥러닝의 등장으로 머신 러닝의 실용성은 강화되었고, 인공지능의 영역은 확장 되었다. 운전자 없는 자동차, 예방의학, 영화추천과 같은 딥러닝 기반의 기술들이 우리 일상에서 이미 사용되고 있거나 실용화를 앞두고 있다. 


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

IBM 개발자 기술 포럼에 게시된 블록체인의 전반적인 기술을 습득하고, 오픈소스 기반인 Hyperledger Fabric을 활용하여 블록체인 네트워크를 구성하고, 클라이언트를 개발하는 기술을 익힐수 있는 좋은 글이 있어서 링크를 만들었습니다.


IBM의 클라우드 시스템인 Bluemix와 블록체인의 구현 방법을 이해할 수 있는 좋은 기술자료인것 같습니다.



먼저 시작해 보는 블록체인 


01. 블록체인 기본 : 공유원장에 대한 소개

https://developer.ibm.com/kr/cloud/bluemix/2017/01/08/blockchain-basic-01-introduction-to-distributed-ledgers/


02. Hyperledger Fabric

https://developer.ibm.com/kr/cloud/bluemix/blockchain/2017/01/15/blockchain-basic-02-hyperledger-fabric-overview/


03 – Hyperledger Fabric 개발 환경 구성

https://developer.ibm.com/kr/cloud/bluemix/blockchain/2017/01/26/blockchain-basic-03-build_development_environment/


04 – 개발 모드에서 스마트 컨트랙(체인코드) 개발

https://developer.ibm.com/kr/cloud/bluemix/blockchain/2017/01/26/hyperledger_fabric_chaincode_develpement_by_devmode/


05 – 운영 모드에서 스마트 컨트랙(체인코드) 개발

https://developer.ibm.com/kr/cloud/bluemix/blockchain/2017/02/06/hyperledger_fabric_chaincode_develpement_by_prodmode/


06 – Fabric의 설정파일들

https://developer.ibm.com/kr/cloud/bluemix/blockchain/2017/02/12/hyperledger_fabric_configuration_files/


07 – TLS 설정

https://developer.ibm.com/kr/cloud/bluemix/2017/02/19/hyperledger_fabric_tls/


08 – Consensus 적용하기

https://developer.ibm.com/kr/cloud/bluemix/2017/02/26/hyperledger_fabric_consensus/

 

 

IBM Blockchain Developer Center

https://developer.ibm.com/blockchain/

블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

출처: https://www.google.com/about/appsecurity/reward-program/


Google Vulnerability Reward Program (VRP) Rules

We have long enjoyed a close relationship with the security research community. To honor all the cutting-edge external contributions that help us keep our users safe, we maintain a Vulnerability Reward Program for Google-owned web properties, running continuously since November 2010.

Services in scope(대상서비스)

 *.google.com

 *.youtube.com

 *.blogger.com


In principle, any Google-owned web service that handles reasonably sensitive user data is intended to be in scope. This includes virtually all the content in the following domains:

  • *.google.com
  • *.youtube.com
  • *.blogger.com

Bugs in Google-developed apps and extensions (published in Google Play, in iTunes, or in the Chrome Web Store) will also qualify.

On the flip side, the program has two important exclusions to keep in mind:

  • Third-party websites. Some Google-branded services hosted in less common domains may be operated by our vendors or partners (this notably includeszagat.com). We can’t authorize you to test these systems on behalf of their owners and will not reward such reports. Please read the fine print on the page and examine domain and IP WHOIS records to confirm. If in doubt, talk to us first!
  • Recent acquisitions. To allow time for internal review and remediation, newly acquired companies are subject to a six-month blackout period. Bugs reported sooner than that will typically not qualify for a reward.

Qualifying vulnerabilities (보상대상 취약점)


- XSS(Cross-site scripting)

- CSRF(Cross-site request forgery)

- Mixed-content scripts(HTTPS페이지에서 HTTP를 로드하는 경우 발생하는 ㅟ약점)

- Authentication or authorization flaws

- Server-side code execution bugs


Any design or implementation issue that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program. Common examples include:

  • Cross-site scripting,
  • Cross-site request forgery,
  • Mixed-content scripts,
  • Authentication or authorization flaws,
  • Server-side code execution bugs.

Note that the scope of the program is limited to technical vulnerabilities in Google-owned browser extensions, mobile, and web applications; please do not try to sneak into Google offices, attempt phishing attacks against our employees, and so on.

Out of concern for the availability of our services to all users, please do not attempt to carry out DoS attacks, leverage black hat SEO techniques, spam people, or do other similarly questionable things. We also discourage the use of any vulnerability testing tools that automatically generate very significant volumes of traffic.

Non-qualifying vulnerabilities   (대상이 아닌 취약점)


- 샌드박스 도메인 내에서 발생하는 XSS

- URL redirection

- 합법적인 프록싱

- 거의 발생하지 않는 사용자의 인터렉션을 요구하는 경우

- 로그아웃 CSRF

- 이전 버번의 브라우저와 플러그인에서만 발생하는 경우

- 배너나 버전 정보 노출


New! Visit our Bug Hunter University page dedicated to common non-qualifying findings and vulnerabilities.

Depending on their impact, some of the reported issues may not qualify. Although we review them on a case-by-case basis, here are some of the common low-risk issues that typically do not earn a monetary reward:

  • Cross-site scripting vulnerabilities in “sandbox” domains (read more.) We maintain a number of domains that leverage the same-origin policy to safely isolate certain types of untrusted content; the most prominent example of this is *.googleusercontent.com. Unless an impact on sensitive user data can be demonstrated, we do not consider the ability to execute JavaScript in that domain to be a bug.
  • Execution of owner-supplied JavaScript in Blogger. Blogs hosted in *.blogspot.com are no different from any third-party website on the Internet. For your safety, we employ spam and malware detection tools, but we do not consider the ability to embed JavaScript within your own blog to be a security bug.
  • URL redirection (read more.) We recognize that the address bar is the only reliable security indicator in modern browsers; consequently, we hold that the usability and security benefits of a small number of well-designed and closely monitored redirectors outweigh their true risks.
  • Legitimate content proxying and framing. We expect our services to unambiguously label third-party content and to perform a number of abuse-detection checks, but as with redirectors, we think that the value of products such as Google Translate outweighs the risk.
  • Bugs requiring exceedingly unlikely user interaction. For example, a cross-site scripting flaw that requires the victim to manually type in an XSS payload into Google Maps and then double-click an error message may realistically not meet the bar.
  • Logout cross-site request forgery (read more.) For better or worse, the design of HTTP cookies means that no single website can prevent its users from being logged out; consequently, application-specific ways of achieving this goal will likely not qualify. You may be interested in personal blog posts from Chris Evansand Michal Zalewski for more background.
  • Flaws affecting the users of out-of-date browsers and plugins. The security model of the web is being constantly fine-tuned. The panel will typically not reward any problems that affect only the users of outdated or unpatched browsers. In particular, we exclude Internet Explorer prior to version 9.
  • Presence of banner or version information. Version information does not, by itself, expose the service to attacks - so we do not consider this to be a bug. That said, if you find outdated software and have good reasons to suspect that it poses a well-defined security risk, please let us know.

Monetary rewards aside, vulnerability reporters who work with us to resolve security bugs in our products will be credited on the Hall of Fame. If we file an internal security bug, we will acknowledge your contribution on that page.

Reward amounts   (보상금액)  $100~$20,000

New! To read more about our approach to vulnerability rewards you can read our Bug Hunter University article here.

Rewards for qualifying bugs range from $100 to $20,000. The following table outlines the usual rewards chosen for the most common classes of bugs:

CategoryExamplesApplications that permit taking over a Google account [1]Other highly sensitive applications [2]Normal Google applicationsNon-integrated acquisitions and other sandboxed or lower priority applications [3]
Vulnerabilities giving direct access to Google servers
Remote code executionCommand injection, deserialization bugs, sandbox escapes$20,000$20,000$20,000$1,337 - $5,000
Unrestricted file system or database accessUnsandboxed XXE, SQL injection$10,000$10,000$10,000$1,337 - $5,000
Logic flaw bugs leaking or bypassing significant security controlsDirect object reference, remote user impersonation$10,000$7,500$5,000$500
Vulnerabilities giving access to client or authenticated session of the logged-in victim
Execute code on the clientWebCross-site scripting
MobileCode execution
$7,500$5,000$3,133.7$100
Other valid security vulnerabilitiesWebCSRF, Clickjacking
MobileInformation leak, privilege escalation
$500 - $7,500$500 - $5,000$500 - $3,133.7$100

[1] For example, for web properties this includes some vulnerabilities in Google Accounts (https://accounts.google.com).

[2] This category includes products such as Google Search (https://www.google.com and https://encrypted.google.com), Google Wallet (https://wallet.google.com), Google Mail (https://mail.google.com), Google Inbox (https://inbox.google.com), Google Code Hosting (code.google.com), Chrome Web Store (https://chrome.google.com), Google App Engine (https://appengine.google.com), Google Admin (https://admin.google.com), Google Developers Console (https://console.developers.google.com), and Google Play (https://play.google.com).

[3] Note that acquisitions qualify for a reward only after the initial six-month blackout period has elapsed.

The final amount is always chosen at the discretion of the reward panel. In particular, we may decide to pay higher rewards for unusually clever or severe vulnerabilities; decide to pay lower rewards for vulnerabilities that require unusual user interaction; decide that a single report actually constitutes multiple bugs; or that multiple reports are so closely related that they only warrant a single reward.

We understand that some of you are not interested in money. We offer the option to donate your reward to an established charity. If you do so, we will double your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.

Investigating and reporting bugs

When investigating a vulnerability, please, only ever target your own accounts. Never attempt to access anyone else's data and do not engage in any activity that would be disruptive or damaging to your fellow users or to Google.

New! Visit our Bug Hunter University articles to learn more about sending good vulnerability reports.

If you have found a vulnerability, please contact us at goo.gl/vulnzPlease be succinct: the contact form is attended by security engineers and a short proof-of-concept link is more valuable than a video explaining the consequences of an XSS bug. If necessary, you can use this PGP key.

Note that we are only able to answer to technical vulnerability reports. Non-security bugs and queries about problems with your account should be instead directed toGoogle Help Centers.

Frequently asked questions

Q: What if I found a vulnerability, but I don't know how to exploit it?

A: We expect that vulnerability reports sent to us have a valid attack scenario to qualify for a reward, and we consider it as a critical step when doing vulnerability research. Reward amounts are decided based on the maximum impact of the vulnerability, and the panel is willing to reconsider a reward amount, based on new information (such as a chain of bugs, or a revised attack scenario).

Q: How do I demonstrate the severity of the bug if I’m not supposed to snoop around?

A: Please submit your report as soon as you have discovered a potential security issue. The panel will consider the maximum impact and will chose the reward accordingly. We routinely pay higher rewards for otherwise well-written and useful submissions where the reporter didn't notice or couldn't fully analyze the impact of a particular flaw.

Q: I found an outdated software (e.g. Apache or Wordpress). Does this qualify for a reward?

A: Please perform due diligence: confirm that the discovered software had any noteworthy vulnerabilities, and explain why you suspect that these features may be exposed and may pose a risk in our specific use. Reports that do not include this information will typically not qualify.

Q: Who determines whether my report is eligible for a reward?

A: The reward panel consists of the members of the Google Security Team. The current permanent members are Artur Janc, Eduardo Vela Nava, Jeremy Zimmer, Martin Straka, and Michal Zalewski. In addition there is a rotating member from the rest of our team.

Q: What happens if I disclose the bug publicly before you had a chance to fix it?

A: Please read our stance on coordinated disclosure. In essence, our pledge to you is to respond promptly and fix bugs in a sensible timeframe - and in exchange, we ask for a reasonable advance notice. Reports that go against this principle will usually not qualify, but we will evaluate them on a case-by-case basis.

Q: I wish to report an issue through a vulnerability broker. Will my report still qualify for a reward?

A: We believe that it is against the spirit of the program to privately disclose the flaw to third parties for purposes other than actually fixing the bug. Consequently, such reports will typically not qualify.

Q: What if somebody else also found the same bug?

A: First in, best dressed. You will qualify for a reward only if you were the first person to alert us to a previously unknown flaw.

Q: My employer / boyfriend / dog frowns upon my security research. Can I report a problem privately?

A: Sure. If you are selected as a recipient of a reward, and if you accept, we will need your contact details to process the payment. You can still request not to be listed on our public credits page.

Q: What is bughunter.withgoogle.com?

A: The dashboard for the participants in Google’s VRP program. It dynamically creates the hall of fame, i.e., the 0x0A and honorable mentions lists.

Q: Do I need a profile on bughunter.withgoogle.com to participate in the VRP?

A: No. You can participate in the VRP under the same rules without the need of a profile. However, if you want your name to be listed in the 0x0A or the honorable mentions lists, you need to create a profile.

Q: Is the profile data publicly available?

A: Yes. The profile holds the data that is currently already available now on our hall of fame, i.e., on the 0x0A and honorable mentions lists. You can always leave these fields blank.

Q: How is the honorable mentions list sorted?

A: The hall of fame is sorted based on the volume of valid bug submissions, the ratio of valid vs. invalid submissions, and the severity of those submissions.

We are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists. You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon your local law.

This is not a competition, but rather an experimental and discretionary rewards program. You should understand that we can cancel the program at any time and the decision as to whether or not to pay a reward has to be entirely at our discretion.

Of course, your testing must not violate any law, or disrupt or compromise any data that is not your own.

블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

데이터베이스 암호화

2015.08.22 21:16

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

슈퍼쿠키란?

2015.07.08 23:49

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

원본: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html


TIOBE Index for March 2015

March Headline: All time high for F# at position 11

Microsoft's programming language F# is about to sneak into the top 10. It is not clear why F# is gaining popularity. Possible reasons might be the F# web-programming framework WebSharper and the promotional work of the F# Software Foundation as Tomas Petricek (author of "F# Deep Dives") stated in an interview about 2 weeks ago. Another interesting move this month: CoffeeScript enters the top 100 for the first time.

The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.

The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system. The definition of the TIOBE index can be found here.

Mar 2015Mar 2014ChangeProgramming LanguageRatingsChange
11C16.642%-0.89%
22Java15.580%-0.83%
33Objective-C6.688%-5.45%
44C++6.636%+0.32%
55C#4.923%-0.65%
66PHP3.997%+0.30%
79changeJavaScript3.629%+1.73%
88Python2.614%+0.59%
910changeVisual Basic .NET2.326%+0.46%
10-changeVisual Basic1.949%+1.95%
1112changeF#1.510%+0.29%
1213changePerl1.332%+0.18%
1315changeDelphi/Object Pascal1.154%+0.27%
1411changeTransact-SQL1.149%-0.33%
1521changePascal1.092%+0.41%
1631changeABAP1.080%+0.70%
1719changePL/SQL1.032%+0.32%
1814changeRuby1.030%+0.06%
1920changeMATLAB0.998%+0.31%
2045changeR0.951%+0.72%


Ratings (%)2002200420062008201020122014051015202530Wednesday, Dec 2, 2009● Java: 17.061%TIOBE Programming Community IndexSource: www.tiobe.com
C
Java
Objective-C
C++
C#
PHP
JavaScript
Python
Visual Basic .NET
Visual Basic

Other programming languages

The complete top 50 of programming languages is listed below. This overview is published unofficially, because it could be the case that we missed a language. If you have the impression there is a programming language lacking, please notify us at tpci@tiobe.com. Please also check the overview of all programming languages that we monitor.

PositionProgramming LanguageRatings
21SAS0.936%
22Logo0.876%
23Swift0.816%
24COBOL0.736%
25ML0.699%
26PostScript0.666%
27OpenEdge ABL0.626%
28Assembly0.620%
29Fortran0.607%
30ActionScript0.546%
31D0.504%
32Lisp0.501%
33Scratch0.472%
34Ada0.468%
35Scala0.456%
36Groovy0.413%
37Lua0.409%
38C shell0.402%
39Prolog0.377%
40Max/MSP0.355%
41Scheme0.324%
42RPG (OS/400)0.314%
43Awk0.298%
44PL/I0.283%
45Inform0.272%
46VBScript0.270%
47Go0.261%
48Z shell0.231%
49(Visual) FoxPro0.230%
50LabVIEW0.227%

The Next 50 Programming Languages

The following list of languages denotes #51 to #100. Since the differences are relatively small, the programming languages are only listed (in alphabetical order).

  • 4th Dimension/4D, Alice, Apex, Arc, Automator, Bash, bc, Bourne shell, C-Omega, cg, CL (OS/400), Clean, Clojure, CoffeeScript, cT, Dart, DiBOL, Eiffel, Erlang, Factor, Forth, Hack, Haskell, Icon, IDL, Io, Ioke, J, J#, Korn shell, Ladder Logic, M4, Magic, Mathematica, Moto, NATURAL, NXT-G, OpenCL, Oz, PILOT, PowerShell, Programming Without Coding Technology, Pure Data, Q, S, SPARK, SPSS, Standard ML, Tcl, VHDL


This Month's Changes in the Index

This month the following changes have been made to the definition of the index:

  • There are lots of mails that still need to be processed. As soon as there is more time available your mail will be answered. Please be patient.

Very Long Term History

To see the bigger picture, please find the positions of the top 10 programming languages of many years back. Please note that these are average positions for a period of 12 months.

Programming Language2015201020052000199519901985
C1211211
Java2123---
Objective-C32038----
C++44321212
C#5589---
PHP63426---
Python7662322--
JavaScript8896---
Perl9754914-
Visual Basic .NET10------
Pascal151366133155
Lisp1915138552
Ada30261516663
Fortran312314174311

Programming Language Hall of Fame

The hall of fame listing all "Programming Language of the Year" award winners is shown below. The award is given to the programming language that has the highest rise in ratings in a year. 

YearWinner
2014medal JavaScript
2013medal Transact-SQL
2012medal Objective-C
2011medal Objective-C
2010medal Python
2009medal Go
2008medal C
2007medal Python
2006medal Ruby
2005medal Java
2004medal PHP
2003medal C++


Bugs & Change Requests

This is the top 5 of most requested changes and bugs. If you have any suggestions how to improve the index don't hesitate to send an e-mail to tpci@tiobe.com.

  1. Apart from "<language> programming", also other queries such as "programming with <language>", "<language> development" and "<language> coding" should be tried out.
  2. Add queries for other natural languages (apart from English). The idea is to start with the Chinese search engine Baidu. This has been implemented partially and will be completed the next few months.
  3. Add a list of all search term requests that have been rejected. This is to minimize the number of recurring mails about Rails, JQuery, JSP, etc.
  4. Start a TIOBE index for databases, software configuration management systems and application frameworks.
  5. Some search engines allow to query pages that have been added last year. The TIOBE index should only track those recently added pages.


Frequently Asked Questions (FAQ)

  • Q: Am I allowed to show the TIOBE index in my weblog/presentation/publication?

    A: Yes, the only condition is to refer to its original source "www.tiobe.com".

  • Q: How may I nominate a new language to be added to the TIOBE index?

    A: If a language meets the criteria of being listed (i.e. it is Turing complete and has an own Wikipedia entry that indicates that it concerns a programming language) and it is sufficiently popular (more than 25,000 hits for +"<language> programming" for Google), then please write an e-mail to tpci@tiobe.com.

  • Q: I would like to have the complete data set of the TIOBE index. Is this possible?

    A: We spent a lot of effort to obtain all the data and keep the TIOBE index up to date. In order to compensate a bit for this, we ask a fee of 5,000 US$ for the complete data set. The data set runs from June 2001 till today. It started with 25 languages back in 2001, and now measures more than 150 languages once a month. The data are availabe in comma separated format. Please contactsales@tiobe.com for more information.

  • Q: Why is the maximum taken to calculate the ranking for a grouping, why not the sum?

    A: Well, you can do it either way and both are wrong. If you take the sum, then you get the intersection twice. If you take the max, then you miss the difference. Which one to choose? Suppose somebody comes up with a new search term that is 10% of the original. If you take the max, nothing changes. If you take the sum then the ratings will rise 10%. So taking the sum will be an incentive for some to come up with all kinds of obscure terms for a language. That's why we decided to take the max.

    The proper way to solve this is is of course to take the sum and subtract the intersection. This will give rise to an explosion of extra queries that must be performed. Suppose a language has a grouping of 15 terms, then you have to perform 32,768 queries (all combinations of intersections). So this seems not possible either... If somebody has a solution for this, please let us know.

  • Q: What happened to Java in April 2004? Did you change your methodology?

    A: No, we did not change our methodology at that time. Google changed its methodology. They performed a general sweep action to get rid of all kinds of web sites that had been pushed up. As a consequence, there was a huge drop for languages such as Java and C++. In order to minimize such fluctuations in the future, we added two more search engines (MSN and Yahoo) a few months after this incident.

  • Q: Why is YouTube used as a search engine for the TIOBE index?

    A: First of all, YouTube counts for less than 10% of all ratings, so it has hardly any influence on the index. YouTube has been added as an experiment. It qualified for the TIOBE index because of its high ranking on Alexa. YouTube is a young platform (so an indicator for popularity) and there are quite some lectures, presentations, programming tips and language introductions available on YouTube.


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

하트블리드(HeartBleed)' 취약점


HeartBeat는 OpenSSL에서 사용하는 확장규격중 하나인데, 서버와 클라이언트 사이에 안정적인 연결을 유지하기 위해 클라이언트가 임의의 정보를 정보의 길이와 함께 서버에게 전달하면 서버에서는 수신된 정보를 다시 클라이언트에 응답하여 연결상태를 알려준다.


클라이언트가  서버에게  YES(100글자) --> 를 보내게 되면 서버는 잘못된 정보라고 인식하고 응답을 하지 않아야 하는데  100바이트를 받았으니 100바이트를 응답하게 된다.


이때  메모리에 [YES ID:admin PASSWORD: 1234 ....  ] 와 같이 저장되어 있었다면 서버는 YES를 포함한 100바이트의 정보를 클라이언트에게 전송하게 된다.


클라이언트는 한번에 최대 64KB의 정보를 요청할 수 있다.  실제 64KB에  저장되는 정보는 많은것이 아니지만 지속적으로 정보를 수집하게 되면 의미를 가지는 정보(메모리에 저장되어 있는 개인키나 관리정보와 같은 민감한 데이터)를  얻을 수 있게 될것이다. 


<참고> 64K 까지 요청을 처리하는 이유

struct {

            unsigned short len;   <-- 길이를 저장하는 변수 len이 부호없는 2바이트

            char payload[];                 사용. 2바이트 최대 나타낼수 있는 수가 65536

} packet;



※ 영향을 받는 버전 

OpenSSL 1.0.1 ~ OpenSSL 1.0.1f

OpenSSL 1.0.2-beta, OpenSSL 1.0.2-beta1


※ 영향을 받지 않는 버전 

OpenSSL 0.9.x 버전

OpenSSL 1.0.0 버전

OpenSSL 1.0.1g 



※ 패치방법


1. OpenSSL 버전을 1.0.1g 버전으로 업데이트 한다.


또는 


2. 운영환경의 특수성 때문에 패키지 형태의 업데이트가 어려운 경우, Heartbeat를 사용하지 않도록 컴파일 옵션을 설정하여 재컴파일 해서 사용

# ./config -DOPENSSL_NO_HEARTBEATS

# make depend

# make

# make install


또는


3. 네트워크 보안 장비에서 취약점 탐지 및 차단 패턴을 적용한다.



※ 추가적인 보안 조치


취약한 버전의 OpenSSL을 사용하고 있었다면, 서버측 SSL비밀키가 유출되었을 가능이 있기 때문에 인증서 재발급을 검토해야 하고, 사용자들의 비밀번호도 유출가능성이 있기 때문에 사용자들이 비밀번호를 재설정하도록 유도하여 추가 피해를 방지할 수 있어야 한다.



 http://blog.alyac.co.kr/76   <-- 링크를 클릭하면 더 자세한 정보를 볼 수 있어요 ^^

'보안 > 보안기술동향' 카테고리의 다른 글

구글 버그 바운티 프로그램  (0) 2015.10.25
TIOBE Index for March 2015  (0) 2015.04.05
하트블리드(HeartBleed)' 취약점  (0) 2014.11.13
SSLv3 'POODLE' 취약점  (0) 2014.11.13
bash 쉘 취약점  (0) 2014.10.05
보안분야?  (0) 2014.07.18
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

SSLv3 'POODLE' 취약점 


CVE-2014-3566  푸들(Poodle, Padding Oracle On Downgraded Legacy Encryption)이라고 명명된 이 취약점은 HTTPS에서 사용되는 암호화 프로토콜 네고시 버전 다운그래이드 공격을 통해 SSL 3.0을 사용하도록 강제하여,  MITM(Man In The Middle) 공격을 통해  암호화 되어서 송수신되는 쿠키정보나 데이터를 추출할 수 있는 취약점이다.


SSLV3의 POODLE 취약점은  블록암호화기법인 CBC모드를 사용하는 경우 발생하는 패딩된 암호블록이 MAC(메시지인증코드)에 의해 보호 되지 않기 때문에 발생한다.


공격자는 이 취약점을 가지고 있지 않은 TLS 버전을 사용하는 클라이언트와 서버의 핸드쉐이킹 과정에 끼어 들어 TLS가 지원되지 않는다는 변조된 메시지를 클라이언트에게 전송하여 SSLv3로 다운그레이드 시켜 통신이 연결되도록 한다.


이 취약점을 제거하기 위해서는 SSL의 상위버전인 TLS 1.0 이상의 버전이 사용되도록 해야 하며,  연결을 위한 핸드쉐이크 과정에서 다운그레이드가 되지 않도록 하는 옵션이 보안 장비나  클라이언트 소프트웨어에 설정되어야 한다.


프로토콜 다운그레이드 취약점을 제거하기 위해서는 각 서버마다 설정이 다르므로 다음 링크를 참조한다.

http://blog.alyac.co.kr/183



'보안 > 보안기술동향' 카테고리의 다른 글

TIOBE Index for March 2015  (0) 2015.04.05
하트블리드(HeartBleed)' 취약점  (0) 2014.11.13
SSLv3 'POODLE' 취약점  (0) 2014.11.13
bash 쉘 취약점  (0) 2014.10.05
보안분야?  (0) 2014.07.18
Apache Struts2 원격 코드 실행 취약점  (0) 2014.04.24
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

bash Shell 취약점


리눅스, 유닉스 계열의 운영체제에서 사용 중인 GNU Bash에서 발생하는 취약점이다.

Bash 환경변수의 함수정의를 이용하여 원하는 코드 추가를 하거나 실행할 수 있는 문제인데, 공격자는 이 취약점을 이용하여 사용자의 컴퓨터에 임의의 코드를 구동할 수 있게 하므로 그 위험도가 무척 높다.


CVE-2014-6271 및 CVE-2014-7169로 취약점이 등록되었고 그 위험도는 가장 높은 단계로 지정되어있어, 취약점에 노출된 모든 기기를 업데이트해줘야 한다. 취약점은 이를 압도하는 보한 결함으로 여겨지고 있습니다.


안드로드이드, MacOS, 리눅스, 유닉스 계열의 많은 시스템이 이 취약점에 노출 될 수 있다.


bash 버전 확인


# echo $BASH_VERSION



bash Shell 취약점  확인 


우선 자신의 운영체제가 Bash Shell 취약점에 노출되었는지를 확인한다.

터미널에서 환경변수 x 를 다음과 같은 함수로 설정한 뒤 실행하여 실행 결과를 확인한다.


env x='() { :;}; echo vulnerable' bash -c "echo this is a test"


실행결과가 this is a test 만 출력된다면 취약점을 가지고 있지 않다.


하지만 실행결과가

vulnerable

this is a test

가 출력된다면 취약성을 가지고 있으므로 반드시 패치를 수행하도록 해야 한다.




bash shell 취약점 대응 


센토:           http://lists.centos.org/pipermail/centos/2014-September/146154.html

데비안:         https://www.debian.org/security/2014/dsa-3035
레드햇:         https://rhn.redhat.com/errata/RHSA-2014-1306.html
우분투:         http://www.ubuntu.com/usn/usn-2363-2/





'보안 > 보안기술동향' 카테고리의 다른 글

하트블리드(HeartBleed)' 취약점  (0) 2014.11.13
SSLv3 'POODLE' 취약점  (0) 2014.11.13
bash 쉘 취약점  (0) 2014.10.05
보안분야?  (0) 2014.07.18
Apache Struts2 원격 코드 실행 취약점  (0) 2014.04.24
OpenSSL 취약점 대응 방안 권고  (0) 2014.04.24
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

보안의 범위는? 

"ISEC 2014 에서 궁금증을 물어보세요." 라고 하면서 질문이 카테고리를 만들어서 메일을 날렸네요.

찬찬히 읽어보다 카테고리에 번호를 붙여봤습니다. 41개. 이것말고 뭐가 더 있을까? 하고 고민을 해 본다.


1. 금융보안

2. 개발보안 (시큐어코딩) 

3. 핵티비즘 등 사이버테러

4. 네트워크 보안

5. 클라우드 보안

6. APT 대응

7. 디지털포렌식

8. 스마트 보안

9. 임베디드 보안

10. 소셜 네트워크 서비스 (SNS) 보안

11. DB암호화 / DB 접근제어

12. 보안관제, 컨설팅

13. 저작권 관리 및 컨텐츠 보호

14. 정보폐기

15. 개인정보보호 / 개인정보 접속이력 관리

16. 보안정책, 예산

17. 보안조직, 이력

18. 게임보안

19. 웹사이트 보안

20. 보이스피싱

21. CCTV

22. 출입통제

23. 바이오인식

24. 융합보안

25. 내부정보유출방지 (DLP)

26. 문서보안 (DRM)

27. 보안취약점 점검·관리

28. 모의해킹

29. 스미싱, 파밍

30. 빅데이터 보안

31. 사물인터넷 (IoT) 보안

32. 보안인증 제도

33. 보안자격증

34. 보안관련 법률분쟁, 소송

35. 보안관련 법규 (개인정보보호법, 정보통신망법 외)

36. OTP / 2차 인증

37. 망 분리 / 망 연계

38. MDM

39. 출력물 보안

40. 엔드포인트 보안 / 안티 바이러스

41. 외주인력 관리

  

'보안 > 보안기술동향' 카테고리의 다른 글

SSLv3 'POODLE' 취약점  (0) 2014.11.13
bash 쉘 취약점  (0) 2014.10.05
보안분야?  (0) 2014.07.18
Apache Struts2 원격 코드 실행 취약점  (0) 2014.04.24
OpenSSL 취약점 대응 방안 권고  (0) 2014.04.24
LDAP 정보 구조  (0) 2013.10.16
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

2013년 7월 16일 Apache Struts2의 취약점(CVE-2013-2251)이 공개되었다. 해당 취약점은 Apache Struts의 특정 매개변수에 공격 구문을 전달하여, 파일 생성 및 원격 명령을 수행 할 수 있다.

7월 17일 오후 Apache Struts2 공격툴이 공개된 이후 해당 취약점을 이용한 공격이 급증하고 있으며 기업의 중요 서버에 대한 침입 시도와 피해 사례가 다수 확인되고 있다.

Apache.org는 이 취약점을 위험도 [매우 위험]으로 구분하고 있으며, 현재 패치를 제작하여 배포하고 있다.

이번 보안 업데이트의 적용 대상은 다음과 같다.

 Struts 2.0.0 - Struts 2.3.15

취약점은 Apache Struts 2.3.15 이하의 버전에서 “action:”, “redirect:”, “redirectAction:”와 같은 매개변수에 특정 구문이 전달될 때, Struts가 해당 매개변수들에 대한 입력 값 검증을 제대로 수행하지 않아 발생한다. 공격자는 원격에서 임의의 코드를 삽입할 수 있으며, 검증되지 않은 해당 코드를 서버에 삽입할 수 있다.

공격 예를 다음과 같다.

    hxxp://target/X.action?action:%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()} 


    hxxp://target/save.action?redirect:%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()} 


    hxxp://target/save.action?redirectAction:%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()}


현재 관련 공격 도구가 등장해 공격자가 손쉽게 공격 할 수 있다.


Struts2 취약점 공격도구 1


Struts2 취약점 공격도구 2


공격 도구를 이용할 경우 다음과 같은 GET 명령을 볼 수 있다.


취약점 해결을 위해 Struts 2.3.15 이하 버전은 2.3.15.1 이상으로 업데이트 해야 한다.

다운로드 주소 : http://struts.apache.org/download.cgi#struts23151


자세한 내용은 다음 주소를 참고하면 된다.

http://struts.apache.org/release/2.3.x/docs/s2-016.html


안랩 TrusGuard 제품군에서는 다음 시그니처로 해당 공격을 차단 할 수 있다.
-  Apache_struts_attack_tool (CVE-2013-2251)
-  Apache_struts_remote_command_exec(CVE-2013-2251)



'보안 > 보안기술동향' 카테고리의 다른 글

bash 쉘 취약점  (0) 2014.10.05
보안분야?  (0) 2014.07.18
Apache Struts2 원격 코드 실행 취약점  (0) 2014.04.24
OpenSSL 취약점 대응 방안 권고  (0) 2014.04.24
LDAP 정보 구조  (0) 2013.10.16
[링크] 정보보안의 ABC, CBK를 이해하자  (0) 2013.09.24
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

출처: KISA 

OpenSSL 취약점(HeartBleed) 대응 방안 권고2014.04.14

개요

  • 통신 구간 암호화를 위해 많이 사용하는 OpenSSL 라이브러리에서 서버에 저장된 중요 메모리 데이터가 노출되는 HeartBleed라고 명명된 심각한 버그가 발견되어 시스템 및 소프트웨어에 대한 신속한 취약점 조치를 권고

취약점 정보

  • 시스템 메모리 정보 노출 취약점
    • CVE-2014-0160 (2014.04.07.)
  • 영향 받는 버전
    • OpenSSL 1.0.1 ~ OpenSSL 1.0.1f
    • OpenSSL 1.0.2-beta, OpenSSL 1.0.2-beta1
  • 영향 받는 시스템 및 소프트웨어
    • 취약한 OpenSSL 버전이 탑재된 시스템
      • 서버(웹서버, VPN 서버 등), 네트워크 장비, 모바일 단말 등 다양한 시스템이 해당될 수 있음
    • 취약한 OpenSSL 라이브러리가 내장된 소프트웨어 제품
  • 영향 받지 않는 소프트웨어
    • OpenSSL 0.9.x 대 버전
    • OpenSSL 1.0.0 대 버전
    • OpenSSL 1.0.1g

취약점 내용

  • OpenSSL 암호화 라이브러리의 하트비트(Heartbeat)라는 확장 모듈에서 클라이언트 요청 메시지를 처리할 때 데이터 길이 검증을 수행하지 않아 시스템 메모리에 저장된 64KB 크기의 데이터를 외부에서 아무런 제한 없이 탈취할 수 있는 취약점
    • 하트비트 : 클라이언트와 서버 간의 연결 상태 체크를 위한 OpenSSL 확장 모듈

공격 형태

  • 본 취약점은 원격에서 발생 가능한 취약점으로, 공격자는 메시지 길이 정보가 변조된 HeartBeat Request 패킷을 취약한 OpenSSL 버전을  사용하는 서버에 전송할 경우, 정해진 버퍼 밖의 데이터를 공격자에게 전송하게 되어 시스템 메모리에 저장된 개인정보 및 인증 정보 등을 탈취할 수 있음

공격방법

                       ※ 노출 가능한 정보: SSL 서버 비밀키, 세션키, 쿠키  및 개인정보(ID/PW, 이메일주소 등) 등
                       ※ 노출되는 정보는 서비스 환경에 따라 다를 수 있음

  

취약점 확인 절차

  • 점검 대상 선정
    • 서버, 네트워크, 보안 장비 등의 시스템에서 OpenSSL 설치 여부 확인
    • 웹 서버의 경우 서브 도메인을 운영하는 시스템도 점검 대상에 포함
      • 서브 도메인 : mail.example.com, blog.example.com 등
    • 시스템뿐만 아니라 소프트웨어 제품 자체에 OpenSSL 라이브러리가  내장되어 있을 경우 버전 확인 후 점검 대상에 포함
  • 취약점 노출 여부 확인 방법
    • 명령어를 통한 OpenSSL 버전 정보 확인
      • openssl이 설치된 시스템에서 아래 명령어를 입력하여 취약점에 영향 받는 버전을 사용하는지 확인

점검

    • OpenSSL 하트비트(HeartBeat) 활성화 여부 확인
      • 취약한 버전의 OpenSSL을 사용하는 시스템 중 HeartBeat 기능 사용 여부 확인 방법 (단, 패치된 최신 버전(1.0.1g)은 활성화 여부를 확인할 필요 없음)
      • 취약한 버전이 HeartBeat를 사용하지 않은 경우 취약점에 영향 받지 않음   

점검2

                       ※ 명령어 실행 방법 : domain.com에 점검 대상 URL 정보로 수정

                       ※ HeartBeat 기능이 활성화되어 있는 경우 heartbeat 문자열이 검색됨

   점검3

                       ※ HeartBeat 기능이 활성화되지 않은 경우 heartbeat 문자열이 검색되지 않음

점검4

  • OpenSSL에서 사용하는 소스코드 확인
    • OpenSSL 취약점이 발생된 소스코드를 열람하여 아래와 같이 보안 패치 코드가 추가되었는지 확인을 통해 취약 여부 판별
    • 패치된 버전에서는 아래와 같이 사용자 요청 메시지에 대한 길이를 검사하도록 코드가 추가됨

소스코드

                        ※ 참고 사이트 : http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902

  • KISA(한국인터넷진흥원)를 통한 취약점 여부 확인
    • 자체적인 확인이 어려울 경우 KISA 전문가로부터 점검을 요청
      연락처

해결 방안

 

<시스템 측면 대응 방안>

  • OpenSSL 버전을 1.0.1g 버전으로 업데이트
  • 서비스 운영환경에 따른 소프트웨어 의존성 문제를 고려하여 업데이트 방법을 선택하고 반드시 먼저 테스트 수행
      • 아래 보안 패치 방법은 CentOS/Fedora 및 Ubuntu의 예제로 각 운영체제 별로 업데이트 방법이 상이할 수 있음
    • CentOS/Fedora
      • 전체 시스템 업데이트(OpenSSL을 포함한 시스탬 내의 소프트웨어 전부 업데이트) 

업데이트

  • OpenSSL 업데이트

업데이트2

  • Ubuntu
    • 전체 시스템 업데이트 (OpenSSL을 포함한 시스탬 내의 소프트웨어 전부 업데이트)

업데이트3

  • OpenSSL 업데이트 

업데이트4

  • 운영환경의 특수성 때문에 패키지 형태의 업데이트가 어려운 경우, Heartbeat를 사용하지 않도록 컴파일 옵션을 설정하여 재컴파일 가능
    • OpenSSL 소스코드를 처음 다운받아 컴파일하는 경우 라이브러리   의존성 문제가 발생하여 추가적인 작업이 필요한 경우도 존재

업데이트5

 

 
 <네트워크 보안 장비 측면 대응 방안>

 

  • 취약점 공격 탐지 및 차단 패턴 적용
    • 아래의 Snort 탐지 룰(rule)을  참고하여 침입탐지시스템 및 침입차단 시스템에 패턴 업데이트 적용 권고
      • 차단 패턴 적용은 서비스 및 네트워크 영향도를 고려하여 적용

룰

                       ※ 출처 : FBI


  <서비스 관리 측면 대응 방안>

 

  • 서버 측 SSL 비밀키(Secret Key)가 유출되었을 가능성을 배제할 수 없기 때문에 인증서를 재발급 받는 것을 운영자가 검토
  • 취약점에 대한 조치가 완료된 후 사용자들의 비밀번호 재설정을 유도하여 탈취된 계정을 악용한 추가 피해를 방지하는 방안도 고려
    • 야후 메일의 경우 접속한 사용자의 계정정보가 유출되는 것이 확인되어 현재 비밀번호 변경을 안내 중

헥스값


 

 


블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

티스토리 툴바