1P by GN⁺ | ★ favorite | 댓글 1개
  • IT Brew의 Tom McKay는 2022년 Gizmodo를 떠나며 자신의 Slack 계정을 Slackbot처럼 위장해 몇 달 동안 삭제를 피함
  • Slack은 이미 쓰이는 “Slackbot” 이름을 막았지만, McKay는 비슷하게 보이는 Unicode 문자로 표시 이름 제한을 우회함
  • 프로필 사진도 실제 Slackbot 아이콘과 닮은 화난 버전으로 바꿔, 관리자가 중복된 Slackbot과 눈썹 차이를 알아차리지 못함
  • 계정이 남아 있는 동안 McKay는 동료들에게 “Slackbot fact of the day” 같은 봇처럼 보이는 메시지를 보낼 수 있었음
  • 회사에 따라 이런 장난을 막는 보안 조치가 있을 수 있어, 퇴사자 계정 정리와 표시 이름 검증이 중요함

퇴사 후 남아 있던 Slack 계정

  • IT Brew의 Tom McKay는 Gizmodo를 떠난 뒤 자신의 Slack 계정을 Slackbot처럼 위장
  • McKay는 X에 당시 스크린샷을 공유했고, The Verge에도 이 장난이 실제였다고 확인함
  • 위장된 계정은 몇 달 동안 Gizmodo 관리진에게 탐지되거나 삭제되지 않음

Slackbot처럼 보이게 만든 방법

  • Slackbot은 Slack 안에서 알림, 사무실 Wi-Fi 비밀번호 확인, 참여하지 않은 채널에서의 멘션 알림 등을 돕는 친숙한 봇임
  • McKay는 퇴사 시점에 기존 프로필 사진을 실제 Slackbot 아이콘과 닮은 화난 버전 이미지로 바꿈
  • 표시 이름도 “Slackbot”으로 바꾸려 했지만, Slack은 이미 사용 중인 이름이라는 이유로 일반적인 변경을 허용하지 않음
  • 대신 글자와 비슷한 Unicode 문자를 써서 이름 제한을 우회함
    • 예: “o”를 비슷하게 보이는 Unicode 문자 “о”로 바꾸는 방식

몇 달 동안 가능했던 행동

  • 이 변경 덕분에 McKay의 활성 Slack 계정은 몇 달 동안 삭제를 피함
  • 계정이 남아 있는 동안 동료들에게 봇처럼 보이는 메시지를 보낼 수 있었음
    • 예: “Slackbot fact of the day: Hi, I’m Slackbot! That’s a fact. Have a Slack-ly day!”
  • 과거 Gizmodo에서 일했던 Victoria Song은 이 상황이 놀랍지 않다는 반응을 보임

회사별 방어 가능성

  • 모든 회사가 같은 방식에 속는 것은 아니며, 일부 회사는 이런 유형의 상황을 막는 보안 조치를 갖추고 있음
  • Gizmodo 관리진은 McKay의 계정이 이미 삭제됐다고 생각했을 수 있음
  • 또는 수상한 눈썹이 있는 중복 Slackbot을 발견할 만큼 세밀하게 보지 못했을 수 있음

댓글과 토론

Hacker News 의견들
  • 예전에 알던 전 직원이 모뎀 랙 컨트롤러 모듈에 Ringing이라는 다이얼업/ISDN 프로비저닝 프로필을 만들어 둔 적이 있음. Radius 서버에 만들면 너무 뻔하니까 피한 것임
    모뎀 랙 상태 페이지를 보면 접속 중인 사용자들과 아직 받지 않은 전화처럼 Ringing 상태 하나가 보였고, 완전히 들키지 않은 채 1년 넘게 128Kbit ISDN 서비스를 썼음
    물론 이런 짓은 권하지 않음. 특히 지금은 CFAA가 URL 매개변수 바꾸기나 카펫에 코딱지를 튕기는 것까지 포함하는 식으로 해석되기도 하니까

    • CFAA 관련 근거가 있는지 궁금함. 오히려 URL 매개변수 변경은 문제가 아닐 가능성이 높아 보였음
      뉴저지 법상 “무단 접근 또는 권한 초과 접근”으로 유죄가 되려면 코드나 비밀번호 기반 장벽을 우회했다는 점을 정부가 입증해야 했고, 해당 사건에서는 공개된 로그인 화면 일부에 접근해 AT&T가 의도치 않게 공개한 정보를 긁었을 뿐이라는 취지였음
      https://law.justia.com/cases/federal/appellate-courts/ca3/13...
    • Warcraft II 랜 게임에서 형제 둘이 컴퓨터 상대로 협동전을 할 때, 내 이름을 Computer로 바꾸고 몰래 들어갔던 일이 조금 생각남
    • 전 직장에서 Slack에서 내 계정을 제거해 주길 몇 달 동안 조용히 기다린 적이 있음. 거의 1년 뒤에도 내부 채널 상당수에 전체 접근 권한이 남아 있어서 정말 이상했음
      친한 사람들은 맞았지만 호의로 남겨 둔 게 아니라, Slack 계정 관리와 Google Office 연동이 엉망이었기 때문임
    • CFAA와 코딱지 얘기는 무슨 사연인지 모르겠음. 검색해도 참고 자료를 못 찾겠음
  • 2016년쯤 컨설팅 회사에서 서로의 Slack 이름을 바꿀 수 있다는 걸 알아낸 영광스러운 하루가 떠오름. 한때 모두의 이름이 그냥 dad였음

    • 아이들이 Netflix/Disney+ 프로필 이름과 사진은 누구나 바꿀 수 있다는 걸 깨달았을 때와 아주 비슷하게 들림
    • 좋긴 한데 나는 grandad를 고집하겠음. 아니면 손녀들을 풀어놓을 텐데, 걔들은 무자비함
    • 아직도 이게 가능한가?
      대학 프리스비 팀이 Slack을 쓰고 있음
  • 이름 변경을 막는 방법을 많이들 권하지만, 그걸로 문제가 완전히 풀리지는 않음. 실제 이름이 Jira인 사람도 어딘가에는 있을 수 있음
    예전에 일하던 $company에서는 고객 대시보드를 와일드카드 기반 https://*.$company.com에 두었음. 예를 들어 https://foo.$company.com 같은 식임
    그런데 누군가 wwwblog처럼 실제 레코드와 충돌하는 대시보드 슬러그를 고르면 그 대시보드는 완전히 접근 불가능해짐. 접두사를 바꾸는 설정도 https://$dashboard.$company.com에 있으니 고객이 직접 고칠 수 없고 지원팀이 필요해짐. 당연히 지원 도구도 $dashboard 접두사를 직접 바꾸는 기능을 노출하지 않았음
    차단 목록을 어떻게 만들지도 사소하지 않음. 기존 DNS 항목, 이미 존재하는 $dashboard 접두사, 욕설, 유니코드 기호, Punycode의 xn-- 접두사, 이전 접두사 리다이렉트와 향후 선점 방지 예약까지 필요함
    Slack에 이런 구멍이 있는 게 놀랍지는 않음. 본질적으로 어려운 문제임

    • Zendesk는 고객 대시보드를 자기 메인 도메인의 직접 하위 도메인에 둠. 자체 도메인도 허용하고, 쓰려면 Zendesk가 준 하위 도메인을 가리키는 CNAME으로 만들어야 함
      https://support.zendesk.com/hc/en-us/articles/4408838571930-...
      GitHub나 Shopify처럼 고객 페이지용 하위 도메인은 최소한 별도 도메인에 두는 편이 더 낫다고 봄. GitHub는 GitHub.com을 자기 도메인으로 쓰고 GitHub.io를 사용자 페이지 도메인으로 쓰며, Shopify도 Shopify.com과 myshopify.com을 나눠 씀
      고객용 별도 도메인의 장점은 회사가 직접 쓰고 싶은 기존·미래 하위 도메인과 덜 충돌하고, 그 도메인을 Public Suffix List에 넣어 잠재 문제를 피할 수 있다는 것임. 그래도 모욕적이거나 오해를 부르는 단어는 필터링해야 함
      https://publicsuffix.org/
    • 배우자 직장에는 실제로 Admin이라는 이름의 직원이 있음. IT가 그걸 어떻게 처리해야 할지 애먹고 있음
    • 여기서 정말 Slack을 변호하려는 건가? oо는 가능한 동형이의 문자 공격 중 거의 가장 쉬운 축에 속함
      https://en.wikipedia.org/wiki/IDN_homograph_attack
      퇴사할 때 McKay가 프로필 사진을 더 화난 Slackbot 아이콘처럼 바꾸고 이름을 Slackbot으로 바꿨다는 내용인데, Slack은 Slackbot이라는 이름이 이미 쓰인다고 막지만 o를 유니코드 문자 о로 바꾸면 동작했음
      이 영어/키릴 문자 쌍은 2001년에 공개된 초기 동형 글리프 공격 중 하나에서도 이미 쓰였음
      https://web.archive.org/web/20200102175251/http://www.cs.tec...
      2022년 Slack의 가치는 대략 200억 달러였고 거의 10년째 운영 중이었음. 게다가 보안이 필요한 조직·기업을 대상으로 하는 사용자 이름 기반 소프트웨어임
    • 사용 가능한 문자를 제한하고, 변경을 허용하기 전에 해당 페이지가 이미 해석되는지 그대로 확인하면 됨. 그러면 고객이 잠기지 않고 문자로 다른 대상을 사칭하기도 어려움
      일부 기호를 허용하고 싶다면 허용 목록을 쓰거나, 사용자 이름이 slackbot 같은 핵심 이름과 충분한 레벤슈타인 거리를 갖는지 검사해서 금지하거나 사람이 확인하게 표시하면 됨
      모든 걸 막기는 본질적으로 어렵지만, 가장 큰 문제들을 막는 건 어렵지 않음
    • 이 경우에는 “근본적으로 다른 이름공간이 충돌하지 않게 하라”가 그렇게 어려운 문제는 아님
  • 숨기 가장 좋은 곳은 비활성화하면 뭐가 망가질지 몰라 모두가 건드리기 두려워하는 서비스 계정처럼 보이는 것임. 잘했음

    • 반대로 우리 직장의 지나치게 열성적인 IT 담당자가 Jira 자동화 계정을 지워 버린 적이 있음. 그 계정이 왜 있는지 몰랐고 $CompanySecretary라는 이름이 수상해 보였기 때문임
      며칠 뒤, 정말 중요한 게 깨지기 전에 그 사용자를 참조하던 모든 워크플로와 티켓을 찾아 고치느라 큰 고생을 했음
    • 유명한 악성코드와 그 프로세스 이름들이 떠오름
  • “물론 모든 회사가 이 장난에 넘어가지는 않는다”지만, 회사가 마지막에 웃을 수도 있음: https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act

    • 그래서 그가 2년을 기다렸다가 말했다는 게 포인트임. 마침 CFAA 공소시효와 맞아떨어짐
    • “가벼운 장난”이라는 문구를 보고 처음 든 생각이 이거였음
    • 마지막에 웃는 건 Slack일 수도 있음. 결국 “민감한 비즈니스 데이터”를 많이 손에 넣으니까
  • ASCII 문자를 비슷하게 생긴 유니코드 문자로 바꾸는 건 오래된 수법임. 이런 문자는 꽤 많고, 코드에 넣어 동료 개발자를 놀리는 데 쓸 수 있음. 4월 1일도 가까워지고 있음
    이런 “위험한” 문자를 강조 표시하는 Vim 플러그인도 만들었음: https://github.com/vim-utils/vim-troll-stopper
    유니코드 문자로 장난을 당한 적은 없지만, 일본 컨설턴트가 번역 파일에 의도치 않게 “일본식 공백” 문자를 넣어서 앱이 깨진 적은 있음. 항상 Vim 플러그인을 켜 두고 있어서 원인을 금방 알아봤음

    • 많은 앱이 친절하게도 하이픈 두 개를 더 보기 좋은 유니코드 긴 대시로 바꾸기 시작했는데, 그 덕분에 명령줄 도구가 깨짐
    • 이거 기억남: https://news.ycombinator.com/item?id=10438363
    • 우발적인 쓰레기 문자도 멀리 갈 수 있음. 의료 보고서에서 누군가 위첨자 O를 도 기호처럼 쓴 적이 떠오름
      그게 나중에 위첨자가 아닌 문자로 변환되면서 의미가 꽤 달라졌음. 더 불친절했던 건, 그 기호 시도 뒤에 degrees라는 단어도 같이 써 놨다는 점임
  • Slack이 이름 변경 잠금을 허용하지 않는다면 대기업에는 엄청난 보안 구멍일 것 같음
    이름을 CEO로 바꾸고 프로필 이미지도 맞추면, 너무 늦기 전까지 차이를 알아챌 확률이 극히 낮음. Slackbot으로 바꾸는 건 작은 일처럼 보임

    • 이름 변경은 잠글 수 있음. Enterprise Grid 조직에 있는데 표시 이름과 사용자 이름이 직원 프로필과 동기화
      데스크톱 앱을 실행할 때마다 SSO도 필수라, 퇴사하면 절대 다시 들어올 수 없음. 계정도 매우 빨리 비활성화하니 모바일도 큰 걱정은 아닐 가능성이 높음
      티켓을 넣지 않고 바꿀 수 있는 건 사실상 사진과 별로 중요하지 않은 자유 입력 필드 몇 개뿐임
    • 조직 설정에서 가능함. 아래의 SAML/SSO 얘기도 마찬가지임. 이름을 바꿀 수 있다면 IT 관리자가 없거나 게으른 것에 가까움
    • 큰 회사들은 SAML이나 다른 연합 인증을 써서 회사 인증 없이는 로그인할 수 없게 만듦
    • 동시에 이름 변경 기능은 정말 큰 축복이기도 함
      우리는 표시 이름에 바로 재실 정보를 넣는 식으로 남용 중임. 예를 들어 mike-2/12~16vac.처럼 써서 연락하는 사람이 응답 시간을 예상하거나, 예정된 휴가 며칠 전이면 업무를 맡겨도 되는지 알 수 있게 함
      실제 상태 속성은 아무도 보는 것 같지 않았고, 달력에 가서 확인하는 것보다 낫음
    • 우리 회사가 최근 화상회의 시스템에서 사람들이 이름을 바꾸는 기능을 제거한 이유 중 하나가 아마 이거라고 봄
  • 사람들이 그에게 답장하는 스크린샷을 보면, 그가 Slackbot이 아니라는 걸 분명히 알고 있고 Tom이라고 부르기도 함. 그래서 제목과는 좀 모순됨. 그는 명백히 “들키지 않은” 상태가 아니었음
    우리 Slack에도 전 직원들이 아직 남아 있음. 가끔 들러서 인사하는데 보기 좋음. 그중 누군가 어느 날 비꼬는 Slackbot 흉내를 내기 시작하면 우리도 웃고 넘길 것 같음

    • 여기서 뜻하는 건 “관리진에게 들키지 않았다”는 것임. 기사에도 분명히 나옴. 친구들은 그가 있는 걸 알고 같이 웃고 있었음
    • 우리도 비슷함. Slack이 주 커뮤니케이션 채널은 아니었지만 외부 컨설턴트용으로 썼고, 퇴사한 사람들이 쫓겨나지 않은 채 계속 점심 약속을 잡고 있었음
  • 예전에 일하던 곳은 Slack 계정 비활성화가 느렸음. 그래서 퇴사할 때 #daves_cave라는 비공개 채널을 만들고 친구들을 초대했음
    가끔 짧은 이야기나 재치 있는 문구를 남겼고, 관리진이 알아차려 내 계정을 비활성화하기 전까지는 재미있었음

    • 개인 유료 Slack 팀을 갖고 있는데 월 10달러 정도였던 것 같음. 다른 유료 Slack 팀 사람들을 방에 초대해 대화할 수 있음
      이 방식의 좋은 점은 “의도된 설계”라서 닫힐 가능성이 낮고, 컴퓨터 오용 관련 법에 걸릴 가능성도 낮다는 점임
  • 회사에서 이 문제의 답은 싱글 사인온이라고 생각했을 것 같음
    요즘은 IT를 운영하지 않지만, 예전에 운영할 때는 Azure Active Directory에서 퇴사자를 비활성으로 표시했음. 그러면 Office 365, Outlook, Teams 등 어떤 서비스에도 로그인할 수 없고, MS SSO를 쓰는 서드파티 서비스에도 들어갈 수 없었음. Slack도 거기에 붙이는 게 맞지 않나?

    • 유능하거나 충분한 인력이 있는 IT 부서라면 당연히 그렇게 함. 다만 다른 부서가 IT와 상의하지 않고 Slack을 설정했을 가능성도 있음