Fuzz testing is a software testing technique that has risen to prominence over the past two decades. The unifying feature of all fuzz testers (fuzzers) is their ability to somehow automatically produce random test cases for software. Fuzzers can generally be placed in one of two classes: black-box or white-box. Blackbox fuzzers do not derive information from a program's source or binary in order to restrict the domain of their generated input while white-box fuzzers do. A tradeoff involved in the choice between blackbox and whitebox fuzzing is the rate at which inputs can be produced; since blackbox fuzzers need not do any "thinking" about the software under test to generate inputs, blackbox fuzzers can generate more inputs per unit time if all other factors are equal. The question of how blackbox and whitebox fuzzing should be used together for ideal economy of software testing has been posed and even speculated about, however, to my knowledge, no publically available study with the intent of characterizing an answer exists. The purpose of this thesis is to provide an initial exploration of the bug-finding characteristics of blackbox and whitebox fuzzers. A blackbox fuzzer is implemented and extended with a concolic execution program to make it whitebox. Both versions of the fuzzer are then used to run tests on some small programs and some parts of a file compression library.

Rapporten behandlar ett examensarbete med fokus på att hitta och jämföra en whiteboxlösningmot en nuvarande nätverksenhet åt företaget Cygate. Whiteboxlösningar är ett växande konceptsom är relativt outforskat och den större delen av nätverksmarknaden domineras fortfarande avetablerade märken. En brist på jämförelser mellan whiteboxslöningar och etablerade märken ären bidragande orsak till denna rapport. Cygate ville veta om det fanns några whiteboxlösningarsom kunde mäta sig prestandamässigt mot en av deras nuvarande enheter. Olikawhiteboxlösningar granskades och analyserades med fokus på porthastighet, antal portar ochstöd för utvalda protokoll. Den teoretiska undersökningen av olika whiteboxlösningar gjordeatt det gick att konstatera att det fanns en whiteboxlösning som levde upp till liknade prestandasom den nuvarande nätverksenheten. Whiteboxlösningen levde upp till de kraven som ställtsfrån Cygate och visade sig vara mer ekonomiskt lönsam och på vissa punkter ha bättreprestanda. Granskningen visar att ett företag kan förbättra sin prestanda och minska sinakostnader genom att implementera en whiteboxlösning.

Inom nätverksbranchen finns en strävan att gå från proprietära lösningar till en öppen standard för hård- och mjukvara. En term för detta är Whiteboxing och det innebär att användaren ges möjlighet att plocka ihop komponenter efter behov, och själv välja vilken mjukvara som används. I sin enklaste form byggs en Whiteboxrouter av en konventionell PC med två nätverkskort och en mjukvarubaserad routingapplikation. Företaget ÅF är intresserade av att veta hur Whitebox-lösningar för routrar står sig prestandamässigt i relation till konventionella routerlösningar med Application Specific Integrated Circuit. Detta arbete har undersökt prestandan genom att mäta throughput och goodput hos en Cisco 2911-router, en Whiteboxrouter med mjukvaran pfSense, samt en Whiteboxrouter som körde pfSense virtualiserat på ESXi. Dessutom undersöktes respektive konfigurations prestanda när trafiken skickades över IPsec VPN. För mätningarna användes filöverföringar med FTP och mätprogrammet Iperf3. Målet med arbetet var att skapa ett beslutsunderlag som klargjorde eventuella prestandaskillnader och utarbetade rekommendationer för framtida val av routerlösning. Resultatet visade att vid generell paketförmedling var prestandan mellan routrarna relativt jämn, dock rekommenderas den virtualiserade Whiteboxroutern då den fick det bästa resultatet. När trafiken sedan krypterades med IPsec VPN var det stora prestandaskillnader mellan enheterna. Bäst prestanda fick Whiteboxroutern. Författaren ser en vinning med Whitebox-tekniken i stort då den medger att serverutrustning som ska utrangeras på grund av prestandakrav, istället kan fungera som nätverksutrustning (routrar och brandväggar) och fortsätta användas under en större del av den tekniska livslängden. Detta kan på sikt leda till minskad miljöpåverkan och besparingar för företaget.

Whitebox cryptography aims at protecting standard cryptographic algorithmsthat execute in attacker-controlled environments. In these, the attacker is ableto read a secret key directly from memory. Common implementations mask alldata at runtime and operate on masked data by using many small precomputedtables. Practical whiteboxes involve trade-offs between security and executionspeed, to limit their footprints and enable applications such as real-time videostreaming.To improve this compromise, we study the use of bitslicing (or bitparallelism)to implement whiteboxes. Bitslicing is commonly used to writefast constant-time implementations of cryptographic algorithms and relies onthe synthesis of boolean circuits implementing the corresponding algorithms.The synthesis of optimal circuits for lookup tables is resource intensive andgenerally only performed once. In a whitebox context however, many randomlookup tables are generated at compile-time. We therefore require the booleancircuit generation to be time efficient.In this master thesis, we review the existing circuit-synthesis algorithms,and analyse their usability in the whitebox context. In particular, we studythe technique of Binary Decision Diagrams to generate efficient circuits ina cheap and adaptable manner. We implemented a flexible version of thisalgorithm as a C++ library. Eventually, we go through different techniques toevaluate the generated circuits and analyse the performances of our algorithm,and recommand the best parameters for the whitebox context. / Vit-låda kryptografi syftar till att skydda kryptografiska standardalgoritmersom körs i miljöer som kontrolleras av angripare, där angriparen kan läsa enhemlig nyckel direkt från minnet. Vanliga tillämpningar maskerar alla data vidkörning och bearbetar maskerade data med hjälp av många små förberäknadetabeller. Praktiska vit-låda innebär att man måste göra avvägningar mellansäkerhet och exekveringshastighet, för att begränsa deras fotavtryck och möjliggöratillämpningar som till exempel videoströmning i realtid.För att förbättra denna kompromiss studerar vi användningen av bitslicing(eller bit-parallelism) för att genomföra vit-låda. Bitslicing används vanligenför att skriva snabba konstanttidsimplementationer av kryptografiska algoritmeroch kräver syntes av boolska kretsar som implementerar motsvarande funktioner.Syntesen av optimala kretsar för uppslagstabeller är resurskrävande och utförsi allmänhet bara en gång. I ett vit-låda-sammanhang genereras dock mångaslumpmässiga uppslagstabeller vid kompilering, och därför kräver vi attgenereringen av boolska kretsar är tidseffektiv.I denna masteruppsats går vi igenom de befintliga algoritmerna för kretssyntesoch analyserar deras användbarhet i vit-låda-sammanhang. Vi studerar särskilttekniken med binära beslutsdiagram för att generera effektiva kretsar på ettbilligt och anpassningsbart sätt. Vi har implementerat en flexibel version avdenna algoritm som ett C++-bibliotek. Slutligen går vi igenom olika teknikerför att utvärdera de genererade kretsarna och analysera vår algoritms prestandaoch rekommenderar de bästa parametrarna för whitebox-kontexten. / La cryptographie en boîte blanche est connue comme protection pour desalgorithmes cryptographiques s’exécutant dans des environnements contrôléspar l’attaquant. L’approche classique consiste à remplacer les opérations pardes accès à des tables précalculées, ce qui a un coût en performance. Il estdifficile d’obtenir un bon compromis entre sécurité et vitesse d’exécution pourdes applications lourdes telles que la diffusion de contenus vidéos en tempsréel.Le parallélisme au bit ou bitslicing est utilisé en cryptographie traditionnellepour accélérer les implémentations, mais aussi en boîte blanche. Cettetechnique d’implémentation demande la synthèse d’un circuit booléen pourchaque table, recherche qui peut être très coûteuse en temps. En pratique, ilest commun de regénérer régulièrement toutes les tables utilisées dans uneboîte blanche pour renouveler sa défense, ce qui complique l’application dubit-parallélisme.Nous présentons dans cette thèse de master notre effort pour une synthèseefficace de circuits booléens à l’usage de la compilation de boîtes blanchesparallèles au bit. Nous publierons avec cet article une bibliothèque C++ etun module de compilation LLVM pour l’écriture d’implémentation bitslicée,avec un objectif de performance et de lisibilité.

<p>Att genomföra ett penetrationstest av en nätverksarkitektur är komplicerat, riskfyllt och omfattande. Denna rapport utforskar hur en konsult bäst genomför ett internt penetrationstest tidseffektivt, utan att utelämna viktiga delar. I ett internt penetrationstest får konsulten ofta ta del av systemdokumentation för att skaffa sig en bild av nätverksarkitekturen, på så sätt elimineras den tid det tar att kartlägga hela nätverket manuellt. Detta medför även att eventuella anomalier i systemdokumentationen kan identifieras. Kommunikation med driftansvariga under testets gång minskar risken för missförstånd och systemkrascher. Om allvarliga sårbarheter identifieras meddelas driftpersonalen omgå-ende. Ett annat sätt att effektivisera testet är att skippa tidskrävande uppgifter som kommer att lyckas förr eller senare, t.ex. lösenordsknäckning, och istället påpeka att orsaken till sårbarheten är att angriparen har möjlighet att testa lösenord obegränsat antal gånger. Därutöver är det lämpligt att simulera vissa attacker som annars kan störa produktionen om testet genomförs i en driftsatt miljö.</p><p>Resultatet av rapporten är en checklista som kan tolkas som en generell metodik för hur ett internt penetrationstest kan genomföras. Checklistans syfte är att underlätta vid genomförande av ett test. Processen består av sju steg: förberedelse och planering, in-formationsinsamling, sårbarhetsdetektering och analys, rättighetseskalering, penetrationstest samt summering och rapportering.</p> / <p>A network architecture penetration test is complicated, full of risks and extensive. This report explores how a consultant carries it out in the most time effective way, without overlook important parts. In an internal penetration test the consultant are often allowed to view the system documentation of the network architecture, which saves a lot of time since no total host discovery is needed. This is also good for discovering anomalies in the system documentation. Communication with system administrators during the test minimizes the risk of misunderstanding and system crashes. If serious vulnerabilities are discovered, the system administrators have to be informed immediately. Another way to make the test more effective is to skip time consuming tasks which will succeed sooner or later, e.g. password cracking, instead; point out that the reason of the vulnerability is the ability to brute force the password. It is also appropriate to simulate attacks which otherwise could infect the production of the organization.</p><p>The result of the report is a checklist by means of a general methodology of how in-ternal penetration tests could be implemented. The purpose of the checklist is to make it easier to do internal penetration tests. The process is divided in seven steps: Planning, information gathering, vulnerability detection and analysis, privilege escalation, pene-tration test and final reporting.</p>

Att genomföra ett penetrationstest av en nätverksarkitektur är komplicerat, riskfyllt och omfattande. Denna rapport utforskar hur en konsult bäst genomför ett internt penetrationstest tidseffektivt, utan att utelämna viktiga delar. I ett internt penetrationstest får konsulten ofta ta del av systemdokumentation för att skaffa sig en bild av nätverksarkitekturen, på så sätt elimineras den tid det tar att kartlägga hela nätverket manuellt. Detta medför även att eventuella anomalier i systemdokumentationen kan identifieras. Kommunikation med driftansvariga under testets gång minskar risken för missförstånd och systemkrascher. Om allvarliga sårbarheter identifieras meddelas driftpersonalen omgå-ende. Ett annat sätt att effektivisera testet är att skippa tidskrävande uppgifter som kommer att lyckas förr eller senare, t.ex. lösenordsknäckning, och istället påpeka att orsaken till sårbarheten är att angriparen har möjlighet att testa lösenord obegränsat antal gånger. Därutöver är det lämpligt att simulera vissa attacker som annars kan störa produktionen om testet genomförs i en driftsatt miljö. Resultatet av rapporten är en checklista som kan tolkas som en generell metodik för hur ett internt penetrationstest kan genomföras. Checklistans syfte är att underlätta vid genomförande av ett test. Processen består av sju steg: förberedelse och planering, in-formationsinsamling, sårbarhetsdetektering och analys, rättighetseskalering, penetrationstest samt summering och rapportering. / A network architecture penetration test is complicated, full of risks and extensive. This report explores how a consultant carries it out in the most time effective way, without overlook important parts. In an internal penetration test the consultant are often allowed to view the system documentation of the network architecture, which saves a lot of time since no total host discovery is needed. This is also good for discovering anomalies in the system documentation. Communication with system administrators during the test minimizes the risk of misunderstanding and system crashes. If serious vulnerabilities are discovered, the system administrators have to be informed immediately. Another way to make the test more effective is to skip time consuming tasks which will succeed sooner or later, e.g. password cracking, instead; point out that the reason of the vulnerability is the ability to brute force the password. It is also appropriate to simulate attacks which otherwise could infect the production of the organization. The result of the report is a checklist by means of a general methodology of how in-ternal penetration tests could be implemented. The purpose of the checklist is to make it easier to do internal penetration tests. The process is divided in seven steps: Planning, information gathering, vulnerability detection and analysis, privilege escalation, pene-tration test and final reporting.