Skip to main content

Ethical hacking

gap analysis

improvement


https://hakin9.org/

www.hackthissite.org

http://www.securitytube.net/

Pluralsight.com


http://www.reddit.com/r/HowToHack/


If you are serious about learning to hack ethically you first need to learn the basics and building blocks. You can't "learn" hacking: Hacking is the result of having an understanding of the underlying systems, protocols and functions to such a degree that you understand the code better than the programmers who wrote it. In other words, to "learn" to hack, you need to learn the fundamental building blocks of every aspect of IT.

A simple example of this is the discovery of the buffer overflow: Most programmers don't know what the CPU actually does. They don't understand the complexities of ASM, stack, registers etc. A (good) hacker on the other side does understand exactly how the CPU works, they can program in ASM (Assembly) which (here we go) is the fundamental building block of programming. C++, Visual Basic, C# etc, all ultimately convert their code into Assembly code, or opcode, or hex code. Some hackers are so proficient at this that they are able to read a program's hex code (open any program in XVI32 for instance), read the opcodes and see what's going on. Very few people ever reach this (over-the-top) level of Assembly, but you should at the very least be able to understand the Assembly version of a program ( basically, opcodes translated into ASM code, a bit more readable to the human eye than hex code ).

Once you know Assembly, you'll want to learn a programming language to program your own exploits and tests for network vulnerability scanning. These programs are best coded in higher-level languages like C++, C# or VB (or any other high-level language of your preference) so you'll have to learn to program in one of those languages too. Learn about how APIs work, but also what is behind the APIs. You'll learn about RING0, RING3 etc on your way and you should learn how to program drivers too, and use debuggers like SoftICE, IDA Pro and OllyDBG, as well as the surprisingly useful windows debugger.

Then, you'll have to learn the basics of networking. Now, just like programmers, most networking people don't actually understand the basics of networking. They understand how they can configure a router, a switch, they understand the basics of DHCP, and routing protocols like EIGRP and OSPF. But most of them never quite understand the fundamental building blocks of networking: The TCP/IP stack. One could write a 1000-page book just about the workings of TCP/IP. Often, the best resource to learn TCP/IP can be source codes of the TCP/IP stack. You'll have to work your way up the OSI layer. At layer 1, you'll need to know how fiber transmits data, and you'll start to understand how you could exploit that, for instance, you can bend a fiber in a tight bend, which will leak some light, this light can then be read and translated by your sniffer. Similarly, you'll need to know how bits and bytes are transmitted over the network, and that you can actually read the emanations that hover just above the cables, which again you can intercept. You'll get up the layers, learning how to perform MITM attacks, eventually you'll get to the top layers and you'll learn how HTTP works, and how encryption techniques work. For multiple reasons, most programmers won't code their own algorithms, they will instead use a standard, so you'll have to learn these standards. You have to recognize traffic patterns and be able to tell what type of algorithm is most likely used. You can use tools that analyze this pattern but a good hacker will program his own tool set. After all, you can expect most companies will use the readily available toolsets.

Once you know these things, you can start about thinking to learn to hack. Remember that hacking is just a way to bend the system rules. Most programmers are by definition "efficient" (lazy) and this is what hackers tap into when finding and creating exploits.

In regards to backtrack and vulnerability scanners, they're for opportunistic script-kiddies and "efficient" security professionals.


Popular posts from this blog

LinuxGuruz Netfilter IPTABLES Firewall Page

The Netfilter Project Homepage http://www.netfilter.org Source Code Userspace code (tar.bz2) http://www.netfilter.org/files/iptables-1.3.0.tar.bz2 FAQ Netfilter/Iptables FAQ http://netfilter.samba.org/documentation/FAQ/netfilter-faq.html Firewall Forensics (What am I seeing?) FAQ http://www.robertgraham.com/pubs/firewall-seen.html Network Intrusion Detection Systems - IDS http://www.robertgraham.com/pubs/network-intrusion-detection.html Sniffing (network wiretap, sniffer) FAQ http://www.robertgraham.com/pubs/sniffing-faq.html Linux IP Masquerade FAQ http://en.tldp.org/HOWTO/IP-Masquerade-HOWTO/ Firewall Admins Guide to Porn FAQ http://www.robertgraham.com/pubs/firewall-pr0n.html Hacking Lexicon - hacking dictionary http://www.robertgraham.com/pubs/hacking-dict.html Submit a FAQ Link or URL http://www.linuxguruz.com/iptables/#links Scripts Home LAN masquerading http://the-devil.dnsalias.net/home/extremist_MASQ Home LAN ip6t...

How to Address the Patching Paradox

Analyze your vulnerability response capabilities.  Assess vulnerability detection and patching capabilities to identify vulnerability response issues. Tackle low-hanging fruit first.  Prioritize minor vulnerability response problems and build a comprehensive vulnerability response strategy over time. Eliminate barriers between security and IT teams.  Combine vulnerability and IT configuration data into a single platform to drive collaboration between security and IT teams. Create end-to-end vulnerability response processes.  Develop vulnerability response processes and ensure that security and IT teams have a shared view of these processes. Retain security talent.  Remove internal barriers, optimize day-to-day processes and automate mundane work; by doing so, an organization can create a positive environment for security teams, increase employee satisfaction and boost the likelihood of retaining top security talent. Manual vulnerability response process...

mobile application Security Testing

Apps that enterprises develop themselves (or have developed by outsourcers) must be tested, to ensure they’re not leaking customer data or opening the enterprise to attack It’s cheaper and faster to test apps pre-production than it is after deployment Automated testing of mobile software is faster and more effective than manual testing Mobile applications interact with back-end web servers and services that also need to be tested That’s where AppScan® comes in What customers struggle with: Deploying secure mobile applications – both iOS and Android Static testing of mobile applications for security exposures, prior to deployment Inability to assess security of mobile applications developed by outsourcers Finding resources to test application code Understanding security risks of the mobile application environment Bringing together mobile application testing results with back-end web application and services resu...