Agora imos probar outra forma de inxección SQL. A ver se a base de datos segue lanzando mensaxes de erro. Este método chámase "esperando atraso" e o propio atraso escríbese do seguinte xeito: waitfor delay 00:00:01'. Copio isto do noso ficheiro e pégalo na barra de enderezos do navegador.
Todo isto chámase "inxección SQL temporal cega". Todo o que estamos facendo aquí é dicir: "espera un atraso de 10 segundos". Se notaches, na parte superior esquerda temos a inscrición “conectando...”, é dicir, que fai a nosa páxina? Agarda pola conexión e despois de 10 segundos aparece a páxina correcta no monitor. Usando esta técnica, contactamos coa base de datos para que nos permita facerlle algunhas preguntas máis, por exemplo, se o usuario é Joe, entón debemos esperar 10 segundos. Está claro? Se o usuario é dbo, agarde tamén 10 segundos. Este é o método de inxección de SQL cego.
Creo que os desenvolvedores non solucionan esta vulnerabilidade ao crear parches. Esta é unha inxección SQL, pero o noso programa IDS tampouco o ve, como os métodos anteriores de inxección SQL.
Imos probar algo máis interesante. Copiemos esta liña co enderezo IP e peguemos no navegador. Funcionou! A barra TCP do noso programa volveuse vermella, o programa observou 2 ameazas de seguridade.
Xenial, a ver que pasou despois. Temos unha ameaza para o shell XP e outra ameaza: un intento de inxección SQL. En total, notáronse dous intentos de atacar a aplicación web.
Vale, agora axúdame coa lóxica. Temos un paquete de datos de intrusión no que IDS di que respondeu a varias intrusións no shell XP.
Se nos desprazamos cara abaixo, vemos unha táboa de códigos HEX, á dereita da cal hai unha bandeira coa mensaxe xp_cmdshell + &27ping, e obviamente isto é malo.
Vexamos aquí que pasou. Que fixo o servidor SQL?
O servidor SQL dixo: "podes ter o contrasinal da miña base de datos, podes obter todos os rexistros da miña base de datos, pero amigo, non quero que executes os teus comandos en min, iso non está nada ben"!
O que debemos facer é asegurarnos de que aínda que o IDS informe dunha ameaza para o shell de XP, a ameaza sexa ignorada. Se está a usar SQL Server 2005 ou SQL Server 2008, se se detecta un intento de inxección de SQL, bloquearase o intérprete de comandos do sistema operativo, impedindo que continúe co seu traballo. Isto é moi molesto. Entón, que debemos facer? Deberías tentar preguntarlle ao servidor moi amablemente. Deberías dicir isto: "por favor, papá, podo ter estas galletas"? Iso é o que fago, en serio, pregúntolle ao servidor moi educadamente! Pido opcións adicionais, pido reconfiguración e pido que se cambie a configuración do shell de XP para que o shell sexa accesible porque o necesito!
Vemos que IDS detectou isto; xa se observaron 3 ameazas aquí.
Basta mirar aquí: explotamos os rexistros de seguridade! Parece unha árbore de Nadal, hai moito colgado aquí! ¡Ata 27 ameazas de seguridade! Vaia rapaces, collemos a este hacker, conseguímolo!
Non nos preocupa que roube os nosos datos, pero se pode executar comandos do sistema na nosa "caixa" - isto xa é serio. Podes debuxar unha ruta Telnet, FTP, podes facerte cargo dos meus datos, é xenial, pero non me preocupo, simplemente non quero que te fagas cargo do shell da miña “caixa”.
Quero falar de cousas que realmente me atraparon. Traballo para organizacións, levo moitos anos traballando para elas, e dígovos isto porque a miña moza pensa que estou no paro. Ela pensa que o único que fago é estar no escenario e charlar, isto non se pode considerar traballo. Pero eu digo: "non, a miña alegría, son consultora"! Esa é a diferenza: digo o que penso e páganme por iso.
Vou dicir isto: nós, como hackers, encántanos romper a cuncha, e para nós non hai maior pracer no mundo que "tragar a cuncha". Cando os analistas de IDS escriben as súas regras, ve que as escriben para protexerse contra a manipulación do shell. Pero se falas co CIO sobre o problema da extracción de datos, pedirache que penses en dúas opcións. Digamos que teño unha aplicación que fai 100 "pezas" por hora. O que é máis importante para min: garantir a seguridade de todos os datos desta aplicación ou a seguridade do shell "box"? Esta é unha pregunta seria! De que debes preocuparte máis?
Só porque o teu shell "caixa" estea corrompido non significa necesariamente que alguén teña acceso ao funcionamento interno das aplicacións. Si, isto é máis que probable, e se aínda non pasou, pode ocorrer en breve. Pero teña en conta que moitos produtos de seguridade constrúense a partir da hipótese de que un atacante se move pola túa rede. Polo tanto, prestan atención á execución de comandos, á implementación de comandos, e debes notar que isto é algo serio. Prestan atención ás vulnerabilidades triviais, aos scripts entre sitios moi sinxelos e ás inxeccións SQL moi sinxelas. Non lles importan as ameazas avanzadas nin as mensaxes cifradas, non lles importan ese tipo de cousas. Poderíase dicir que todos os produtos de seguridade buscan ruídos, buscan xapas, buscan parar algo que che morde o nocello. Isto é o que aprendín ao tratar con produtos de seguridade. Non tes que comprar produtos de seguridade, non tes que conducir o camión en marcha atrás. Necesitas persoas competentes e capacitadas que comprendan a tecnoloxía. Si, meu Deus, exactamente persoas! Non queremos botarlle millóns de dólares a estas cuestións, pero moitos de vós traballaron neste campo e saben que en canto o seu xefe ve un anuncio, corre á tenda gritando: "Temos que conseguir isto! " Pero realmente non o necesitamos, só temos que arranxar o desorde que hai detrás. Esa foi a premisa desta actuación.
O ambiente de seguridade é algo no que pasei moito tempo entendendo como funcionan os mecanismos de seguridade. Unha vez que entendes os mecanismos de protección, ignorar a protección non é difícil. Por exemplo, teño unha aplicación web que está protexida polo seu propio firewall. Copio o enderezo do panel de configuración, pégoo na barra de enderezos do navegador e vou á configuración e intento facer scripts entre sitios.
Como resultado, recibo unha mensaxe de firewall sobre unha ameaza: bloqueáronme.
Creo que isto é malo, estás de acordo? Encontrou un produto de seguridade. Pero que pasa se intento algo así: introduzo o parámetro Joe'+OR+1='1
Como podes ver, funcionou. Corríxeme se me equivoco, pero vimos que a inxección de SQL derrotou o firewall da aplicación. Agora imos finxir que queremos crear unha empresa de implementación de seguridade, así que poñeremos o noso sombreiro de fabricante de software. Agora encarnamos o mal porque é sombreiro negro. Son consultor, polo que podo facer o mesmo cos fabricantes de software.
Queremos crear e implantar un novo sistema de detección de manipulacións, polo que iniciaremos unha empresa de detección de manipulacións. Snort, como produto de código aberto, contén centos de miles de sinaturas de ameazas de manipulación. Debemos actuar con ética, polo que non roubaremos estas sinaturas doutras aplicacións e as inseriremos no noso sistema. Sentarémonos a reescribilas todas: Bob, Tim, Joe, ven aquí, repasa rapidamente todas estas 100 sinaturas.
Tamén necesitamos crear un escáner de vulnerabilidades. Xa sabes que Nessus, un programa para a busca automática de vulnerabilidades, ten ben 80 mil sinaturas e scripts que buscan vulnerabilidades. Actuaremos de novo de forma ética e reescribirémolos todos no noso programa nós mesmos.
A xente pregúntame: "Joe, fas todas estas probas usando software de código aberto como Mod Security, Snort e similares, como se parecen aos produtos doutros fabricantes?" Eu contestolles: "Non se parecen en absoluto!" Como os fabricantes non rouban cousas dos produtos de seguridade de código aberto, sentan e escriben todas estas regras eles mesmos.
Se podes facer que as túas propias sinaturas e cadeas de ataque funcionen sen usar produtos de código aberto, esta é unha gran oportunidade para ti. Se non podes competir con produtos comerciais, movendo na dirección correcta, debes atopar un concepto que che axude a facerte famoso no teu campo.
Todo o mundo sabe que bebo. Déixame mostrar por que bebo. Se algunha vez fixeches unha auditoría do código fonte na túa vida, definitivamente beberás, confía en min, despois comezarás a beber.
Entón, a nosa linguaxe favorita é C++. Vexamos este programa - Web Knight, é unha aplicación de firewall para servidores web. Ten excepcións por defecto. Isto é interesante: se implemento este firewall, non me protexerá de Outlook Web Access.
Marabilloso! Isto débese a que moitos provedores de software extraen regras dunha aplicación e pégalas no seu produto sen facer unha chea de investigacións. Entón, cando desprego a aplicación de firewall web, descubro que todo sobre o correo web está feito incorrectamente. Porque case calquera correo web rompe a seguridade por defecto. Tes código web que executa comandos e consultas do sistema para LDAP ou calquera outra tenda de bases de datos de usuarios directamente en Internet.
Dime, en que planeta se pode considerar seguro algo así? Basta pensar niso: abres Outlook Web Access, premes ctrl +K, buscas usuarios e todo iso, xestionas Active Directory directamente desde Internet, executas comandos do sistema en Linux, se usas Squirrel Mail, ou Horde ou o que sexa. outra cousa. Estás sacando todos estes evals e outros tipos de funcionalidades inseguras. Polo tanto, moitos firewalls exclúenos da lista de riscos de seguridade, proba a preguntarlle ao fabricante do teu software sobre isto.
Volvamos á aplicación Web Knight. Roubou moitas regras de seguridade do escáner de URL, que analiza todos estes intervalos de enderezos IP. Entón, todos estes intervalos de enderezos están excluídos do meu produto?
Algún de vós quere instalar estes enderezos na súa rede? Queres que a túa rede funcione con estes enderezos? Si, é incrible. Está ben, desprámonos neste programa e vexamos outras cousas que este firewall non quere facer.
Chámanse "1999" e queren que o seu servidor web retroceda no tempo! Algún de vós lembra este lixo: /scripts, /iishelp, msads? Quizais un par de persoas lembrarán con nostalxia o divertido que era piratear tales cousas. "Lembras, amigo, canto tempo atrás "matamos" servidores, foi xenial!
Agora, se miras estas excepcións, verás que podes facer todas estas cousas - msads, printers, iisadmpwd - todas estas cousas que ninguén precisa hoxe. Que pasa cos comandos que non tes permitido executar?
Estes son arp, at, cacls, chkdsk, cipher, cmd, com. A medida que os enumeras, venche superado con recordos dos vellos tempos, "amigo, recordas cando tomamos ese servidor, recordas aqueles días"?
Pero aquí está o que é realmente interesante: alguén ve aquí WMIC ou PowerShell? Imaxina que tes unha aplicación nova que funciona executando scripts no sistema local, e estes son scripts modernos porque queres executar Windows Server 2008, e vou facer unha gran cousa protexendoo con regras deseñadas para Windows 2000. Para que a próxima vez que un provedor chegue coa súa aplicación web, pregúntalles: "Oe, home, cubriches cousas como bits admin ou executaches comandos de PowerShell, verificaches todas as demais cousas porque imos actualizar? e usar a nova versión de DotNET"? Pero todas estas cousas deberían estar presentes nun produto de seguridade por defecto!
O seguinte do que quero falarche son os erros lóxicos. Imos ao 192.168.2.6. Esta é aproximadamente a mesma aplicación que a anterior.
Podes notar algo interesante se desplazas a páxina cara abaixo e fai clic na ligazón Contacte connosco.
Se miras o código fonte da pestana "Contacte connosco", que é un dos métodos de pentesting que fago todo o tempo, notarás esta liña.
Pénsao! Escoito que cando viron isto, moitos dixeron: "Guau"! Unha vez estiven facendo probas de penetración para, por exemplo, un banco multimillonario, e notei algo semellante. Polo tanto, non necesitamos inxección de SQL nin scripts entre sitios: temos o básico, esta barra de enderezos.
Entón, sen esaxerar, o banco díxonos que tiñan tanto un especialista en redes como un inspector web e non fixeron ningún comentario. É dicir, consideraban normal que se puidese abrir e ler un ficheiro de texto a través dun navegador.
É dicir, pode simplemente ler o ficheiro directamente desde o sistema de ficheiros. O xefe do seu equipo de seguridade díxome: "si, un dos escáneres atopou esta vulnerabilidade, pero considerouna menor". Ao que respondín: vale, dáme un minuto. Escribo filename=../../../../boot.ini na barra de enderezos e puiden ler o ficheiro de inicio do sistema de ficheiros!
A isto dixéronme: "non, non, non, estes non son ficheiros críticos"! Respondín, pero isto é Server 2008? Dixeron que si, que é el. Eu digo, pero este servidor ten un ficheiro de configuración situado no directorio raíz do servidor, non? "Correcto", responden. "Xenial", digo, "e se un atacante fai isto", e escribo filename=web.config na barra de enderezos. Din: e que, non ves nada no monitor?
Digo: que pasa se fago clic co botón dereito no monitor e selecciono a opción Mostrar a fonte da páxina? E que atoparei aquí? "Nada crítico"? Verei o contrasinal do administrador do servidor!
E dis que aquí non hai ningún problema?
Pero a miña parte favorita é esta seguinte. Non me permites executar comandos na caixa, pero podo roubar o contrasinal e a base de datos do administrador do servidor web, revisar toda a base de datos, arrancar todo o material sobre a base de datos e os fallos do sistema e saír con todo. Este é un caso do malo dicindo: "hey home, hoxe é o gran día"!
Non deixes que os produtos de seguridade te enfermen! Non deixes que os produtos de seguridade te enfermen! Busca uns nerds, dálles todos eses recordos de Star Trek, fai que se interesen, anímaos a quedar contigo, porque eses apestosos aburridos que non se duchan todos os días son os que fan que as túas redes funcionen. Estas son as persoas que axudarán aos teus produtos de seguridade a funcionar como deberían.
Dime, cantos de vós podedes permanecer moito tempo na mesma habitación cunha persoa que di constantemente: "¡Oh, necesito escribir este guión con urxencia!", e quen está ocupado con isto todo o tempo? Pero necesitas as persoas que fan que os teus produtos de seguridade funcionen.
Voino dicir de novo: os produtos de seguridade son estúpidos porque as luces cometen erros constantemente, fan cousas de merda constantemente, simplemente non proporcionan seguridade. Nunca vin un bo produto de seguridade que non requira que unha persoa cun desaparafusador o apertase onde fose necesario para que funcione con máis ou menos normalidade. É só unha enorme lista de regras que di que é malo, iso é todo!
Entón, quero que vexades a educación, cousas como a seguridade, a formación politécnica, porque hai moitos cursos en liña gratuítos sobre temas de seguridade. Aprende Python, aprende Assembly, aprende probas de aplicacións web.
Isto é o que realmente che axudará a protexer a túa rede. As persoas intelixentes protexen as redes, os produtos de rede non! Volve ao traballo e dille ao teu xefe que necesitas máis orzamento para persoas máis intelixentes, sei que isto é unha crise, pero dille de todos os xeitos: necesitamos máis diñeiro para a xente, para adestralos. Se compramos un produto pero non compramos un curso sobre como usalo porque é caro, entón por que o compramos se non imos ensinar á xente a usalo?
Traballei para moitos vendedores de produtos de seguridade, pasei practicamente toda a miña vida implementando eses produtos e estou farto de todo o control de acceso á rede e outras cousas porque instalei e executei todos eses produtos de merda. Unha vez cheguei a un cliente, querían implementar o estándar 802.1x para o protocolo EAP, polo que tiñan enderezos MAC e enderezos secundarios para cada porto. Cheguei, vin que estaba mal, dei a volta e comecei a premer os botóns da impresora. Xa sabes, a impresora pode imprimir unha páxina de proba dos equipos de rede con todos os enderezos MAC e IP. Pero resultou que a impresora non admite o estándar 802.1x, polo que debería excluírse.
Despois desconectei a impresora e cambiei o enderezo MAC do meu portátil polo enderezo MAC da impresora e conectei o meu portátil, evitando así esta cara solución MAC, pensa niso! Entón, de que pode facerme esta solución MAC se unha persoa pode pasar calquera equipo como unha impresora ou un teléfono VoIP?
Entón, hoxe en día, para min é que paso tempo intentando comprender e comprender o produto de seguridade que comprou o meu cliente. Hoxe en día, todos os bancos nos que fago probas de penetración teñen todos estes HIPS, NIPS, LUGTHS, MACS e un montón de outras siglas que son unha merda completa. Pero estou tentando descubrir o que intentan facer estes produtos e como o intentan. Entón, unha vez que descubro que tipo de metodoloxía e lóxica usan para proporcionar protección, non se fai nada difícil ignorala.
O meu produto favorito co que vos deixo chámase MS 1103. É un exploit baseado en navegador que "pulveriza" HIPS, Host Intrusion Prevention Signature ou Host Intrusion Prevention Signature. De feito, está deseñado para evitar as sinaturas HIPS. Non quero mostrar como funciona porque non quero tempo para demostralo, pero fai un gran traballo para evitar esa seguridade e quero que o probes.
Vale rapaces, voume agora.
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com