심각한 보안: 잘못된 오류가 DNS 보안을 개선하는 방법

수년에 걸쳐 우리는 쓴 및 이야기 Naked Security에서 DNS의 까다로운 문제에 대해 여러 번 납치.

아시다시피 DNS는 도메인 명 시스템, 인터넷의 "전화번호부" 또는 "gazetteer"로 묘사되는 것을 자주 듣게 될 것입니다.

단어가 낯설다면 지명사, 그것은 당신이 찾는 아틀라스의 뒷면에 있는 색인을 말합니다. 라이베리아 몬로 비아 편리한 알파벳 목록에 다음과 같이 표시됩니다. 184 - C4. 이것은 184페이지로 곧장 돌아가서 지도 상단에 있는 문자 C에서 아래로 격자선을 따라 왼쪽에 있는 숫자 4를 가로질러 건너라는 것을 알려줍니다. 선이 만나는 곳에서 Monrovia를 찾을 수 있습니다.

대부분의 사용자의 경우 대부분의 DNS 조회는 서버 이름을 포함하여 나가고 A 레코드 또는 AAAA 레코드로 알려진 것을 포함하는 응답을 요청합니다.

(A 레코드는 다음과 같은 32비트 IPv4 인터넷 번호에 사용됩니다. 203.0.113.42; AAAA 레코드는 다음과 같은 128비트 IPv6 주소에 대한 동등한 답변입니다. 2001:db8:15a:d0c::42 – 이 문서에서는 A 레코드와 IPv4 번호만 사용하지만 두 경우 모두 동일한 보안 문제가 조회 프로세스에 적용됩니다.)

다음은 가상 도메인 이름을 조회하는 예입니다. naksec.test DNS 트래픽을 추적하고 알려주기 위해 특별히 제작된 DNS 서버를 통해

우리는 구식 Linux 도구를 사용했습니다. dig, 짧은 도메인 인터넷 그로퍼, 간단한 DNS 요청(dig 기본적으로 A 레코드 조회) 원하는 서버에 대해:

$ dig +noedns @127.42.42.254 naksec.test ;; 질문 섹션: ;naksec.test. 안에 ;; 답변 섹션: NAKSEC.TEST. 5 IN A 203.0.113.42 ;; 쿼리 시간: 1msec ;; 서버: 127.42.42.254#53(127.42.42.254) (UDP) ;; 언제: 23년 14월 38일 월요일 42:2023:56 GMT ;; MSG 크기 rcvd: XNUMX

다음은 DNS 서버가 요청을 처리하여 수신 요청의 XNUMX진수 덤프와 반환된 성공적인 응답을 보여주는 방법입니다.

---> 127.0.0.1:57708에서 127.42.42.254:53으로 요청 ---> 00000000 62 4e 01 20 00 01 00 00 00 00 00 00 06 6e 61 6b |bN. .........나크| 00000010 73 65 63 04 74 65 73 74 00 00 01 00 01 |초.테스트..... | DNS 조회: naksec.test에 대한 A 레코드 ==> A=203.0.113.42 <--- 127.42.42.254:53에서 127.0.0.1:57708로 응답 <--- 00000000 62 4e 84 b0 00 01 00 01 00 00 00 00 06 6e 61 6b |bN..........nak| 00000010 73 65 63 04 74 65 73 74 00 00 01 00 01 06 4e 41 |초 테스트......NA| 00000020 4b 53 45 43 04 54 45 53 54 00 00 01 00 01 00 00 |KSEC.TEST.......| 00000030 00 05 00 04 cb 00 71 2a |......q* |

성능상의 이유로 대부분의 DNS 요청은 UDP를 사용합니다. 사용자 데이터그램 프로토콜, 전송 및 희망 기반으로 작동합니다. 대화하려는 서버에서 UDP 패킷을 시작한 다음 응답이 돌아올 때까지 기다립니다.

이로 인해 UDP는 큰 사촌인 TCP보다 훨씬 간단하고 빠릅니다. 전송 제어 프로토콜이름에서 알 수 있듯이 UDP가 처리하지 않는 많은 세부 정보를 자동으로 처리합니다.

특히 TCP는 데이터 손실을 감지하고 다시 요청하는 작업을 처리합니다. 모든 데이터 청크가 올바른 순서로 도착하는지 확인합니다. 일단 설정되면 동시에 송수신에 사용할 수 있는 단일 네트워크 연결을 제공합니다.

UDP에는 "연결" 개념이 없으므로 요청과 응답이 본질적으로 독립적으로 이동합니다.

• DNS 요청이 DNS 서버에 도착 자체 UDP 패킷에서.
• DNS 서버는 기록을 유지합니다 어떤 컴퓨터가 특정 패킷을 보냈는지.
• 서버는 회신할 답을 찾기 시작합니다. 또는 하나가 없다고 결정합니다.
• 서버가 답장을 보냅니다. 두 번째 UDP 패킷을 사용하여 원래 보낸 사람에게.

운영 체제 또는 네트워크 수준에서 위의 두 UDP 패킷은 독립적인 독립형 전송이며 동일한 디지털 연결의 일부로 함께 연결되지 않습니다.

각 응답을 보낼 클라이언트를 기억하는 것은 서버에 달려 있습니다. 어떤 응답이 원래 보낸 요청과 관련이 있는지 파악하는 것은 클라이언트의 몫입니다.

어떻게 확신할 수 있습니까?

이 시점에서 특히 위의 DNS 요청 및 응답의 작은 크기를 살펴보면 "클라이언트가 전송 중에 왜곡되거나 잘못 전달된 응답이 아닌 올바른 응답과 일치하는지 어떻게 확인할 수 있습니까? 실수로, 우연히 또는 의도적으로?”

불행하게도 대부분은 아니지만 많은 DNS 요청(특히 서버에서 서버로, 요청한 첫 번째 서버가 답을 모르고 응답을 공식화하기 위해 응답을 찾아야 하는 경우)이 암호화되지 않았거나 그렇지 않으면 모든 종류의 암호화 인증 코드로 레이블이 지정됩니다.

실제로 기본적으로 DNS 요청에는 단일 "식별 태그"가 포함되며 DNS 데이터 형식 문서에서는 간단히 ID.

놀랍게도 수년에 걸쳐 수많은 업데이트와 개선 제안을 받았음에도 불구하고 공식 인터넷 RFC(의견 요청) DNS 사양 역할을 하는 문서는 여전히 RFC 1035 (우리는 현재 9000년대 중반에 RFC에 참여하고 있습니다.) 1987년 35월로 거슬러 올라가 XNUMX년이 조금 넘었습니다!

당시에는 대역폭과 처리 능력이 모두 부족했습니다. 일반적인 CPU 속도는 약 10MHz였습니다. 데스크톱 컴퓨터에는 약 1MByte의 RAM이 있었습니다. 온라인에 접속할 수 있는 조직의 경우 인터넷 액세스 속도는 모두가 공유하는 56kbits/sec 또는 64kbits/sec였습니다. 1200bits/sec는 당시의 전화 접속 모뎀을 통한 개인 연결을 위한 저렴한 선택이었습니다.

그렇기 때문에 DNS 요청 및 응답 헤더는 RFC 12의 귀여움과 같이 ID 태그가 처음 두 개를 차지하는 1035바이트로 압축되었으며 여전히 그렇습니다. 아스키 아트 명확하게 :

 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+ --+--+--+--+--+--+--+ | 신분증 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QR| 연산 코드 |AA|TC|RD|RA| 지 | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 앙카운트 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 계정 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

위에 표시된 XNUMX진수 덤프에서 작동 중인 ID를 볼 수 있습니다. 여기서 요청 패킷과 응답 패킷은 모두 동일한 두 문자로 시작합니다. bN, 16비트 식별자에 해당 62 4e XNUMX진수로.

매우 느슨하게 말하면 이 16비트는 공식 DNS 프로토콜이 "인증" 또는 "오류 감지"를 통해 제공하는 것과 같습니다.

추측에 의한 간섭

상상할 수 있듯이 일반 DNS 트래픽의 종단 간 단순성을 고려할 때 소위 미들박스 or 스캐닝 프록시 네트워크 트래픽을 가로채고 검사하고 수정할 수 있는 사람은 DNS 트래픽에 사소한 간섭을 할 수 있습니다.

여기에는 맬웨어가 산재해 있는 것으로 알고 있는 서버에서 사용자를 리디렉션하는 IT 팀과 같이 의도적으로 부정확한 정보를 제공하는 답장을 보내는 것이 포함됩니다.

또한 ISP가 아동 학대 자료와 같은 불법 콘텐츠의 차단 목록에 있기 때문에 일부 서버가 살아 있고 제대로 실행되더라도 존재하지 않는 것으로 보고되도록 요구하는 해당 국가의 법률을 준수하는 ISP가 포함될 수 있습니다.

그러나 언뜻 보기에 이 매우 약한 종류의 DNS ID 태깅도 사소해 보입니다. 네트워크 트래픽에 대한 가시성이 전혀 없는 공격자도 마찬가지입니다. 사용자 또는 서버에서 가짜 DNS 응답을 실행하려면…

... 위험할 정도로 높은 성공 가능성을 가지고 있습니다.

결국, 공격자가 네트워크의 누군가가 정기적으로 방문하기를 좋아한다는 것을 알고 있다면 naksec.test, 해당 서버는 가짜 뉴스, 의심스러운 업데이트 또는 악성 JavaScript 코드를 삽입하기에 좋은 장소처럼 보일 수 있습니다.

공격자가 해킹할 수 없는 경우 naksec.test 서버 자체에서 "A 레코드는 무엇입니까? naksec.test"?

그렇게 하면 DNS 요청을 하이재킹하고 가짜 응답을 제공할 수 있으므로 다음 방문을 웹 사이트로 잘못 안내할 수 있습니다. naksec.test 전혀 서버.

약간의 운이 필요합니다

물론 그들은 약간의 운이 필요하지만, 한 번만 성공하면 되는 반면 매번 진실한 DNS 응답을 받아야 한다는 점을 감안할 때 전체 기회를 높이기 위해 반복해서 시도할 수 있습니다.

성공하려면 악성 DNS 회신을 보내야 합니다.

• 자신의 서버가 질문에 대한 답을 아직 알지 못하는 기간 동안. DNS 응답에는 TTL이라는 32비트 숫자가 포함됩니다. 수명, 상대방이 응답을 계속 재사용할 수 있는 기간을 나타냅니다. 귀하 또는 ytour 네트워크의 다른 사람이 요청한 경우 naksec.test 최근에 DNS 서버의 캐시에 답이 있을 수 있습니다. 더 이상의 조회가 필요하지 않으며 공격자가 하이재킹을 요청하는 발신 요청도 없습니다.
• 귀하가 요청을 보낸 시간과 외부에서 공식적인 답변이 돌아온 시간 사이에. 옛날에도 DNS 조회 시간은 거의 몇 초 이상 걸리지 않았습니다. 오늘날에는 밀리초 단위로 가장 잘 측정됩니다.
• 처음 16비트에 올바른 숫자가 있습니다. 65536(2¹⁶) 다른 값을 16비트로 나누기 때문에 공격자는 어느 정도 운이 좋아야 합니다. 그러나 오늘날의 네트워크 대역폭에서 한 번에 65536개의 서로 다른 가짜 답장을 보내 가능한 모든 ID 번호를 포함하는 데는 XNUMX초도 걸리지 않습니다.

다행스럽게도 괜찮은 DNS 서버는 기본적으로 하이재킹을 어렵게 만드는 추가 조치를 취하고 있습니다.

적어도 그들이 2008년경부터 해온 일입니다. 고 댄 카민스키 당시 많은 DNS 서버가 고정 UDP 포트(거의 항상 포트 53, DNS에 공식적으로 할당됨)에서 들어오는 요청을 수신하도록 구성되었을 뿐만 아니라…

...또한 고정 포트에서 인바운드 응답을 수신하기 위해 트래픽에서 기분 좋은 대칭을 만들기 위해서만 포트 53도 자주 사용합니다.

양방향으로 고정 포트를 사용하는 이유는 아마도 원래 프로그래밍 단순성 때문일 것입니다. 항상 동일한 UDP 포트 번호에서 응답을 수신하면 응답에 대해 어떤 포트를 열어야 하는지 추적할 필요가 없습니다. 즉, DNS 소프트웨어의 요청 처리기와 회신 생성기 구성 요소가 독립적으로 작동할 수 있습니다. 요청 수신기는 회신 발신자에게 "이 특정 회신은 일반 포트가 아닌 특수 포트로 돌아가야 합니다."라고 말할 필요가 없습니다.

포트 번호를 추가 ID로 사용

오늘날 거의 모든 UDP 기반 DNS 서버는 항상 그렇듯이 포트 53에서 수신 대기하지만 DNS 요청자가 사용하는 소위 "소스 포트"를 추적하며 이는 무작위로 선택될 것으로 예상됩니다.

구식 사무실 전화 교환기의 "내선 번호"와 비슷한 UDP 소스 포트는 귀하와 네트워크가 요청을 서로 구별하는 데 도움을 주기 위한 것입니다.

인터넷 프로토콜 포트(TCP도 이를 사용함)는 1에서 65535까지 실행할 수 있지만 대부분의 아웃바운드 연결은 소스 포트 1024-65535만 사용합니다. 포트 번호 1023 이하가 일반적으로 시스템 권한이 있는 프로세스용으로 예약되어 있기 때문입니다.

아이디어는 DNS 조회의 발신자가 각 요청의 시작 부분에 진정한 임의의 16비트 ID를 삽입할 뿐만 아니라 연결된 응답을 수신할 진정한 임의의 UDP 소스 포트 번호를 선택해야 한다는 것입니다.

이것은 사기꾼이 위의 "도용 행운" 목록에 추가해야 하는 추가 수준의 추측을 추가합니다. 즉, 다음 상자를 모두 체크하는 가짜 회신을 보내야 합니다.

• 최근에 요청한 쿼리여야 합니다. 일반적으로 지난 몇 초 이내입니다.
• 로컬 서버의 캐시에 없는 조회여야 합니다. 일반적으로 지난 몇 분 동안 아무도 그것에 대해 묻지 않았다는 것을 의미합니다.
• 올바른 16비트 ID 번호가 있어야 합니다. 데이터 패킷의 시작 부분에.
• 올바른 대상 포트로 보내야 합니다. 해당 서버의 IP 번호에서.

그리고 또 다른 것

사실 DNS 요청자가 기본 DNS 프로토콜을 변경하지 않고 따라서 (대부분) 아무 것도 손상시키지 않고 수행할 수 있는 또 다른 트릭이 있습니다.

이 트릭은 놀랍게도 처음 제안 된 2008년에 영광스러운 제목의 논문에서 0x20비트 인코딩을 통한 DNS 위조 저항성 증가: LeET 쿼리를 통한 SecURItY.

이 아이디어는 이상할 정도로 간단하며 DNS 프로토콜의 두 가지 세부 정보에 의존합니다.

• 모든 DNS 응답은 처음에 원래 쿼리 섹션을 포함해야 합니다. 쿼리에는 분명히 빈 답변 섹션이 있지만 요청과 응답이 실수로 섞이지 않도록 하는 데 도움이 되는 원래 질문을 반영하기 위해 응답이 필요합니다.
• 모든 DNS 질문은 대소문자를 구분하지 않습니다. 요청 여부 naksec.test및 NAKSEC.TEST및 nAksEc.tESt, 같은 답을 얻어야 합니다.

이제 프로토콜에는 DNS가 대소문자를 구분하지 않기 때문에 원래 쿼리를 반복하는 회신 부분에 동일한 철자를 사용해야 한다는 내용이 없습니다.

그러나 RFC 1035에서는 대소문자를 구분하지 않는 비교를 수행하도록 요구하지만 다음을 강력히 제안합니다. 실제로 케이스를 변경하지 마십시오 요청에서 수신하거나 응답에 사용하기 위해 자신의 데이터베이스에서 검색한 모든 텍스트 이름.

즉, 요청을 받으면 nAKsEC.tEST, 데이터베이스에는 다음과 같이 저장되어 있습니다. NAKSEC.TEST, 그럼에도 불구하고 이 두 이름은 동일한 것으로 간주되어 일치합니다.

그러나 답을 공식화할 때 RFC 1035는 다음을 제안합니다. 회신에 입력한 데이터의 대소문자를 변경하지 마십시오., DNS에서 요구하는 대소문자를 구분하지 않는 비교 덕분에 더 깔끔해 보일 것이라고 생각할 수도 있고 다른 쪽 끝에서 여전히 일치하더라도.

따라서 DNS 요청을 보내기 전에 문자의 대소문자를 무작위로 섞으면 여기에서 볼 수 있듯이 대부분의 DNS 서버는 자체 데이터베이스가 서버 이름을 다르게 저장하더라도 문자의 이상한 매시업을 충실하게 반영합니다. :

$ dig +noedns @127.42.42.254 nAkSEC.tEsT ;; 질문 섹션: ;nAkSEC.tEsT. 안에 ;; 답변 섹션: NAKSEC.TEST. 5 IN A 203.0.113.42 ;; 쿼리 시간: 1msec ;; 서버: 127.42.42.254#53(127.42.42.254) (UDP) ;; 언제: 23년 14월 40일 월요일 34:2023:56 GMT ;; MSG 크기 rcvd: XNUMX

우리의 DNS 서버는 이름을 저장합니다 naksec.test 모두 대문자이므로 회신의 답변 섹션에는 다음 형식의 이름이 포함됩니다. NAKSEC.TEST, IPv4 번호(A 레코드)와 함께 203.0.113.42.

그러나 DNS 서버가 다시 보내는 응답의 "여기에 교차 확인을 위해 반환된 쿼리 데이터가 있습니다" 부분에서 DNS 조회에 원래 사용된 대소문자 매시업이 보존됩니다.

---> 127.0.0.1:55772에서 127.42.42.254:53으로 요청 ---> 00000000 c0 55 01 20 00 01 00 00 00 00 00 00 06 6e 41 6b |.U. .........nAk| 00000010 53 45 63 04 74 45 73 54 00 00 01 00 01 |섹션 테스트..... | DNS 조회: nAkSEc.tEsT에 대한 A 레코드 ==> A=203.0.113.42 <--- 127.42.42.254:53에서 127.0.0.1:55772로 응답 <--- 00000000 c0 55 84 b0 00 01 00 01 00 00 00 00 06 6e 41 6b |.U..........nAk| 00000010 53 45 63 04 74 45 73 54 00 00 01 00 01 06 4e 41 |섹션테스트......NA| 00000020 4b 53 45 43 04 54 45 53 54 00 00 01 00 01 00 00 |KSEC.TEST.......| 00000030 00 05 00 04 cb 00 71 2a |......q* |

추가 보안 태깅, 무료

빙고!

DNS 조회가 추가할 수 있는 "식별 태깅"이 더 있습니다!

무작위로 선택된 15비트 정도의 소스 포트와 무작위로 선택된 16비트의 ID 번호 데이터와 함께 요청자는 도메인 이름의 각 알파벳 문자에 대해 대소문자를 선택할 수 있습니다.

Audiencegain과 naksec.test 10개의 문자를 포함하며 각 문자는 대문자 또는 소문자로 쓰여질 수 있으며 추가 10비트 가치의 무작위 "태깅"이 가능합니다.

추측할 수 있는 이 추가 세부 정보를 통해 공격자는 타이밍, UDP 포트 번호, ID 태그 값 및 도메인 이름의 대문자를 사용하여 운이 좋아야 요청 서버에 가짜 "하이재킹 회신"을 주입할 수 있습니다. 받아 들일 것입니다.

그건 그렇고, 이름 0x20 인코딩 위는 약간의 농담입니다. 0x20 머리말은 00100000 이진법으로, 해당 바이트의 단독 비트는 ASCII 인코딩 시스템에서 대문자와 소문자를 구분합니다.

편지들 A 에 I, 예를 들어 0x41 ~ 0x49로 나오는 반면 a 에 i 0x61에서 0x69로 나옵니다.

 ASCII 텍스트로 ASCII 인코딩 차트 +------+------+------+------+------+------+- -----+------+ |00 ^@ |10 ^P |20 |30 0 |40 @ |50 피 |60 ` |70 피 | |01 ^A |11 ^Q |21 ! |31 1 |41A |51Q |61A |71Q | |02 ^B |12 ^R |22" |32 2 |42 B |52 R |62 b |72 R | |03 ^C |13 ^S |23 # |33 3 |43 C |53 S |63 c |73초 | |04 ^D |14 ^T |24 $ |34 4 |44 D |54 T |64 D |74 T | |05 ^E |15 ^U |25 % |35 5 |45 E |55 U |65 e |75 u ||06 ^F |16 ^V |26 & |36 6 |46 F |56 V |66 f |76 V | |07 ^G |17 ^W |27 ' |37 7 | 47G |57W |67g |77W | |08 ^H |18 ^X |28 ( |38 8 |48 H |58 X |68 h |78 x | |09 ^I |19 ^Y |29 ) |39 9 |49 I |59 Y |69 I |79 Y | |0A ^J |1A ^Z |2A * |3A : |4A J |5A Z |6A J |7A Z | |0B ^K |1B ^ [ |2B + |3B ; |4B K |5B [ |6B k |7B { | |0C ^L |1C ^ |2C , |3C < |4C L |5C |6C l |7C | | |0D ^M | 1D ^] |2D - |3D = |4D M |5D ] |6D m |7D } | |0E ^N |1E ^^ |2E . |3E > |4E N |5E ^ |6E n |7E ~ | | 0F ^O |1F ^_ |2F / |3F ? |4F O |5F _ |6F o |7F | +------+------+------+--- ---+------+------+------+------+

즉, 0x41+0x20을 더해 0x61을 얻으면 A 으로 a; 0x69-0x20을 빼면 0x49가 됩니다. i 으로 I.

왜 지금인가?

지금쯤이면 궁금해하실 수도 있습니다. "왜 지금 아이디어가 15년 전에 나왔고 어쨌든 실제로 도움이 될 수 있다면?"

공교롭게도 우리의 갑작스러운 관심은 최근 공개 이메일 2022년에 구식 보안 트릭을 사용한 실험이 실생활에 배포되었음을 인정하는 Google 기술 전문가:

이전에 발표한 바와 같이 Google Public DNS는 권한 있는 이름 서버로 전송되는 DNS 쿼리 이름의 대소문자 무작위화를 활성화하는 과정에 있습니다. TLS를 통한 DNS가 적용되지 않는 지역에서 DNS 쿼리의 대부분(90%)을 보호하는 북미, 유럽 및 아시아의 일부 지역에 이를 성공적으로 배포했습니다.

흥미롭게도 Google은 이 간단하고 분명히 논란의 여지가 없는 조정으로 인해 발생한 주요 문제는 대부분의 DNS 서버가 일관되게 대소문자를 구분하지 않거나(그래서 이 트릭을 사용할 수 있음) 일관되게 그렇지 않음(그래서 차단 목록에 있음)이라고 제안합니다. 당신이 예상할 수 있듯이…

...몇몇 메인스트림 서버는 때때로 짧은 기간 동안 "대소문자 구분" 모드로 전환되는데, 이는 주요 서비스 공급자가 피했으면 하는 일종의 불일치처럼 들립니다.

정말 도움이 되나요?

질문에 대한 답변, "그만한 가치가 있습니까?" 아직 명확하지 않습니다.

다음과 같이 멋진 긴 서비스 이름이 있는 경우 nakedsecurity.sophos.com (알파벳 문자 22자), 추가 신호 기능이 충분합니다.²² 다른 대문자는 사기꾼이 시도할 수 있는 4만 개의 조합을 의미하며, 여기에 65536개의 서로 다른 ID 번호를 곱하고 추측할 약 32000~64000개의 서로 다른 소스 포트를 곱합니다.

...하지만 Twitter와 같은 매우 짧은 도메인 이름에 적은 돈을 지불했다면 t.co, 공격자는 이전보다 2x2x2=8배 더 어려운 작업만 수행합니다.

그럼에도 불구하고 이것을 시도한 Google에 "Chapeau"라고 말할 수 있다고 생각합니다.

사이버 보안 관찰자들이 말하는 것처럼 공격은 점점 더 빨라지기 때문에 기존 프로토콜을 사용하고 크래킹 시간을 추가할 수 있는 모든 것이 거의 "무료"로 반격하는 유용한 방법입니다.

---

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• 플라토 블록체인. Web3 메타버스 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 출처: https://nakedsecurity.sophos.com/2023/01/23/serious-security-how-deliberate-typos-might-improve-dns-security/