Author Archives: Felix

How we got our name….

Choosing the name of your child is hard. Arguably, selecting the name of your business is harder.

When I was choosing the name of the company, I knew a few things. I knew I wanted it to be cool. I knew it needed to have a kickass domain name. And I also knew that everything I thought of was already taken.

So like any other proudly geeky person, I set about programming my way through the problem. I wrote a little script that tested to see what domain names were available for every possible combination of Domain. I started with all the known TLDs (Top-Level Domains such as .com) and then the script added characters to the front. I ended up with a reasonably long list of possible domains, and I needed to narrow it down. My next step was to take the Domains I had identified and gather a screenshot of the first page of Google when searching for each of them. I was looking for inspiration. When I searched for YGHT, I spotted an article in the Urban Dictionary titled “You Gotta Hit That”. I instantly knew the name of my company and how I would brand it: “You Gotta Hack That”.

Something inexplicable happened along the way, possibly caused by my inner nerd, and I stook with the shortened version of the company name: YGHT. For several years using YGHT has been fine, but, it is more and more evident that on its own this only means things to those of us in the company.

We are now relaunching ourselves with the full version of our name, “You Gotta Hack That” but we won’t be losing our favourite short domain name…

Athom Homey Security Review | Transmits unencrypted WiFi credentials (CVE-2020-9462)


TL;DR: All Athom Homey and Athom Homey Pro devices, up to the current version (v4.2.0) transmit their initial configuration in the clear which includes your WiFi password. At the time of writing, Athom have no plans to fix this.


I will preface this with the fact that this vulnerability is not the most exciting in history, however, it is a vulnerability and the company should be doing better. The Athom Homey device is a smart-hub and can connect with other devices using a lot of different protocols.

In principle, the device is great as it means you should only have one place to orchestrate your smart home.

Despite it’s flaws, I actually really like this device.

Essentially, when setting up the device it has to connect to your WiFi network. The device has no exposed Ethernet port which is a shame, but, on the most part, this doesn’t seem to be a problem.

Athom Homey Security Vulnerability

The vulnerability only exists when going through the setup routine. The vulnerability exists because the device creates a temporary WiFi hotspot that is unencrypted which the user must connect to in order to perform the initial configuration. Crucially this means that when you configure the devices WiFi connection, you send the WiFi password in an unencrypted link to the device.

I sent Athom an email which contained the following:

The security vulnerability I wish to report to you today is the fact
that during sign up, your devices receive the WiFi security key without
being protected by any form of encryption. This means that an attacker
who is physically within range would be able to receive a copy of the
encryption key and therefore be able to gain unauthorised access to the
victim’s WiFi network. This is the same vulnerability that Amazon’s Ring
Doorbell made international news about in November 2019:

Read more about ring doorbell WiFi vulnerability

Which got the following response:

Thank you for your effort and letting us know your findings!

We are aware of the security risk involved in sending the credentials in plain text during setup of Homey.

We have made the decision back when this feature has been designed that while the process is in theory insecure, in practice it has a very low risk attack vector. In fact, there are many smart devices that use a similar way to set-up said devices.

Because the user must manually enable Wi-Fi Setup on Homey by turning it physically upside down, and another hacker must be present at the same time with equipment that’s not available to most, we have decided to focus our security efforts on more pressing matters. I am happy to say that 3rd party penetration tests have been performed on Homey and no one was able to gain access.

On a technical note, there is no secure way to set-up devices over a Wi-Fi hotspot without an out-of-band key. Homey does not have this printed in a manual, sticker etc. so we cannot simply issue an update. All other mechanisms are by definition unsafe because they rely on a shared secret, which is always crackable for any determined hacker.

We take the security and privacy of our users very seriously.

Not a bad response, though it got me to thinking…

It is true that other devices use a similar WiFi configuration routine, but, as demonstrated by Amazon’s Ring, it isn’t considered good enough on those devices either. It is also true that devices using completely different protocols, such as ZigBee, also have a similar type of key-exchange flaw. Again, it isn’t considered good enough here either.

I also don’t think it is fair to suggest that this configuration process only happens once. I’ve had this device for a while and I use it a fair bit and during that time I have ended up having to reset it and reconfigure it.

Nevermind that, but, it doesn’t take much to realise that an attacker could easily create a circumstance that would encourage the victim user to start this reconfiguration process even when it wasn’t needed.

So I sent them another email:

Thank you for your response an, but I respectfully disagree.

There are methods in a closed ecosystem to perform key exchange. For example, the software on the Homey could be instructed to use knowledge of an Athom internal Root Certificate Authority to perform Homey to Smart-phone authentication, and the user’s smart-phone could be issued with an identity that is cryptographically derived from Athom’s internal CA and as such can be trusted by the device.

This then provides encrypted comms between Homey and the Smart phone which is already a big step-up. In theory though, this could be subjected to a Man-in-the-Middle attack. For example, where another user with a legitimate certificate could trick the victim Homey and the victim smart-phone into communicating with the attacker. To prevent this circumstance it would be best to have mutual authentication, but that is very difficult to achieve with devices that have already been deployed. There is a solution though – either Diffie Hellman key exchange (DH KX) which reveals an active attacker the moment they stop intercepting communications, or a variant of DH KX called STS (Station to Station)…

Furthermore, the Homey does have the ability to perform out of band key validation – amongst other methods, it speaks! This would allow key exchange and validation to be completed in the same manner as Bluetooth key exchange is completed with a PIN number.

I’m also worried about your analysis of the risk involved – just because this only happens during setup and that there must be user interaction does not make it immune to problems. For example, it is perfectly possible for an active attacker within RF range to perform a de-authentication attack against the device until the user chooses to reset it. Granted that when calculating its CVSS, having user interaction does reduce the score, but, I would suggest the result is still relatively high at approximately 5.0, with a vector of CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. This is owing to the ability of the attacker to not only intercept the communications which reveals the WiFi network key that in turn changes the scope of the attack, but also, because there is also the possibility of an integrity issue, such that at attacker could get the Homey device to connect to a malicious WiFi network and thus be able to perform other attacks against the device.

And finally, I don’t consider your assertion that “other people do this too” an adequate defence to your own lack of security. Just because it is done elsewhere does not make it right.

Please reconsider your position. I would be delighted to be of further help.

They were gracious enough to send me another response:

I do agree with some of the points you make, however, at this time we do not have the capacity to change Homey’s behavior during Wi-Fi setup. While you are technically right, we deem the attack vector to be small enough to be acceptable.

In any future products we will consider your findings.

As of this date, no fix for this is in place which is disappointing. You can find The official CVE for this issue by clicking here:

Learn how YGHT can help you imrpove your cybersecurity

JavaScript Event Handlers a complete list

Before we provide you with the JavaScript Event Handlers list, we should answer some questions for our non-techie friends. Questions like, What is JavaScript Event Handlers? What is an event?

For those readers that know what JavaScript Event Handler is, feel free to use the list.

Introduction to JavaScript Event Handling

What is an Event?

Events are actions in a system that you are programming. Events are used in programming to make more user-friendly websites for visitors. For example, when a user presses a button on a webpage an action happens. If you press the Services word you will get to a different webpage, this is an action.

YGHT also uses JavaScript Event Handlers in web application penetration tests for our clients. If you want to learn more about how we engage in Penetration tests, book a 15-minute appointment.

What is Event Handling?

Event Handling is the procedure that decides what the action of the event should be when the user interacts with the website. The code that triggers when the Event occurs is known as Event Handling.

JavaScript uses the Delegation Event Model to define standards and mechanisms to process events. The Delegation Event Model used by JavaScript includes the following two key contributors:

  • Source: The source is an element on which event takes place. The source is in charge of providing data of the event to its handler.
  • Listener: Is responsible for producing a response to an event. The listener will wait to receive an event. When the event is sent to the listener, firstly it processes it and then returns.

This is just a list of the event handlers that are available in JavaScript. I commonly find web applications that prevent the creation of script tags and some even prevent common JS event handlers for “in-tag” injection. There are quite a few of these including some obscure ones and depending on the method of detection, not all will get caught. There are plenty of resources which include these event handlers, but I couldn’t find a singular list. So here is mine:

  • onclick
  • ondblclick
  • onmousedown
  • onmouseup
  • onmouseover
  • onmousemove
  • onmouseout
  • ondragstart
  • ondrag
  • ondragenter
  • ondragleave
  • ondragover
  • ondrop
  • ondragend
  • onkeydown
  • onkeypress
  • onkeyup
  • onload
  • onunload
  • onabort
  • onerror
  • onresize
  • onscroll
  • onselect
  • onchange
  • onsubmit
  • onreset
  • onfocus
  • onblur
  • onpointerdown
  • onpointerup
  • onpointercancel
  • onpointermove
  • onpointerover
  • onpointerout
  • onpointerenter
  • onpointerleave
  • ongotpointercapture
  • onlostpointercapture
  • oncut
  • oncopy
  • onpaste
  • onbeforecut
  • onbeforecopy
  • onbeforepaste
  • onafterupdate
  • onbeforeupdate
  • oncellchange
  • ondataavailable
  • ondatasetchanged
  • ondatasetcomplete
  • onerrorupdate
  • onrowenter
  • onrowexit
  • onrowsdelete
  • onrowinserted
  • oncontextmenu
  • ondrag
  • ondragstart
  • ondragenter
  • ondragover
  • ondragleave
  • ondragend
  • ondrop
  • onselectstart
  • onhelp
  • onbeforeunload
  • onstop
  • onbeforeeditfocus
  • onstart
  • onfinish
  • onbounce
  • onbeforeprint
  • onafterprint
  • onpropertychange
  • onfilterchange
  • onreadystatechange
  • onlosecapture
  • DOMMouseScroll
  • ondragdrop
  • ondragenter
  • ondragexit
  • ondraggesture
  • ondragover
  • onclose
  • oncommand
  • oninput
  • DOMMenuItemActive
  • DOMMenuItemInactive
  • oncontextmenu
  • onoverflow
  • onoverflowchanged
  • onunderflow
  • onpopuphidden
  • onpopuphiding
  • onpopupshowing
  • onpopupshown
  • onbroadcast
  • oncommandupdate