1500 Bytes

In a previous post, 'Memory and Stack Frames', I covered the basics of computer memory and stack frames. Now it's time to take that theory and give it a practical application. Under the spotlight is a C program that was presented as a flag in 'The Necromancer', a CTF challenge machine I downloaded from https://www.vulnhub.com/ . The file is named 'talisman' and presents the following output when it is run: You have found a talisman. The talisman is cold to the touch, and has no words or symbols on it's surface. Do you want to wear the talisman?          The program is waiting for user input at this stage. After spending some time trying various words (' yes ',' no ',' maybe ',' wear ') and phrases (' wear the talisman ',' wear talisman ') it was clear that the answer was always the same - " Nothing happens. ". You have found a talisman. The talisman is cold to the touch, and has

Recently I completed a Capture The Flag machine named 'The Necromancer' from the site VulnHub.  If you've never heard of VulnHub before, it is essentially a site that provides 'hands-on' experience in digital security by way of virtual machines designed to be deliberately vulnerable to certain exploits ( https://www.vulnhub.com/about/ ). One of 'The Necromancer''s 11 flags requires the use of a memory buffer overflow. In short, a memory buffer overflow occurs when a program attempts to put more data into an allocated section of memory than it can hold (for instance, 50 bytes of data into a 40 byte memory buffer) causing the program to crash or, in some instances, execute malicious code. To understand and execute a memory buffer overflow first requires knowledge of memory, how it is allocated and how it is used. This knowledge is crucial to have before writing any code to execute an attack. In typical fashion I ended up with dozens of pages containing

GDB (The GNU Project Debugger) is a debugging tool that I admittedly have a love/hate relationship with. On the one hand it is extremely good at what it does, while on the other hand it has a terribly frustrating learning curve. After getting through the initial 'none of this is making sense' barrier, however, using GDB is a fantastic way to learn about C, assembly, and debugging. GDB is started from the terminal with the following syntax: gdb (options) (filename)  To 'quietly' open a C file named 'Talisman' would require the following syntax:  gdb -q Talisman  The location of the file matters and will need to be specified if it isn't in the current working directory.  Note: if the original source code was compiled without debugging options specified, a 'no symbols' error will be presented. This means the source code is not available for viewing inside GDB, however, we can still view the assembly code.  When working with GDB th

Let's take a look at some options available to us when securing traffic that is transmitted over the Internet. For the sake of a scenario to work with lets consider that site A is an existing site with a 3rd party network we must integrate with, and site B is a newly commissioned site that now needs to receive traffic. The deployment initially consists of two Cisco ASA 5505X's, each with a connection to a public Internet connection. A VPN is configured between these two devices to allow secure transmission of  traffic from the third party network over the Internet to the storage server.  Worth mentioning is the basic configuration of a Cisco ASA. Out of the box it will require configuration for an 'Inside' and 'Outside' interface, as well as SSH for remote management: ## Cisco ASA interface configuration:   interface GigabitEthernet1/1 nameif outside security-level 0 ip address ( publicIP ) 255.255.255.252 interface GigabitEthernet1/3 nameif