Earlier today, Motherboard reported on what had been rumoured for some time, namely that Dropbox had been hacked. Not just a little bit hacked and not in that "someone has cobbled together a list of credentials that work on Dropbox" hacked either, but proper hacked to the tune of 68 million records.
Very shortly after, a spporter of Have I been pwned (HIBP) sent over the data which once unzipped, looked like this:
HIBP의 도우미가 트로이헌트에게 데이터 몇개를 보내줬는데, 두개는 이메일하고 bcrypt로 암호화한 해시파일, 두개는 이메일과 SHA-1으로 암호화한 해시파일이었다. 드롭박스 유출본이다.
What we've got here is two files with email address and bcrypt hashes then another two with email addresses and SHA1 hashes. It's a relatively even distribution of the two which appears to represent a transition from the weaker SHA variant to bcrypt's adaptive workload approach at some point in time.
Only half the accounts get the "good" algorithm but here's the rub: the bcrypt accounts include the salt whilst the SHA1 accounts don't. It's just as well because it would be a far more trivial exercise to crack the older algorithm but without the salts, it's near impossible.
At first glance the data looks legit and indeed the Motherboard article above quotes a Dropbox employee as confirming it.
개발자관점에서 잠깐 살펴보고 넘어가자.
먼저 MySQL과 php로 구축하는 사이트는 개발자가 php 스크립트 언어나 MySQL에 내장된 암호화 함수를 써서 개발하게 마련이다. php버전에 따라 적용되는 암호화 방식이 조금씩 다르다.
MySQL의 password() 함수는 입력하는 아이디의 암호값을 MySQL DB내부에 고유 알고리즘으로 암호화시켜 저장하는 건데, 중요한 점은 MySQL 4.x버전과 MySQL 5.x 버전은 저장하는 알고리즘이 서로 완전히 다르다는것이다. 2012년 옛날에 가입한 사람의 암호 저장방식이랑 2016년 최근 사이트 개편후 가입자랑 틀려서 같은 방식으론 암호 체크가 안된다. 근데 넣어두는 암호 필드는 같은데가 많다.
보통 암호화를 하면 "9!ewBm4@dg=qsdT" 이런 해시값만 저장되고 암호의 원래값으로는 원상복구 자체가 안된다. 그래서 개발자가 사용하는 프로그래밍 방법은 사용자의 입력값을 해시함수로 먼저 해시를 한 다음 DB에 저장된 값과 몇가지 비교하는 거다.
PHP 5.5 이상에서는 강력한 bcrypt 암호화 함수를 아예 내장하고 있으므로 깃허브를 뒤지거나 하지않고 암호화 처리가 필요하면 바로 갖다쓰게되어있다.
암호화: $hash = password_hash($password, PASSWORD_DEFAULT);
여기서 반환하는 $hash 값을 DB에 저장해 두었다가 아래에서 확인하는 데 쓴다.
확인: if (password_verify($password, $hash)) {
// 입력한 값의 해시랑 비밀번호가 맞음
} else {
// 비밀번호가 틀림
}
*php스쿨 게시판 php 암호화에 대한 열띤 토론
http://www.phpschool.com/gnuboard4/bbs/board.php?bo_table=tipntech&wr_id=78316
php 특정 버전에서는 안되서 bcrypt 알고리즘을 직접 코딩으로 구현했다는 이야기가 오간다. 깃허브에서 bcrypt 소스코드를 가져다쓸수도 있고, 소스를 어떻게 구현했는지도 궁금하면 엿볼수 있다. 예전에 버블소트나 B+트리 알고리즘같은거는 다 일일이 C 코드로 구현해야했지만, 요즘 닷넷 비주얼스튜디오 설치하면 안에 함수로 다 제공된다. 마이크로소프트 머리좋은 직원들이 다 만들어서 넣어주고 개발자는 갖다쓰기만 한다. 기초과학과 응용과학의 차이같은거다.
네이버 개발자사이트 D2에서
http://d2.naver.com/helloworld/318732
에서 단방향 해시를 보완하는 "솔트"라는 용어부터 먼저 읽고 넘어가겠다. 원문에 구글 번역기 돌리면 소금을 뿌리고 어쩌고저쩌고 엉뚱한 번역을 하니 주의바란다.
솔팅(salting)
솔트(salt)는 단방향 해시 함수에서 다이제스트를 생성할 때 추가되는 바이트 단위의 임의의 문자열이다. 그리고 이 원본 패스워드에 솔트 문자열을 더 추가하여 다이제스트를 생성하는 것을 솔팅(salting)이라 한다.
예를 들어 다음과 같이 "redfl0wer"에 솔트인 "8zff4fgflgfd93fgdl4fgdgf4mlf45p1"를 더 추가해 다이제스트를 생성할 수 있다.
8zff4fgflgfd93fgdl4fgdgf4mlf45p1 + redfl0wer -> 해시 펑션 ( ) -> 다이제스트 생성
(솔트) (원본패스워드)
그러면 2012년 가입자의 암호랑 2016년가입자랑 암호가 포맷이 다르면 어떻게 이걸 체크하지?
로그인할때 입력받은 사용자암호를 체크한 다음 옛날 저장방식인지 확인하고, 옛날방식으로 해시해서 DB에 저장된 해시값과 서로 맞으면 일단 통과한다. 사용자 입력값을 새로운 SHA-256로 해시를 다시해서 DB에 새롭게 업데이트를 쳐주면 만사오케이겠네? 하는 개발자분들이 대부분일거다.
"sha256:12000:GTRTKjbjoDouabZutUMaHzg8hoACBJX1:Qe3WdSL53WQ1l5om/YFKD9TWIkTUAQL7";
SHA-256 알고리즘을 12000번 사용해서 해시를 만들었다는 뜻으로 숫자가 높을수록 깨기 힘들어지지만, 너무 높으면 해시 생성과 비교할때 서버에 많은 부하가 많이 걸리니 10000~20000 정도를 사용해서 구축하는게 좋다고 이야기한다.
$DB_PW = "*4632AE020DAD3F4D64567F9815DDF9D7470F10CF";
// 예전암호는 *로 시작하며 길이가 40자, 현재 DB에 이런식으로 저장되어있다.
$NEW_DB_PW = "sha256:12000:GTRTKjbjoDouabZutUMaHzg8hoACBJX1:Qe3WdSL53WQ1l5om/YFKD9TWIkTUAQL7";
// SHA-256 알고리즘을 12000번 사용해서 해시를 만듬.
이 숫자가 높을수록 깨기 힘들어지지만, 너무 높으면 해시 생성과 비교시 서버에 부하가 많이 걸린다. 지난 몇 년 사이 생산된 서버라면 10000~20000 정도가 적당하다.
*/
if( strlen($DB_PW) == 41 && substr($DB_PW, 0, 1) == '*' ){
// 현재 DB에 비밀번호가 길이 재보니 앗! 40자네. 맨앞은 *로 시작하는거보니 옛날방식 SHA-1 을 쓰는 걸로 저장되어 있는건데?
if($login_pw == $DB_PW) { // 입력된 패스워드 해시값과 옛날암호 해시값을 비교해서 동일하면 일단 통과, 사용자 입력값을 SHA-256으로 새로 해시한 암호를 DB에 새롭게 업데이트
$NEW_DB_PW = create_hash($login_pw);
mysql_query("update $member_table' set password = '$NEW_DB_PW' where id ='$login_id'");
}
else{ error("PW 불일치"); }
}
else if ( !validate_password($login_pw, $DB_PW) ) { // 이미 패스워드가 변경된 회원의 경우, 비밀번호 체크
error("PW 불일치");
}
strlen(create_hash($password))의 길이로 암호화방식의 유추도 가능한데 60자면 bcrypt를 썼구나 바로 알수있다. 결과가 70-80자 사이로 나오는 알고리듬은 거의 PBKDF2 이다.
알고리즘 비교에서 passwd()로 암호화를 했으니 맨앞에 *로 나오는거고 crypt 로 암호화를 했다면 앞은 $1$ 로 시작된다. SHA-256은 앞글자 "sha256:" 으로 시작하는거 보고 바로 알수있다.
SHA-1은 40자, bcrypt는 60자, SHA-256은 64자, SHA-384는 96자, SHA-512는 128자 등등이라고 php스쿨 게시판의 열띤토론장에서 친절하게 적어주셨다.
* php스쿨 게시판 열띤토론장
http://www.phpschool.com/gnuboard4/bbs/board.php?bo_table=tipntech&wr_id=78825
It's not clear whether they provided the data they obtained from Leakbase to Dropbox directly or not, although it would be reasonable to assume that Dropbox has a copy in their hands from somewhere. But I like to be sure about these things and as I've written before, independent verification of a breach is essential. Fortunately because it's Dropbox, there's no shortage of people with accounts who can help verify if the data is correct. People like me.
So I trawled through the data and sure enough, there was my record:
troyhunt@hotmail.com:$2a$08$W4rolc3DILtqUP4E7d8k/eNIjyZqm0RlhhiWOuWs/sB/gVASl46M2
머더보드가 데이터를 제공받은곳이 Leakbase라는 유출 알림사이트로부터 제공받았다는데, 익명의 드롭박스직원이 이 데이터가 자가네 데이터가 맞다고 인정을 해줬다는것이죠.
*Leakbase 사이트
* 유출확인사이트
https://haveibeenpwned.com/ (HIBP)
유출사이트에 troyhunt@hotmail.com 이메일을 넣어보니깐 7군데나 유출되었다고 나오네요.
그중 드롭박스에 대한 부분을 자세히보면
Dropbox suffered a data breach which exposed the stored credentials of tens of millions of their customers. In August 2016, they forced password resets for customers they believed may be at risk. A large volume of data totalling over 68 million records was subsequently traded online and included email addresses and salted hashes of passwords (half of them SHA1, half of them bcrypt).
2012년 중반 드롭박스가 한번 고객데이터 유출을 당했고, 이때 유출된 6천8백만개 계정은 기본적으로 솔트가 더 추가되어있으면서 SHA-1으로 해시된 암호랑 나머지 3200만개정도의 강력한 bcrypt 암호 두가지방식으로 저장이 되었다는게 유출데이터에서 밝혀졌다.
2016년 8월에는 드롭박스측이 옛날에 SHA-1에서 암호화 방식을 전혀 안바꾼 구형 암호들이 혹시라도 재사용이 될까봐 차단하기위해 강제로 패스워드 리셋 공지를 한걸 트로이헌트가 파고든겁니다.
트로이와 트로이의 아내는 1Password라는 사이트에 돈을 내고 생성되는 암호를 받아서 쓰는데 2012년 4월 2일에 드롭박스 암호를 마지막으로 바꾼적이 있다고 하네요.
I head off to my 1Password and check my Dropbox entry only to find that I last changed the password in 2014, so well after the breach took place. My wife, however, was a different story. Well it was partly the same, she too had an entry in the breach:
[redacted]@[redacted]$2a$08$CqSazJgRD/KQEyRMvgZCcegQjIZd2EjteByJgX4KwE3hV2LZj1ls2
But here's where things differed:
중간 u;bDu2=8 로 시작하는 패스워드부분을 기억해둡니다.
Now there's three things I'd like to point out here:
- My wife uses a password manager. If your significant other doesn't (and I'm assuming you do by virtue of being here and being interested in security), go and get them one now! 1Password now has a subscription service for $3 a month and you get the first 6 months for free.
- Because she uses a password manager, she had a good password. I've obfuscated part of it just in case there's any remaining workable vector for it in Dropbox but you can clearly see it's a genuinely random, strong password.
- She hadn't changed the password since April 2012 which means that assuming Dropbox is right about the mid-2012 time frame, this was the password in the breach.
Knowing what her original password was and having what as this stage was an alleged hash of it, if I could hash her strong password using the same approach and it matched then I could be confident the breach was legit. With that, it was off to hashcat armed with a single bcrypt hash and the world's smallest password dictionary containing just the one, strong password. Even with a slow hashing algorithm like bcrypt, the result came back almost immediately:
유출본 자료에다 해시캣이란 소프트웨어를 가지고 자기 아내 계정의 암호를 풀어보니깐 해시방식이 일부는 bcrypt인걸 알게되었네요. 아래 캡처그림의 Hash Type에 보면 bcrypt, blowfish (openBSD) 으로 표시되는데, blowfish는 컴퓨팅파워가 증가한 지금은 아주 취약한 방법으로 알려지고 있습니다. openBSD는 지금까지 절대 뚫리지않는 보안이 강력한 운영체제로 정평이 나 있습니다. 그래도 SQL인젝션 방식으로 DB가 왕창 유출되었으니 이 사단이 난거겠죠?
해시캣에서는 솔트를 더한것 까지도 풀어내는 프로세싱을 할수 있다고 나와있긴해요. 솔트는 SHA-1으로, 패스워드는 bcrypt로 각각 암호화해서 두개를 섞어놨는데, 트로이헌트한테 이게 보인거죠. 아마 머더보드가 리포트한 루머라는건 벌써 이런 방식으로 만지작거려본 다크웹의 해커가 있단 뜻입니다.
앞부분 솔트만 취약한 blowfish 방식. 즉 SHA-1방식으로 40자까지 적용해서 풀어내서 솔트 필드에 따로 저장하고, 뒷부분은 60자까지 bcrypt로 풀어서 나온 패스워드 필드에 따로 저장하고, 합친다면 리버스로 원래 값을 유추할수 있게된겁니다.
* hashcat
And there you have it - the highlighted text is the password used to create the bcrypt hash to the left of it. Now this isn't "cracking" in the traditional sense because I'm not trying to guess what her password was, rather it's a confirmation that her record in Dropbox is the hash of her very strong, very unique never-used-anywhere-else password. There is no doubt whatsoever that the data breach contains legitimate Dropbox passwords, you simply can't fabricate this sort of thing. It confirms the statement from Dropbox themselves, but this is the kind of thing I always like to be sure of.
드롭박스에 따르면 그동안 암호를 전혀 안바꾼 사람들 - 영향을 받는 사람들에게 이메일로 공지를 했는데, 그래도 유출된 패스워드는 솔트를 추가하는등 여러가지 처리를 해놔서 그동안은 견고했었고, 암호화방식도 강력한 bcrypt라서 다행이었다는 내용이죠.
지금도 6천8백만개 계정이 HIBP사이트에서 검색이 됩니다. 2012년 드롭박스 데이터 유출이 크긴 컸네요. 드롭박스에서는 그래도 2단계 확인 절차로 바꿔달라는 내용입니다.
As for Dropbox, they seem to have handled this really well. They communicated to all impacted parties via email, my wife did indeed get forced to set a new password on logon and frankly even if she hadn't, that password was never going to be cracked. Not only was the password itself solid, but the bcrypt hashing algorithm protecting it is very resilient to cracking and frankly, all but the worst possible password choices are going to remain secure even with the breach now out in the public. Definitely still change your password if you're in any doubt whatsoever and make sure you enable Dropbox's two-step verification while you're there if it's not on already.
There are now 68,648,009 Dropbox accounts searchable in HIBP. I've also just sent 144,136 emails to subscribers of the free notification service and a further 8,476 emails to those using the free domain monitoring service.
Update (the following day): I went back into my 1Password today and whilst my current password was created in 2014, it had kindly stored a previous one I'd overlooked when originally verifying the Dropbox data:
This password was replaced on the 22nd of September in 2012 so that gives you a sense of time frame that reconciles with what Dropbox has said in that the breach would have happened before this time.
So with this password I then repeated the same process as I had with my wife's and sure enough, my hash in the data set checked out - the password is correct:
Both my wife's and my strong, unique password manager generated and stored passwords are the ones in the Dropbox data breach. Frankly, there was no ambiguity as to the legitimacy of this data after my wife's password checked out, but this is yet more certainty that they did indeed suffer a data breach.
결론은
드롭박스 뚫린것은 맞다. 그런데 2012년 얘기다.
옛날 데이터가 돌아다닌다는게 갑자기 문제가 된거지.
우리나라에도 #opnorthkorea 작전때 어나니머스가 뿌린 새누리당 당원 명부가 지금도 외국사이트에서 돌아다니고 있지? 사이트 서버가 폭파되거나 전기세를 안내서 그 사이트가 문닫기 전에는 이런거 데이터 소거가 잘 안돼.
그 당시에는 드롭박스 유출 몇건 안되는줄 알았는데 갑자기 6천8백만건으로 확 부풀려져 버린거지..... 헉!!!
그당시에도 강력한 bcrypt및 솔트가 추가된 SHA-1으로 암호화 처리는 그럭저럭 해놨는데,
게다가 드롭박스측에서 시스템 모니터링도 하고있었고, 옛날꺼로는 접근못하게 처리는 다 해놨다는거지.
하지만 몇년간 컴퓨팅파워가 너무 발달해서 해시캣 정도만 쓰면 유출데이터에 끼워맞추기를 해서 뚫릴수있으니 안심하지마라는 경고인거죠.
Leakbase에 있는 어도비나 링크드인 유출데이터등등에 이 방식을 적용하면 쓰레기더미에서 진주를 찾게될수도 있으니깐
과연 Phantom Menace 보이지않는 위협 이란 부제가 어울려.
난 드롭박스를 2016년 올해 가입했으니 내 드롭더비트에서 유출된거는 없는거로
