Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

I thought it was interesting that the authorset a goal in his endeavors (which was getting free articles).

The main idea was that the first 3 free medium articles are free. So, can we make the Medium website feel like the first time that it has been accessed?

After developing a place, the APK (android app file) was decompiled in order to get the source code. The author made a modification to not send cookies to /_/api/posts/{postId}.

However, making changes to the source code of an APK cannot be done at the Java level; it has to be done at the Smalli level. Once adding these lines to the source code, re-ziping the APK and signing it, the APK is now ready to be used!

Altering APKs is not as complicated as one would think :)

IoT security is terrible some of the time... This is a really good example of that.

The WiFi network, being made by the camera, is unprotected with no way to set the password. This allows anyone who is close by to simply view the stream of the camera.

When decompiling the app they noticed that the cameras had no authentication and there was some hidden functionality! The author mentions that some of the hidden functionality was likely for a drone specific API that just was not taken out (interesting!).

Blind remote code execution! However, the trick is that only 19 characters, at the most are allowed. The author claims that this is essentially unexploitable but I feel that someone could come up with a solution :)

The people at 0patch will create patches for zero day exploits then release them to the world. In the article, they explain the vulnerability, how they reverse engineered the exploit to find the bug and then how they fixed it.

These people are amazing and code great research :)

Essentially, the SchRpcSetSecurity function has an impersonation feature. This feature acts as the Local System user to make changes to files and does not validate the actual permissions of the current user.

All the fix took was 4 assembly instructions!

The JIT (Just-in-time) compiler allows for JavaScript code, within the web browser, to produce high-performance code. Chakra, the JavaScript engine, makes assumptions all over the place when trying to make optimizations, that can exploitable features.

By abusing assumptions made on optimizations, the code has now became exploitable.

The assumption: an array cannot change types just from being accessed.
Reality: If a floating point value contains the same internal representation as 'undefined' ( 0x8000000280000002) then the array is converted into a JavaScriptArray class.

Because of the assumption being made, a floating-point value can be put into JavaScriptArray and avoids the JIT type check... Accessing a[0] will then crash the browser, if accessed.

Lateral movement using trusted SSL Certificates in internal networks.

Using HTTPS, the anti virus software cannot read the information going across the network. Additionally, using HTTPs, instead of DNS, SMB or something else to communicate, does not follow common attacker heuristics.

Why was a priv esc in the researchers mind? In his words:

1. As a user, I could communicate with the CylanceSvc service and influences its behavior.
2. As a user, I could trigger the CyUpdate process to spawn with SYSTEM privileges.
3. As a user, I could cause the CylanceUI process to write to the same file/folder as the SYSTEM process.

By using some symbolic link black magic, pioneered by James Forshaw, the file name could be easily controlled.

With the ability to write to any file location with any file content, a DLL injection was used in order to compromise the system.

I really enjoyed the threat model that Ryan laid out in this research; gives me an insight into doing priv esc research! :)

A file was being read directly from the OS, looking something like /file.jpeg.

Instead of putting just the file name, the researcher added "../../../../etc/passwd", which leaked all of the login information of the system.

To turn this into an RCE, the file traversal could also be paired with a write function, instead of a read function. By being able to write anywhere on the system, an RCE had been created!

The CPU optimization created a double fetch, of the same memory location... This does not seem like a big deal! But, a value can be verified as correct, then changed when actually used! This is known as a TOCTOU (time of check vs time of use).

The article claims to be that the vulnerability is caused by the variable not being set to volatile. However, my understanding of volatile is that the value should be regathered frequently, because the value could be changed out of band or something like that.

After not understanding what this flag on a variable meant, I found a great article explaining it all at barrgroup.

Quote to some up the reason for going down this attack vector: "When a privilged service writes to a user owned resource, it opens up the possibility of s symlink (vuln)...".

Used dnSpy to open up the C# binaries to get full source code recovery. That's a really nice thing to have! Another useful tool was procmon, which shows the running processes in Windows.

With an arbitrary file write with some Windows file black magic, they were able to take over the computer.

Why did this happen? Impersonation features are really hard to get right! Either don't do them or really test that they are done correctly.

By exploiting a simple IDOR (indirect object reference) it was trivial to create a post within a different group. However, the current users group id had to be used with a victim post? I thought this was really odd.

To me, the weirdest part was that a similar bug was found on Facebook and fixed! However, it was on a different part of the site...