xp_cmdshell : 사용해야합니까?

항상 위험 입니다. 항상 검토 해야합니다. 적절하게 완화 할 수 있습니다.

적법한 용도가 있고 때로는 필수품이 있지만 입력 내용을 면밀히 살펴보십시오!

댓글

• 사용자를 사전 정의 된 작업 그룹으로 제한 할 수있는 방법이 없어서 권한 부여를 통해 사용자가 모든 명령 문자열을 실행할 수 있다는 문제는 무엇입니까? ' 권한의 세분화를 허용하지 않거나 다른 제어가 완전한 제어가된다고 명시 했습니까?
• 이제 SQL Server는 나에게 보조 서버이므로 내가 있는지 알려주십시오. ' m wrong : 사용자에게 저장 프로 시저에 대한 실행 권한을 부여하면 해당 프로 시저를 실행할 수 있습니다. 수정을 허용하지 않으며 ' 저장 프로 시저에서 사용하는 모든 항목에 대한 권한을 부여하지 않습니다. 포함 된 저장 프로 시저를 실행하기 위해 xp_cmdshell 권한을 부여 받아야한다면 ' 확실히 문제가있는 것입니다. 저는 ' 필요하지 않다고 합리적으로 확신합니다. 절차는 일반 사용자가 소유해서는 안됩니다.
• @TobyS … 그게 문제입니다. 일종의 진술. 짧은 대답 : xp_cmdshell은 사악합니다. 긴 대답 : 상황에 따라 다릅니다. 😉
• @SteveS-MSSQL의 현재 버전을 사용하면 xp_cmdshell 명령을 실행할 다른 OS 계정을 설정할 수 있습니다.
• @JeffFerland … you 작성 " I ' 필요하지 않다고 합리적으로 확신합니다. 절차는 일반 사용자가 소유해서는 안됩니다. " ' 100 % 정확합니다. ' 사용자가 테이블이 관련되어 있는지조차 알 필요가 없습니다. xp_CmdShell은 신경 쓰지 마십시오. 예, ' 설정이 매우 쉽습니다.

xp_CmdShell을 끄는 것은 썩은 고기 위에 베일을 두는 것과 비슷합니다. 그것은 테이블에 잘못된 안전감을 가져오고 파리는 여전히 고기를 잡을 수 있습니다. 설명하겠습니다.

누가 xp_CmdShell을 사용할 수 있습니까? 맞습니다. “SA”권한이있는 사람 / 앱 로그인 또는 프록시를 부여하는 끔찍한 실수를 한 사람 만 사용할 수 있습니다.

다음 질문입니다. xp_CmdShell을 끄면 누가 다시 켤 수있는 사람이 유일한 사람인가요? 다시 수정하세요. “SA”권한이있는 사람 / 앱만 다시 켤 수 있습니다.

그래서 xp_CmdShell이 보안 위험이되는 진짜 문제는 무엇입니까? ? 대답은 xp_CmdShell은 보안 위험이 아닙니다. 열악한 보안이 유일한 보안 위험입니다. 해커 또는 악의적 인 내부 사용자가 “SA”priv를 사용하여 시스템에 “들어가면 xp_CmdShell을 켤 수 있습니다. 예, 해당 작업이 기록되지만 보안이 처음부터 완전히 부족하다는 문서화 된 증언 만 제공됩니다.

xp_CmdShell을 끄는 것은 해커 코드의 해당 부분이 다시 실행되어 실행될 수있는 기회를 제공하는 것 외에는 보안을 위해 아무것도하지 않습니다.

다시 말씀 드리겠습니다. xp_CmdShell은 보안 위험이 아닙니다. 나쁜 보안 만이 보안 위험입니다. 보안을 수정 한 다음 xp_CmdShell을 켜십시오. “멋진 도구이며 잘못된 보안 관행과 신화로 인해 놓치고 있습니다.

댓글

• 전적으로 동의합니다. Jeff. syadmin 권한을 얻은 공격자는 CmdExec 작업 단계를 사용하여 sa가 소유 한 SQL 에이전트 작업을 생성하고 xp_cmdshell과 동일한 작업을 수행 할 수 있습니다. 또한 프로세스를 시작하는 CLR 저장 프로 시저를 만들 수도 있습니다. xp_cmdshell과 어떻게 다릅니 까?서버를 올바르게 보호하는 것이 보안 위험을 방지하는 유일한 방법입니다.
• 아, 내 친구 ' 친구. 의견을 보내 주셔서 감사합니다. " 다시 만나서 " 반갑습니다.
• +1 당신이 틀렸지 만 당신이 틀렸다는 것을 좋아합니다 사람들이 덜 안전하도록 장려하기 때문에 관심이 더 재미있는 곳이됩니다. 예 모든 것에 SQL Server를 설치하고 구성으로 쉽게 수정할 수있는 방법에 대한 추가 부분입니다. 좋아요 < 3. 2020 년 및 9/10 SQL Server는 올바르게 강화되지 않을 것입니다. 물론 DB 관리자 XD를 비난합니다.
• Heh … I ' 당신은 틀린 것에 대해 똑같은 플러스 원입니다. xp_CmdShell을 사용하지 않도록 설정하면 서버를 " 강화 "하는 데 전혀 영향을 미치지 않는다고 생각하는 것이 잘못되었습니다. '하지 않습니다.

내 생각에는 “사용해서는 안된다”는 것이 꽤 좋은 조언 일 것입니다. 이는 “항상 안전하지 않음 “범주 형이 아니라 xp_cmdshell이 위험하며이를 사용하는 것은 우려의 근거와 면밀한 조사의 근거가된다는 인식입니다.

그리고 보안 위험을 피하는 방법을 알고 있다고 생각하더라도 xp_cmdshell은 여전히 사용하기에 가장 좋은 도구가 아닙니다. 더 나은 해결책이 있다는 것이 의심 스럽습니다 (우연히 덜 위험 할 수있는 해결책).

” 큰 힘에는 큰 책임이 따릅니다. ” 즉, xp_cmdshell는 레드몬드에서 성공하기위한 최악의 보안 열차 중 하나라고 생각합니다.

편집 : 2020 년, 10 년 이상 침투 테스터로서-xp_cmdshell 최고의 조합을 가지고 있기 때문에 제가 직면 한 가장 무서운 보안 위험 중 하나입니다. 의; 널리 퍼져 있고 은행과 같은 중요한 비즈니스에서 사용되며 최대의 영향을 미칩니다. SQLmap은 웹앱에서 SQL Injection 만 사용하여 SA를 가져오고 xp_cmdshell …을 다시 활성화하는 데 사용할 수 있습니다.

한 엔지니어로서 다른 엔지니어로서 Microsoft에 감사드립니다. 문자 그대로 여러분 없이는 이러한 쉘을 얻을 수 없었습니다.

댓글

• 이건 ' 오래된 질문이라는 것을 알고 있지만 정말 말해야합니다. 저는 ' 3 명이 귀하의 트롤링을 진지하게 받아 들여서 놀랐습니다. 답변을 찬성하기에 충분합니다.
• @spaghettidba 펜 테스터 xp_cmdshell()는 신이 보낸 사람이기 때문에 저는 정말 진지합니다. 그토록 나쁜 것은 마이크로 소프트의 아무도이 문제를 고칠 생각조차하지 않는다는 것입니다. 저는 ' Microsoft 플랫폼에 구축 된 Microsoft 제품과 응용 프로그램이 약하기 때문에 매우 기쁩니다. 재미있는 사실은 제가 16 살 때 Microsoft 보안 제품을 사용했던 첫 0 일이 10 년 이상 전이었습니다.
• @rook-It ' 실제 PEN 테스터와 이야기를 나누는 경우가 많지 않기 때문에 '이 기회에 질문을해야합니다 (싸움을 찾고 있지 않습니다 … 저는 ' 정직하고 진심으로 귀하의 좋은 경험에 관심이 있습니다.) ' 누군가를 ' 할 수있는 경우 SysAdmin privs가있는 goodie locker입니다. xp_CmdShell이 활성화 된 경우에도 공격자로 여전히 xp_CmdShell을 사용할 수 있었습니까? ' 그렇다면이를 방지 할 수있는 방법이 있습니까?
• @Jeff Moden. 예 , 그래서 sqlmap은 이것을 아주 잘 수행합니다. SA가 아니더라도 쿼리 스택으로 인해 SQL QUERY를 사용하여 SA 계정에 로그인 할 수 있습니다. 예, 삽입 된 SQL 쿼리를 사용하여 SA를 얻은 다음 모든 명령을 다시 활성화 할 수 있습니다. 여전히 비밀번호를 알아야하지만 무차별 대입이 가능하며이 공격을 고려하지 않았다면 ' SA 계정에 취약한 비밀번호가있을 수 있습니다. 은행에서도 이런 일이 여러 번 일어났습니다. SQL-Server 전문가는 아니지만이 공격을 방지 할 수있는 강화가 있다고 생각합니다. SQLMap for the win!

SQL Server 환경에서 사용중인 보안 유형, 혼합 또는 통합 (Windows)? sysadmin SQL Server 역할에는 몇 명입니까? MS 모범 사례에서는 통합 인증 (sa 로그인 없음, SQL 로그인 없음)과 sysadmin SQL Server 역할에 두 개만 필요합니다. 이러한 모범 사례를 따르면 노출을 크게 줄일 수 있습니다. 또한 xp_cmdshell (sqlcmd 이전 모드 및 Powershell 이전 모드)은 트랜잭션 로그 파일을 프로덕션 서버에서 일정 시간 내에 수백 마일 떨어진 DR 서버로 복사 할 수있는 기능을 제공합니다. SQL 에이전트 작업입니다. 여기에 악의는 없지만 한 포스터가 말했듯이 “상황에 따라 다릅니다”.

jl01을 강조하려면 ” s 대답 (+1을했습니다) …

이상하게도 적절하게 보안되고 안전한 SQL Server의 좋은 척도는 실제로 xp_CmdShell을 활성화하는 것입니다.즉, 시스템이 충분히 안전하다면 “xp_CmdShell이 활성화되고 사용되는 것과 같은 사소한 문제에 대해 걱정할 필요가 없습니다.

특히 SQL Server 2005에서는 사실상 이유가 없습니다. DBA가 아닌 다른 사용자가 제대로 잠긴 시스템의 저장 프로 시저에 대해 PUBLIC privs 및 EXECUTE priv보다 큰 priv를 가져야하는 이유. 실제로 올바르게 구현되면 PUBLIC privs를 가진 사용자는 xp_CmdShell을 직접 실행할 수 없어도 xp_CmdShell에 대한 호출이 포함 된 저장 프로 시저를 실행할 수 있어야합니다.

MS가 명령 셸 프록시를 만든 것은 아이러니 한 일이라고 생각합니다. 권한이 낮은 사용자가 테이블을 볼 수없는 경우에도 xp_CmdShell을 직접 실행할 수 있도록합니다.