그 이후의 세계에 오신 것을 환영합니다심장 출혈. 우리는 서버를 패치했고 SSL 인증서를 교체하고 있습니다. 하지만 서버가 고정되어 있다고 해서 나머지 인터넷도 고정되어 있다는 의미는 아닙니다. 직원이 있고 그들은 인터넷을 사용하여 신용 카드 번호 및 로그온 자격 증명과 같은 비밀을 교환합니다. 그들은 우리에게 조언을 구하고 있습니다.
우리는 고객에게 다음을 사용하도록 조언할 수 있습니다.Heartbleed 테스트 페이지이동하려는 사이트에 취약점이 있는지 확인합니다. 사이트가 긍정적인 결과를 반환하는 경우 해당 사이트와 비밀을 교환하지 마세요. 하지만 사이트가 그렇다면~ 아니다Heartnet에 대해 긍정적인 결과가 나오면 상황은 다음 중 하나일 수 있습니다.
- 해당 사이트에는 취약점이 전혀 없습니다(양호).
- 사이트에 취약점이 있어 이를 수정했지만 여전히 손상되었을 수 있는 SSL 인증서를 사용하고 있습니다(불량).
- 사이트에 취약점이 있었고 이를 수정했으며 SSL 인증서를 재생성했지만 키를 재생성하지 않았습니다(불량).
- 사이트에 취약점이 있어 이를 수정하고 키를 다시 생성하고 SSL 인증서를 교체했습니다. (좋은)
직원들이 양식에 신용 카드 번호를 입력하기 전에 직원들에게 이를 알릴 수 있는 방법이 있습니까?좋은시나리오나쁜것들?
Heartbleed로 인해 손상된 서버에 대한 노출을 최소화하도록 직원에게 어떻게 지시합니까?
답변1
본질적으로 아니요. 사용자가 사용 중인 시스템을 완전히 볼 수 없기 때문에 좋은 시나리오와 나쁜 시나리오를 구분할 수 있는 한 가지 방법은 없습니다.
버그로 인한 피해 규모는 아직 거의 알려지지 않았으며, 대부분의 피해는 잠재적으로 과거에 발생했으며 오랫동안 인터넷에 계속 영향을 미칠 것입니다. 우리는 어떤 비밀이 언제, 누구에 의해 도난당했는지 알 수 없습니다.
예를 들어 Google의 OpenSSL 심장은 약 1년 동안 지속됩니다. 알려지지 않은 공격자는 서버를 수집하고 흥미로운 비밀을 찾습니다. 다시 말하지만, 그들이 Twitter.com 또는 AnyBank와 같은 다른 시스템에 대한 승인된 액세스 권한을 가진 사람의 계정을 찾을 때까지는 그들이 이 작업을 수행했는지 여부를 알 수 있는 방법이 없습니다. co.uk 또는 dev.redhat.com. 이러한 계정에 액세스하면 침해의 원인을 아무도 의심하지 않고 잠재적으로 계속해서 발굴하고, 다른 시스템에 액세스하고, 다른 손상(가시적이든 아니든)을 가하고 다른 계정을 추가로 손상시킬 수 있습니다. 이 단계에서는 이미 출혈이 심한 OpenSSL 서버에서 멀리 떨어져 있으며 이는 Heartbleed의 더 끔찍한 결과 중 하나입니다. 게다가 서버의 개인 키가 손상될 위험도 있습니다.
신뢰는 쌓이는 데 오랜 시간이 걸리며 금방 사라질 수 있습니다. 이전에 인터넷에서 신뢰 문제가 없었다고 말하는 것은 아니지만 Heartbleed는 확실히 도움이 되지 않았습니다. 피해를 복구하는 데는 오랜 시간이 걸리며 이를 이해하는 것은 자신과 직원/고객/상사 등을 보호할 수 있는 방법과 보호할 수 없는 방법을 이해하는 것의 일부입니다. 취약성에 대한 노출을 제한하기 위해 통제할 수 있는 것들이 있고, 통제할 수 없는 것들이 있지만 여전히 영향을 미칠 것입니다. 예를 들어, 다른 사람들이 이 취약점에 어떻게 대응할지 결정하는 방법을 통제할 수 없습니다. NSA는 버그를 발견했지만 침묵을 지켰다고 합니다. 그것은 우리 모두에게 꽤 나쁜 일이었지만, 우리는 그것으로부터 우리를 보호할 방법이 없었습니다.
인터넷 사용자로서 귀하는 다음을 수행할 수 있고 해야 합니다.
- 이해하다얼마나 나쁜지버그는
- 비밀번호 재설정을 요청하는 이메일에 회신하거나 링크를 따르지 말고 회사/기관의 웹사이트를 직접 방문하여 적극적으로 비밀번호를 재설정하세요. 이런 사기꾼들은 피싱을 좋아할 때가 있습니다.
- Android 휴대폰에서 Heartbleed를 확인하세요. 거기에앱OpenSSL 버전을 확인하는 Lookout Mobile Security에서 제공됩니다.
Heartbleed에 대해 방문하는 웹사이트를 확인하세요(불완전한 체크리스트):
서버가 OpenSSL을 사용하고 있나요?
- 아니요: 이 버그로 인해 직접적인 영향을 받지는 않습니다. 사이트를 계속 이용하되, 버그로 인해 직간접적으로 영향을 받은 다른 서버가 귀하의 비밀번호에 접근한 경우를 대비해 비밀번호를 변경하세요. 물론 이는 해당 네트워크의 모든 서버가 패치되고 새 인증서가 발급되었다고 가정합니다.
- 예: 2로 이동합니다.
서버가 Heartbleed가 없는 OpenSSL 버전에 있습니까? check-for-heartbleed-tool이 실제로 HTTP 헤더나 다른 "표시기"가 아닌 취약점을 확인하는지 확인하세요.
- 아니요: 사이트에 어떤 비밀도 제출하지 마세요. 가능하다면 웹마스터에게 메모를 제출하세요.
- 예: 3으로 이동합니다.
이전 버전의 OpenSSL에 Heartbleed가 있었나요?
- 아니요: 일부 관리자는 최신 OpenSSL 버전이 오랫동안 현장 테스트를 거치지 않았기 때문에 최신 OpenSSL 버전으로 업그레이드하지 않았습니다. 해당 서버는 이 버그에 취약한 적이 없지만 위에 제시된 이유로 인해 여전히 비밀번호를 변경하는 것이 더 나을 수 있습니다.
- 예: 서버가 취약했으며, 취약한 버전으로 업그레이드한 시점과 공개 시점(최대 2년 또는 심지어 3년) 사이에 메모리 내 데이터가 손상되었을 가능성이 있습니다.
여기서 우리는 신뢰로 돌아갑니다. 누군가의 신뢰를 잃으면 그것은 나쁜 일입니다. 특히 그 누군가가 귀하의 사용자/고객/상사라면 더욱 그렇습니다. 그들의 신뢰를 다시 얻으려면 구축을 다시 시작하고 대화를 시작해야 합니다.
웹 관리자가 이를 시작하기 위해 게시할 수 있는 내용은 다음과 같습니다.
- 이전 OpenSSL 버전(취약함/취약하지 않음)
- 현재 버전 및 업데이트 시기
이전 버전의 OpenSSL이 취약한 경우:
- 현재 SSL 인증서가 생성된 시기
- 기존 인증서가 해지된 방법에 대한 자세한 설명
- 새 인증서에 새 비밀이 사용되었다는 보장
- 위 정보를 바탕으로 사용자를 위한 제안
귀하가 사용자라면 이러한 종류의 정보를 요청할 모든 권리가 있으며, 서비스의 모든 사용자를 위해 그렇게 해야 합니다. 이렇게 하면 보안 커뮤니티의 가시성이 향상되고 사용자가 손상된 서버에 대한 노출을 더 쉽게 최소화할 수 있습니다.