Tag: Software

What is a Software Supply Chain Attack?

July 5th, 2021
There are essentially two types of software supply chain attack,
- Software Compromise to third party components of software,
- Watering Hole Attacks
Watering Hole Attacks

Software products have many facets and features that require real human capital and investment to implement. As a compromise in software development, software vendors may use code from third party libraries, plugins or even adapt existing software to reduce investment and enhance their product offering.

In cases where software vendors do not produce all parts of their applications they rely on the trust and value the third party software they have incorporated in to their product to ensure that software is not tampered or altered to behave maliciously or insecurely for their customers.

Having third party libraries that have been compromised or have been poorly selected may result in,
- Vulnerable parts of the software being exposed for attackers to utilise.
- The software being used for ways not intended by the vendor, such as allowing the malicious code to evade detection by operating through otherwise trusted code. DLLs (Dynamic Linked Libraries) are parts of a program that can sometimes be altered by attackers to perform functions not intended by the vendor of the software to perform malicious activity such as encrypting files or providing remote code execution.
- Features of the third party library may be unused by the customer but left in their default state could provide attackers privileged access.
An example of a watering hole attack could be,
- Feedify, a website push notification service was compromised and attackers were able to have their altered JavaScript run on websites that use the software.
- SolarWinds Orion, an IT management and remote monitoring product was attacked and compromised by altering updates pushed to customers, which in turn meant their customers were compromised by this attack. The update added a backdoor to customer’s IT systems, which was used to install malware.
- Kaseya VSA (Virtual System Administrator), another unified and remote monitoring IT product was compromised through SQL to install ransomware on affected and monitored machines and lock out owners in 2021.
Software Compromise

Magecart was also able to attack British Airways and steal customer payment data by altering a portion of the British Airways website to include software designed to strip the information and send it to the attackers. In this instance British Airways used software called Modernizr, a JavaScript library designed to detect capabilities of a customers browser to tailor user experience was altered to include AJAX to send payment data when submitted to another URL controlled by the attackers for storage and sale.

This example however using similar methods is not a watering hole attack, as the code was directly altered by the attackers on the victims website, trying to pass off as legitimate software from the vendor.

Where software compromise becomes extremely useful to attackers is when software vendors have their software built into environments more secure than their own, as attackers then have access to a weaker component in the supply chain. There may be a very secure environment that uses all of the latest and best practice to secure their environment but if they are reliant on third party software then they are only as strong as the weakest in the chain, like SolarWinds Orion or Kaseya VSA (Virtual System Administrator).

To protect companies from software supply chain attacks they could,
- Incorporate immutable backups to prevent ransomware, immutable backups are essentially backups that cannot be altered by ransomware directly as they are immutable, thus ransomware would need direct access to the backup facility to encrypt the backups.
- Use trusted third parties with good standing software security practices and modern tech stacks. Know the risks associated with partners and suppliers.
- Monitor resources for unauthorised alterations and increase visibility in to your supply chain.
- Audit third party libraries for unauthorised changes.
- Act quickly to security incidents in third party components like vulnerabilities and compromise.
- Close off or remove un-used features in third party libraries.
- Hash and monitor component signatures to detect changes and prevent your software running unauthorised functions.
- Secure your environment and silo components to prevent lateral movement.
- Build all products in-house. A very expensive and probably unrealistic solution except for the largest most specialised companies.
There are many methodologies to supply chain attacks that make it hard for even the most determined blue team to keep up with and monitor.
Writing a Requirement Specification Document for a Software Project

May 1st, 2019
When a problem or solution requiring software is conceived it is essential that the software project is properly conveyed to the software house, agency or project staff creating the software. When constructing the document there are defined standards that the SRS may be structured to follow, such as IEEE Std 830-1998 which has been superseded by IEEE Std 29148-2011.

The document may also be written by the customer should the client choose to do so as it may provide more control of the specifications required in the project. Simply a Software Requirements Specification (SRS) could be titled ;

This is what the customer wants the software to do.

Introduction

The introduction should indicate the expected behaviors of the software as clearly as possible detailing the processes, activities, interfaces, and tasks required by the software. The introduction can be muddied if the software is not already clearly conceptualized or thought out or is to be built onto existing software if the requirements are not understood by all parties. It may also be necessary to indicate the expected life cycle, phase-out period and maintenance required to maintain the performance and usability of the software. Users may also be considered.

Purpose

An SRS document may state the purpose of the software which could be considered an ultimate end-goal of the resulting project and consider the project a failure if not met. It should conclude with affirming that this document specifies how the software should be designed, developed, tested and implemented where applicable. If the purpose is to improve the speed of current business processes then make it appear in the purpose section, if the purpose is to improve the usability of the current software used by staff then include it in the purpose section as well. If the software is also supposed to do something not included in the purpose or easily justified by this section, then it can be hard to justify why such a feature should exist in the project.

Scope

The scope of the document is to provide a description of what the document specification includes, such as use cases and requirements. Some of the program may be in multiple documents so the scope is necessary to reduce overlap between projects.

System Overview

System Overview provides a description of the context, function and requirements of the software project.

References

References should indicate if the software is somewhat pre-existing, any references made in the document and references to appendixes should also be included too.

Overall Description

The overall description is the second section of the SRS document.

Product Perspective

A product perspective is a detailed outlook of what the program should appear like to the users of the system, some software projects may be completely transparent to users, if so then the product perspective should outline the interfacing between other software components that make it so.
- The overall description should not be vague, it should provide justification as to why the functions of the program are required.
- The overall description should detail crucial cornerstones of the program and interfaces that exist with the hardware or software.
- Some of the programs may be pre-existing which will require the project interface detailed and easily readable to be understood.
The Description should have six sections,
- System Interfaces which the user may interact with the system or the system may interact with other systems.
- User Interfaces which the users may interact with which may include the frequency of their usage and the intuitiveness of the design.
- Hardware. Including the frequency of use of the hardware, considerations to the longevity of the hardware and ability to update or dispose of the hardware.
- Software. Including external interfaces, naming conventions.
- Communication and Telecom both in interfaces software to software and to the user.
- Memory. Including minimum requirements.
- Operations and processes that the program may perform real-time or batch, transaction or otherwise.
- Adaptations and the ability to configure the system. For open source or high-security systems, this section may be larger than private or closed source software due to the need to ensure that it is secure or can be maintained or made depreciated quickly.
Design Constraints
- What are the limitations of the software?
- What might the software fail to perform at?
- What are the limitations of the programming language if selected?
- How might this delay the project if risks arise?
- What are the limitations of the users’ ability?
- What training will need to take place in order to use the software effectively?
- What does the software not do?
- What happens if a user does not use the software as intended?
In most aspects of software engineering, there are simply parts of human nature and failure modes or edge cases that simply cannot always be mitigated, in such scenarios it is important to outline what steps your software has taken to make these issues not slow the productivity of the software and ensure that the system runs as intended part of this may be detailed in test cases written in the appropriate section.

Product Functions

Product Functions should as best as possible describe the function of the program and how the modules of the program if any will work together with the interfaces of the system to produce the software’s desired functions.

The aim of the section is to break down the large characteristics of the program into more readable and manageable sections that can be delegated out to a team or read to an individual clearly without much overlap to avoid confusing what the program is designed to accomplish and what each function does.
- The functions should be organized and listed so that they may be read for the first time and understood effectively.
- The section may include graphical sections or UML detailing how the program may operate.
- The validity of the input.
- Sequence diagrams or how the program may pass data between functions.
- How the program accounts for abnormality.
- Common input examples may be a good way of explaining the function to the reader and providing a sample of what the programmer should accomplish on each function.
- Sequencing.
User Characteristics

When a user may use the system either from time to time (i.e. infrequently), once or many many times it is important to detail this information in the user characteristics section and account for this in the software, if the methods used to do something are contrived or confusing it could lead to increased mistakes or data mismanagement further down the line and increase the need for normalization or reconciliation of information.
- User Characteristics should detail the factors that affect each user and provide use cases for each user, it may also be ideal to detail overlapping functions that each user may use and diagram where appropriate.
- It also may be applicable to detail why each user may need a function of the program.
Specific Requirements

The specific requirements should detail all of the requirements of the clients, the user and the software itself. It should provide suitable detail to enable the software to be written clearly and tested effectively. It should be stated for each requirement which user the requirement is for and if applicable that the test case corresponding to the requirement should be satisfied through cross-referencing other parts of the document.
- The requirements should be clearly stated to prevent later mistakes or edge cases, poorly written requirements or poorly designed functions may cause the program to be unstable or possibly unsuitable for use. Proper error handling should be given to most aspects of the programs requirement and how it operates to meet the requirement.
- Vagueness or Failings in test cases may allow for requirements to be deliberately misinterpreted, such as “The program must be fast and easy to use” may be considered easy to use for the programmer or tester, and therefore a suitable statement that the requirement is met, but not for the user who may not understand the inner workings of the software and therefore lack the knowledge to use the software effectively as much as the programmer testing the requirement, it may be a good idea to allow the users to try the functions using agile development and adapting the program accordingly.
The final part of the document should include the appendices and the index.

Exporting GnuCash Data to PowerBi

February 1st, 2019

Some things are better if you do them yourself. I mainly did this project to keep a running ledger of the changes that I would need to keep track of the account balance data.

GnuCash is great, but when I export my accounts data the CSV file isn’t easily translated with power-query automatically. I decided that because I need to keep track of my transactions, this problem was best suited with a little program to calculate my net inflows and outflows using a python program, I also decided halfway through the project that I wanted to hook it up to my graphing backend, a silly idea – but a fun one to see my spends go up and down. I decided that I’d publish it here so that in the future I would find it a lot easier.

Traditionally if you wanted to export GnuCash data from CSV to PowerBi, you’d be better off using their inbuilt power query, however, I wanted to implement a ledger system, something that I don’t think can be accomplished directly in PowerBi without some scripting, and in the future I want to be able to change platforms if I need to because I no longer have a licence for PowerBi or want to use something else like excel or free equivalents like Google Sheets. I reckon that if done properly Google Scripts could make everything run automagically from an upload, but I don’t have my reports ready yet for that to happen.

# Extracted from here https://github.com/aidancrane/GnuCash-CSV2CSV-for-PowerBi/blob/master/convert_to_powerBI.py

import csv
from re import sub
from decimal import Decimal
import time


# If we only want the transactions values, set this to true and they will print to console, they do not save to accounts_out.csv!
numbersOnly = False

# Anyone thats not me will want this to be false, this is used to show the transaction data on a live graph I use for scratching around with.
smoothieChartEmulation = False
sessionCookie = "39494goodluckguessingthispartlololol213232expiresanyway"

# Leave this here so that Notepad++ and Atom auto-suggest it.
# Date,Account Name,Number,Description,Notes,Memo,Category,Type,Action,Reconcile,To With Sym,From With Sym,To Num.,From Num.,To Rate/Price,From Rate/Price

if (smoothieChartEmulation):
     import requests

# Negative Numbers are bracketed when exported from GNUCash so we need to fix that for the float data type.
def convert_if_negative(number):
    returnNumber = str(number)
    if ("," in returnNumber):
        if ("(" in returnNumber):
            returnNumber = returnNumber[1:]
            returnNumber = returnNumber[:-1]
            returnNumber = returnNumber.replace(",", "")
            returnNumber = 0 - round(float(returnNumber), 2)
        returnNumber = str(returnNumber).replace(",", "")
    if ("(" in returnNumber):
        returnNumber = Decimal(sub(r'[^\d.]', '', returnNumber))
        return (0 - round(float(returnNumber), 2))
    return returnNumber

# open accounts.cvs, our exported file.
with open("accounts.csv", "r") as csvIn:
    reader = csv.DictReader(csvIn)
    entries = []

    runningTotal = float(0)
    
	# Save
    for row in reader:
        if (row["Account Name"] == ""):
            pass
        else:
            runningTotal = runningTotal + float(convert_if_negative(row["To Num."]))
            if (numbersOnly):
                print(str(round(runningTotal, 2)))
            else:
                if (smoothieChartEmulation):
                    payload = {'random_graph': runningTotal}
                    r = requests.get('https://dash.infinityflame.co.uk/dash/flex.php', params=payload, cookies={'PHPSESSID': sessionCookie})
                print(str(convert_if_negative(row["To Num."])) + " Description: "+ row["Description"] + " Account Balance: " + str(round(runningTotal, 2)))
                entries.append([row["Date"],row["Description"],row["Category"],str(convert_if_negative(row["To Num."])),str(round(runningTotal, 2))])

# Save what we care about to our new csv for power BI   
with open('accounts_out.csv', mode='w', newline='') as csvOut:
    titles = ["Date","Description","Destination","Transaction","Account Balance"]
    writer = csv.writer(csvOut, delimiter=',', quotechar='"', quoting=csv.QUOTE_MINIMAL)
    writer.writerow(titles)
    for transaction in entries:
        writer.writerow(transaction)

I used python because it’s quick to debug in Atom and I know it well. The way this snippet is used is to export an account from GnuCash, then use this program to output the final CSV to be taken in by PowerBi, I’ve chained these steps together. The final result is stored in accounts_out.csv.

Thanks!

Tag: Software

What is a Software Supply Chain Attack?

Watering Hole Attacks

Software Compromise

Writing a Requirement Specification Document for a Software Project

Introduction

Purpose

Scope

System Overview

References

Overall Description

Product Perspective

Design Constraints

Product Functions

User Characteristics

Specific Requirements

Exporting GnuCash Data to PowerBi