Executes a multitude of security scanning tools, does other custom coded checks and prints the results spontaneously.
Come of the tools include nmap, dnsrecon, wafw00f, uniscan, sslyze, fierce, lbd, theharvester, dnswalk, golismero etc executes under one entity.
Saves a lot of time, indeed a lot time!
Checks for same vulnerabilities with multiple tools to help you zero-in on false positives effectively.
Legends to help you understand which tests may take longer time, so you can Ctrl+C to skip if needed.
Association with OWASP Top 10 2017 on the list of vulnerabilities discovered. (under development)
Critical, high, large, low and informational classification of vulnerabilities.
Vulnerability definitions guides you what the vulnerability actually is and the threat it can pose
Remediations tells you how to plug/fix the found vulnerability.
Executive summary gives you an overall context of the scan performed with critical, high, low and informational issues discovered. (under development)
Artificial intelligence to deploy tools automatically depending upon the issues found. for eg; automates the launch of wpscan and plecost tools when a wordpress installation is found. (under development)
Detailed comprehensive report in a portable document format (*.pdf) with complete details of the scans and tools used. (under development)
For Your Infomation about RapidScan:
Program is still under development, works and currently supports 80 vulnerability tests.
Parallel processing is not yet implemented, may be coded as more tests gets introduced.
RapidScan supports checking for these vulnerabilities:
DNS/HTTP Load Balancers & Web Application Firewalls.
Figura 1: Contratar hackers profesionales para hackear WhatsApp, la universidad y espiar a tu pareja: La estafa.
A día de hoy sigo recibiendo estos mensajes, sobre todo por mi cuenta de Instagram, donde dejé de leer los mensajes que me enviaban hace tiempo, debido a la cantidad ingente de cosas que me preguntaban - desde se me ha roto el PowerPoint hasta quiero hackear un Fabebook -.
Pero hoy os quería hablar de varios mensajes que me han llegado por mi cuenta de MyPublicInbox, donde me han preguntado varias personas por unas webs de "Hackers for Hire". Es decir, de webs que ofrecen servidos de "Hackers Profesionales" para hacer lo que muchos siempre sueñan. Pero es una estafa y por supuesto ni los iconos de Twitter, Linkedin o números de teléfono funcionan. Son más falsos que una moneda de madera.
Figura 3: Página de Hackers Profesionales for Hire
Estas páginas - y esta en concreto - se presentan como una página de una empresa de verdad, con profesionalidad y como si fuera un servicio, pero no es más que una fachada para conseguir lo importante, el contacto de la persona que quiere contratarlos para sacarle dinero. Para ello, la web está llena de los términos y cadenas de búsqueda que las personas utilizan en Google y otros buscadores para localizar a estos "Hackers for Hire".
Figura 4: Servicios de Hackers
El dinero a las le van a sacar de dos formas. Primero por el servicio que su víctima - que es la persona que los quiere contratar - solicita. Es decir, el coste que negocian por cambiar notas de la universidad, por borrarlo de un fichero de morosos, de hackear y espiar un WhatsApp, etcétera. Lo que la persona que los quiera contratar quiera. ¿Quieres hackear una base de datos del gobierno para borrar una multa? No te preocupes, ellos tienen ese servicio. Siempre que pagues por anticipado el dinero.
Figura 5: "Buscas contactar un Hacker Informatico en Barcelona" o en Madrid
Las webs están llenas de cadenas de SEO utilizadas por los que buscan este tipo de servicios. Y esta concretamente está orientada a estafar a personas de España, por eso posiciona términos con España, Madrid, Barcelona, Toledo, Vigo, Mallorca, y otras ciudades de por aquí, pero se ve claramente que el lenguaje no es 100% del que utilizamos por aquí, ya que utiliza expresiones y forma de escribir no comunes en España.
Figura 6: Algunas cosas en las que somos geniales!!
Esta parte me ha encantado. El título de la Figura 6"Algunas cosas en las que somos geniales!!" es muy cercano y juvenil. El texto después es serio y profesional. La parte de universidades es absolutista, dejando claro que su sistema es efectivo para hackear universidades, cuando los sistemas de cada universidad son diferentes. De esto ya os hablé en un artículo hace tiempo en el artículo de "La estafa del hacker para cambiar notas de las universidades".
Figura 8: Vídeo de webs para "Hackear Facebook en 1 minuto"
A pesar de parecer la página de una empresa, cuando se ven los textos en detalle, se puede observar que no están cuidados, ya que están mal puntuados, mal acentuados y con expresiones que parecen no tener mucho sentido. Solo se trata de poner cadenas de texto que hagan que llegue tráfico desde los buscadores.
Figura 9: Servicios Hacker Profesional
En la web hay un par de partes que me han impactado especialmente. La primera esta de "Client Testimonials" que es una mala traducción al inglés porque entiendo que están utilizando esta misma estafa para países angloparlantes. En ella se ven fotos de supuestos clientes, satisfechos con sus servicios.
Figura 10: "No confíe en nuestra palabra: esto es lo que dicen nuestros clientes"
Sorprendentemente, basta con hacer una búsqueda en Google Images con la primera de las fotos y ver que estos tipos no han tenido ningún miramiento, ya que han utilizado la foto del obituario de una persona fallecida en el año 2016 en Florida (Estados Unidos), que por supuesto no se llama Carlos Manrique.
Figura 11: Uno de los supuestos clientes es una persona fallecida
Y lo mismo para el equipo de la empresa. Donde todos son guapos, profesionales, y con puestos de lo más variopintos. Por supuesto, los enlaces a Twitter, Linkedin, etcétera, no funcionan. Son solo decoración para hacer parecer más profesional esta página de "Hackers for Hire". Eso sí, el vídeo al principio de la web es de Anonymous, pero luego están los perfiles de los "Hackers Profesionales".
Figura 12: El supuesto equipo de "Hackers Profesionales"
Por supuesto, siendo tan guapos no me extrañó que la buscar algunas de las fotos en Google Images apareciera que eran modelos. Uno de ellos, en concreto Andrés Ferrari, que es el supuesto CEO y Fundador de este grupo de hackers profesionales guapos, es un modelo de barbas.
Figura 13: Andrés Ferrari es un modelo de barbas
Por supuesto, para cubrir todo el abanico a la hora de convencer a sus "clientes", esta web pone el puntito técnico, añadiendo información de un bug descubierto por el equipo de Project Zero de Google que afectaba a iOS (iPhone) y que fue arreglado el año pasado. Por supuesto, estos exploits tienen un alto valor - ya vimos lo que se podía pagar por un exploit remoto de iPhone - y por supuesto la gente que los tiene los vende a los "vendors" de seguridad y no los usa para hackear el WhatsApp de las parejas de la gente.
Figura 14: Supuesto exploit usado
Como se puede ver la expresión de "¿Qué tan grave es..." tampoco es una expresión muy común por aquí en España. Y lo curioso es que la letra pequeña explica que la vulnerabilidad está parcheada. En el siguiente vídeo os dejo una visita explicada a la web de estos "Hackers for Hire".
Figura 15: Hackers for Hire "La estafa"
Por último, os había dicho que una de las formas con las que sacaban dinero era con vender el servicio - que no van a hacer porque se jugarían un problema legal más gordo -. Lo que hacen es pedir dinero y más dinero a su cliente hasta que este se enfada y deja de enviarles dinero. Entonces, a veces, amenazan al cliente con denunciarle y hacer públicos los datos y las conversaciones que han tenido con él, extorsionando al contratante de los "hackers for hire".
Y si consiguen datos suficientes, pues se pueden dar los mismos problemas que comentaba en la estafa de la venta fraudulenta, si ellos han conseguido datos suficientes de quién los contrata. A todos los demás, os recomiendo que os leáis el libro de "Cómo protegerse de los peligros en Internet" porque esta estafa de "hackers for hire" existe debido a que hay una demanda muy grande por parte de las personas. Triste, pero es así.
In part 1 and 2 we covered re-entrancy and authorization attack scenarios within the Ethereum smart contract environment. In this blog we will cover integer attacks against blockchain decentralized applications (DAPs) coded in Solidity.
Integer Attack Explanation:
An integer overflow and underflow happens when a check on a value is used with an unsigned integer, which either adds or subtracts beyond the limits the variable can hold. If you remember back to your computer science class each variable type can hold up to a certain value length. You will also remember some variable types only hold positive numbers while others hold positive and negative numbers.
If you go outside of the constraints of the number type you are using it may handle things in different ways such as an error condition or perhaps cutting the number off at the maximum or minimum value.
In the Solidity language for Ethereum when we reach values past what our variable can hold it in turn wraps back around to a number it understands. So for example if we have a variable that can only hold a 2 digit number when we hit 99 and go past it, we will end up with 00. Inversely if we had 00 and we subtracted 1 we would end up with 99.
Normally in your math class the following would be true:
99 + 1 = 100 00 - 1 = -1
In solidity with unsigned numbers the following is true: 99 + 1 = 00 00 - 1 = 99
So the issue lies with the assumption that a number will fail or provide a correct value in mathematical calculations when indeed it does not. So comparing a variable with a require statement is not sufficiently accurate after performing a mathematical operation that does not check for safe values.
That comparison may very well be comparing the output of an over/under flowed value and be completely meaningless. The Require statement may return true, but not based on the actual intended mathematical value. This in turn will lead to an action performed which is beneficial to the attacker for example checking a low value required for a funds validation but then receiving a very high value sent to the attacker after the initial check. Lets go through a few examples.
Simple Example:
Lets say we have the following Require check as an example: require(balance - withdraw_amount > 0) ;
Now the above statement seems reasonable, if the users balance minus the withdrawal amount is less than 0 then obviously they don't have the money for this transaction correct?
This transaction should fail and produce an error because not enough funds are held within the account for the transaction. But what if we have 5 dollars and we withdraw 6 dollars using the scenario above where we can hold 2 digits with an unsigned integer?
Let's do some math. 5 - 6 = 99
Last I checked 99 is greater than 0 which poses an interesting problem. Our check says we are good to go, but our account balance isn't large enough to cover the transaction. The check will pass because the underflow creates the wrong value which is greater than 0 and more funds then the user has will be transferred out of the account.
Because the following math returns true: require(99 > 0)
Withdraw Function Vulnerable to an UnderFlow:
The below example snippet of code illustrates a withdraw function with an underflow vulnerability:
In this example the require line checks that the balance is greater then 0 after subtracting the _amount but if the _amount is greater than the balance it will underflow to a value above 0 even though it should fail with a negative number as its true value.
require(balances[msg.sender] - _amount > 0);
It will then send the value of the _amount variable to the recipient without any further checks:
msg.sender.transfer(_amount);
Followed by possibly increasing the value of the senders account with an underflow condition even though it should have been reduced:
balances[msg.sender] -= _amount;
Depending how the Require check and transfer functions are coded the attacker may not lose any funds at all but be able to transfer out large sums of money to other accounts under his control simply by underflowing the require statements which checks the account balance before transferring funds each time.
Transfer Function Vulnerable to a Batch Overflow:
Overflow conditions often happen in situations where you are sending a batched amount of values to recipients. If you are doing an airdrop and have 200 users who are each receiving a large sum of tokens but you check the total sum of all users tokens against the total funds it may trigger an overflow. The logic would compare a smaller value to the total tokens and think you have enough to cover the transaction for example if your integer can only hold 5 digits in length or 00,000 what would happen in the below scenario?
You have 10,000 tokens in your account You are sending 200 users 499 tokens each Your total sent is 200*499 or 99,800
The above scenario would fail as it should since we have 10,000 tokens and want to send a total of 99,800. But what if we send 500 tokens each? Lets do some more math and see how that changes the outcome.
You have 10,000 tokens in your account You are sending 200 users 500 tokens each Your total sent is 200*500 or 100,000 New total is actually 0
This new scenario produces a total that is actually 0 even though each users amount is 500 tokens which may cause issues if a require statement is not handled with safe functions which stop an overflow of a require statement.
Lets take our new numbers and plug them into the below code and see what happens:
1: The total variable is 100,000 which becomes 0 due to the 5 digit limit overflow when a 6th digit is hit at 99,999 + 1 = 0. So total now becomes 0.
2: This line checks if the users balance is high enough to cover the total value to be sent which in this case is 0 so 10,000 is more then enough to cover a 0 total and this check passes due to the overflow.
3: This line deducts the total from the senders balance which does nothing since the total of 10,000 - 0 is 10,000. The sender has lost no funds.
4-5: This loop iterates over the 200 users who each get 500 tokens and updates the balances of each user individually using the real value of 500 as this does not trigger an overflow condition. Thus sending out 100,000 tokens without reducing the senders balance or triggering an error due to lack of funds. Essentially creating tokens out of thin air.
In this scenario the user retained all of their tokens but was able to distribute 100k tokens across 200 users regardless if they had the proper funds to do so.
Lab Follow Along Time:
We went through what might have been an overwhelming amount of concepts in this chapter regarding over/underflow scenarios now lets do an example lab in the video below to illustrate this point and get a little hands on experience reviewing, writing and exploiting smart contracts. Also note in the blockchain youtube playlist we cover the same concepts from above if you need to hear them rather then read them.
For this lab we will use the Remix browser environment with the current solidity version as of this writing 0.5.12. You can easily adjust the compiler version on Remix to this version as versions update and change frequently. https://remix.ethereum.org/
Below is a video going through coding your own vulnerable smart contract, the video following that goes through exploiting the code you create and the videos prior to that cover the concepts we covered above:
This next video walks through exploiting the code above, preferably hand coded by you into the remix environment. As the best way to learn is to code it yourself and understand each piece:
Conclusion:
We covered a lot of information at this point and the video series playlist associated with this blog series has additional information and walk throughs. Also other videos as always will be added to this playlist including fixing integer overflows in the code and attacking an actual live Decentralized Blockchain Application. So check out those videos as they are dropped and the current ones, sit back and watch and re-enforce the concepts you learned in this blog and in the previous lab. This is an example from a full set of labs as part of a more comprehensive exploitation course we have been working on.
Security Onion is a free and open source Linux distribution for intrusion detection, enterprise security monitoring, and log management. It includes Elasticsearch, Logstash, Kibana, Snort, Suricata, Bro, OSSEC, Sguil, Squert, NetworkMiner, and many other security tools. The easy-to-use Setup wizard allows you to build an army of distributed sensors for your enterprise in minutes!
This story is about a bug generated by g++ and clang compilers (at least) The condition_variables is a feature on the standard library of c++ (libstdc++), when its compiled statically a weird asm code is generated.
The compilers can't copile well this code in static, and same happens on other condition_variable methods. I would say the _lock is being assembled improperly in static, is not exacly a null pointer derreference but the effects are the same, executing code at address 0x00 which on linux is a crash on most of cases.
Modern gcc compiler (v9.2.0) protects the stack by default and you will notice it because instead of SIGSEGV on stack overflow you will get a SIGABRT, but it also generates coredumps.
In this case the compiler adds the variable local_10. This variable helds a canary value that is checked at the end of the function. The memset overflows the four bytes stack variable and modifies the canary value.
The 64bits canary 0x5429851ebaf95800 can't be predicted, but in specific situations is not re-generated and can be bruteforced or in other situations can be leaked from memory for example using a format string vulnerability or an arbitrary read wihout overflowing the stack.
If the canary doesn't match, the libc function __stack_chck_fail is called and terminates the prorgam with a SIGABORT which generates a coredump, in the case of archlinux managed by systemd and are stored on "/var/lib/systemd/coredump/"
❯❯❯ ./test *** stack smashing detected ***: terminated fish: './test' terminated by signal SIGABRT (Abort)
We specify the binary and the core file as a gdb parameters. We can see only one LWP (light weight process) or linux thread, so in this case is quicker to check. First of all lets see the back trace, because in this case the execution don't terminate in the segfaulted return.
We can see on frame 5 the address were it would had returned to main if it wouldn't aborted.
Happy Idea: we can use this stack canary aborts to detect stack overflows. In Debian with prevous versions it will be exploitable depending on the compilation flags used. And note that the canary is located as the last variable in the stack so the previous variables can be overwritten without problems.
Hoy sábado, puente de San Isidro en Madrid, os traigo unos vídeos que he recopilado del pasado, además de unos vídeos que tenemos de esta semana que han hecho mis compañeros de ElevenPaths. Son charlas, entrevistas y podcasts que tienen que ver con las cosas que hacemos, ya sabéis: Ciberseguridad, Big Data, AI, etcétera. Os los pongo en orden cronológico, es decir, lo más nuevo al final, y lo más antiguo al principio.
Figura 1: Yesterday & Today: Unos vídeos para el "weekend" de cosas que hemos hecho y hacemos
El primero que os dejo es una entrevista del año 2014 que me hizo la periodista Mercedes Milá en mi querida Telefónica para hablar de la Deep Web, de la Red Tor y de un caso que fue mediático por aquel entonces.
Figura 2: Entrevista con Mercedes Milá
El segundo vídeo que os traigo es del año 2015 cuando en las conferencias Dare2Data fuimos Pedro Pablo Pérez, CEO de ElevenPaths y yo, a las instalaciones del BBVA a dar una charla de Ciberseguridad & BigData que tienes por aquí.
Figura 3: Ciberseguridad & Big Data
El tercer vídeo es del años 2018, cuando hicimos las jornadas de Telefónica Expert Cybersecurity Day en México y yo expliqué la estrategia de ElevenPaths y Telefónica por vídeo conferencia en una charla en la que hablaba de la gestión de la seguridad en las empresas.
Figura 4: Conferencia en el Expert Cibersecurity Day
El siguiente vídeo fue del MWC de 2019, cuando presentamos las Living Apps e hicimos una entrevista a René, responsable tecnológico sobre la Living App del Atlético de Madrid que tienes en la sección Apps de Movistar+ de tu televisión en España.
Los dos últimos os los he subido a Youtube, donde tienes la entrevista a Yaiza Rubio, nuestra gran experta en ciberseguridad, hacking y tecnologías BlockChain & BitCoin en la que habla de los riesgos de seguridad durante esta crisis del COVID-19, entre otros temas.
Y el último vídeo es un podcast de ElevenPaths Radio Actualidad donde se habla de "Seguridad Low-Cost", que para las PYMES, y especialmente en estos momentos, es algo que interesa mucho. Espero que os guste.
Figura 9: ElevenPaths Radio Acualidad "Seguridad Low-Cost"
Y esto es todo lo que os traigo para hoy, que como veis no es poca cosa. Espero que paséis un buen fin de semana y que no os olvidéis de salir a tomar el aire, de llamar a los papás y mamás y de hacer algo de deporte.
.jpg)
More info