Archive

Archive for the ‘security’ Category

SLSA • Supply-chain Levels for Software Artifacts

Oh thank God I am not the only one who sees the next techopolus (O-day apocalypse) as we all adopt kubernetes as the orchestration platform and we forget about *where* those container images come from… http://slsa.dev/

Categories: security Tags: , , ,

Bank API as Microservices with CQRS in TypeScript | Level Up Coding

Very seldom, do we get to see several technologies used so well together. With the exception of how to illustrate how the secrets should be managed, this article really shows what secure by design is all about.

https://levelup.gitconnected.com/microservices-with-cqrs-in-typescript-and-nestjs-5a8af0a56c3a

Categories: security Tags: ,

New European rules for mobile banking apps coming to a device near you…

July 26, 2019 Leave a comment

The world is clearly a better place now that we carry computers in our back pocket but we need an increase in security measures for payment transactions and therefore we will require an increase in regulation, such as the PSD2 from European Commission.

The Payment Services Directive mandates compliance by September 2019 and aims to regulate banks, payment service providers and electronic payments to include security features to protect consumers across digital channels. The PSD2 legislation will require financial services in the European Union (EU) to contribute to a more integrated, secure, and efficient payments ecosystem.

The PSD2 directive requires financial institutions to:

  • Provide/Implement a monitoring mechanism in their apps to detect/report signs of malware.
  • Provide security measures in their app to mitigate risk for the user device.
  • Ensure consumers have a secure environment to execute their financial transactions

In Article 2 and Article 9 of the directive, PSD2 highlights Strong Customer Authentication (SCA) and Safe Execution Environment (SEE), which requires de-risking across various threat vectors impacting mobile apps.

These include detecting compromised devices (eg: jailbroken or rooted), unsafe environments (such as a fake or malicious wi-fi), as well as malware and vulnerabilities within the application execution environment. PSD2 also includes RTS (Regulatory Technical Standards), which are regulatory requirements set by the European Banking Authority (EBA) to ensure that payments across the EU are secure, fair & efficient.

To meet these requirements, financial institutions should add strong security capabilities like binary protections to their mobile apps. These controls are designed to protect against known and unknown threats on users’ devices.

Mobile banking apps should also be able to detect when they are installed on risky devices and consider restricting access to high value banking services until those risks have been remediated.

Categories: Mobile, security Tags: ,

Web servers are still vulnerable…

April 28, 2018 Leave a comment

In a survey published on an often referenced support site for developers (Stack Overflow), they recently confirmed that JavaScript is the most popular programming language for the 6th year in a row. Almost 70% of the respondents claim that they visit searching for help on this subject so it may not come as a surprise that JavaScript is also the primary cause of vulnerabilities on websites today.

In a blog post from the vendor that brings us one of the most popular tool for hacking websites and finding vulnerabilities, Portswigger writes a great article in which they detail a number of methods that can be used to abuse JavaScript and to bypass cross site scripting mitigation by most frameworks.

There are thousands of ways that can be used to bypass XSS in websites and web developers should already know this. XSS is the number one method to compromise a browser which, in combination with privilege escalation can allow an attacker to take over your computer. Even script kiddies can capture session tokens or cookies from websites without proper security controls that can be used to login as you without even knowing your password. Here is a list of the risks in order of importance for an attacker;

  1. Account hijacking
  2. Credential stealing
  3. Sensitive Data Leakage
  4. Drive by Downloading
  5. Keyloggers/Scanners
  6. Vandalism

Don’t ignore these risks on your websites, public facing or not. If you login to a website often in your organization and it is vulnerable to cross site scripting, teach your users how to identify security risks that could be used to harvest credentials and expose them to malicious attacks. You may also want to make sure that your sites are tested to ensure they are not vulnerable to this type of attack. With Phishing attacks being the number one method that pentesters gain access to your organization, xss is the primary method being used.

 

Categories: security, Work related Tags: ,

RFID hacking for fun (and profit)

November 11, 2016 1 comment

I recently received a new proxmark3 easy and began the fun of reader and cloning access badge cards. For those of you unaware of how these little while cards work, allow me to share some fun facts. The Radio Frequency Identification Device (RFID) Card are comprised of a coil of copper wire wrapped in a loop to create an electronic field. They also have an Integrated circuit (IC) embedded in them that is powered when the field is oscillated. Remember how rubbing your hands together creates static electricity?proxcard

This oscillating field comes from the reader and is tuned to a specific frequency that can be used to pickup a unique identifier from your card.

Near Field Communication (NFC) uses this mechanism and has a more dense command set which can allow it to utilize encryption.

We use RFID tags on most consumer goods to prevent theft and there was once an idea to embed these into pets and even humans!

proxmark3With a little computer know-how  and about $100.00 you can create a device that can be used to clone these badges in just seconds.

I setup my device to capture some data from my work facility with relative ease. Once stored (captured) from any card, the buffer of the device can now replay the signal to fool any reader.

I wanted to show you what some of the thinest cards would look like when they are scanned. The version I am using is a 37 bit iClass px D8L and it features the facility code and the card holder number (blanked out for security purposes).

proxcard2

Verifying the data from any card is as simple as issuing the command ‘lf search’. Here we can see the card number (known as the TAG ID) that would be registered into the security system along with the format length.

Now for the fun part – we place our valid card on top of our reader and issue the following command – ‘lf hid fskdemod’. This will tell you the TAG ID and will repeat quite a few times until it has sampled the modulated waveform.

Now we place a T5577 card on our proxmark device and type ‘lf hid clone’ followed by the TAG ID number. With any luck, you now have a cloned copy of your card!

Beware of manned security stations using newer technology, they will often look at the face of anyone who had their picture taken while being issued a card. Unless you look very similar to the person whose card you have cloned, you will surely be caught.

Next step is to setup a malware program on the security computer so that your picture is substituted for the card holder and our physical security challenge is successful. I wonder what their favourite website is to use when there is no one coming in and out of the building….hmmm. Nextime.

 

Categories: security Tags: ,

Playing with ASLR for Linux

November 5, 2016 Leave a comment

I recently completed a certification with SANS where we were taught to create our own exploits. A well behaved program should have a start procedure called a prologue, clean up and maintain itself and any objects it creates and finally an end. During our testing we assumed that Address Space Layout Randomization (ASLR) was turned on in order for our exploits to be successful but this is not always the case.

All programs have two different sections (instructions and data) and they need to be flagged differently in the memory. A section where only normal data is stored should be marked as non-executable. Executable code that does not dynamically change, should be flagged as read-only.

One of the tricks that hackers use to get control is to hijacking the stack pointer (a road map for where to go next). Evil programs are designed to perform a redirection in order to run their own malicious code. When any program is running in memory, if we want to protect it against evil programs we can use ASLR. Address space layout randomization is based upon the low chance of an attacker guessing the locations of randomly placed areas. Security is increased by increasing the search space.


Auditing

One of the easiest ways to find if a Linux server had ASLR turned on was to look at the proc filesystem for the variable ‘randomize_va_space’.

cat /proc/sys/kernel/randomize_va_space

If the value returned was a zero (0) then it was off, a one (1) then it was on for the stack. Ideally you want to use the value two (2) which will also randomize the data segments but all programs need to be built as a Position Independent Executable (PIE). It will also require that all shared object libraries (.so libraries) also be built as PIE.

Another way to see if ASLR has been activated is to run ldd against your executable and inspect the load address of the shared object libraries.

$ ldd -d -r demo
linux-vdso.so.1 => (0x00007fffe2fff000)
libc.so.6 => /lib64/libc.so.6 (0x00007f3e73cd8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3e74057000)
$ ldd -d -r demo
linux-vdso.so.1 => (0x00007fff053ff000)
libc.so.6 => /lib64/libc.so.6 (0x00007f82071ac000)
/lib64/ld-linux-x86-64.so.2 (0x00007f820752b000)

Notice the change in the memory address referenced by the C library and the dynamic linker (libc and ld-Linux-x86-64)? This indicates that ASLR is in effect.

To ensure that all of your Linux code is more difficult to bypass you will want to audit your systems and look for the value of 2 (assuming your other programs fully support PIE.

root@mybox:~$ sysctl -a –pattern “randomize”

kernel.randomize_va_space = 2


Bypass

I refer to ‘Bypassing ASLR’ on the Linux system as finding a way to defeat it as a security mechanism. If all shared libraries were compiled as PIE along with all executables (services if attacking remotely and all executables if granted console access) then ASLR would be very difficult to beat but that is not the case. The additional checks required to be sure that the attack footprint has been reduced to zero is to audit each of the services publically available to make sure that all libraries and executables involved are 100% position independent.

There is a great opensource tool out there for checking if your executables support PIE.

‘CheckSec.sh’ maintained by slimm609 (https://github.com/slimm609/checksec.sh)

Categories: security, Work related