Yesterday I gave a talk for an Italian workshop on CTFs. The audience was ~200 Italian students at the beginning of their journey into CTFs / infosec / tech careers (~18-24 years old). These are very busy times, but I don't have the chance to reach many young students so often. And so, I took it :-)
Instead of a classic tech talk, I used this occasion to annoy them with "wisdom" accumulated over the last 10 years (!) of being part, in one way or another, of the infosec community.
The news is out: I left France, I'm no longer a professor at EURECOM, I joined the Malware Research Team at CISCO Talos, and I moved to beautiful Vienna. Big change :-)
I have been a professor for a bit more than three years, but I have had conflicted feelings about the "prof job" for a long time (even before finishing my PhD), it took me a couple of years to realize that I would eventually have needed to move on, and it took even more (mental) effort to actually make the call and leave. Despite being very excited for what's next, oh boy, this was tough :-) But independent of the concrete next step, it was time to move on. Even if Talos realizes the mistake and kicks me out next week, I'm still confident that moving on was the right call.
Last week, an article by @campuscodi ZDNet caught my eye. The headline is: "Google could have fixed 2FA code-stealing flaw in Authenticator app years ago". The article refers to a blog post by NightWatch Cybersecurity.
This caught my eyes for two reasons: to the best of my knowledge, 1) protecting from a11y is not that easy (it's definitively not just a matter of adding one flag); 2) the article mentions that FLAG_SECURE could be used for this purpose.
This is a quick blog post discussing aoool, a challenge/service I wrote for DEFCON CTF Finals 2019 (co-hosted with the OOO team).
In short, aoool is a C++ web server with support for a custom nginx-like config and support for OSL, the OOO Scripting Language, a (simple) JITted language written from scratch.
Depending on the configuration, the server would interpret a given file as raw text or as osl. When interpreted as raw text, the server would just return the file to the user as-is. When interpreted as osl, instead, the server would actually JIT the OSL script (that is, it would convert OSL textual representation to machine code) and execute it.
In the last couple of days, many reports (see XDA developers, The Hacker News) appeared about Google emailing apps developers about new restriction affecting the Android accessibility service (a11y, in short). The gist: in 30 days, apps should use a11y only to implement features to assist users with disabilities; Apps misusing a11y (even for benign purposes) will get kicked out from the store.
I am one of the many researchers that showed how a11y poses severe issues for Android security. I did it by showing how you could mount a number of devastating attacks, and other researchers recently found real-world malware abusing them (see Zimperium's post on Clicking Bot Apps, or TrendMicro's post on a11y abuse).
This is a write-up for the 0ctf 2016 quals "State of the ART" mobile/Android challenge worth 5 points. We (Shellphish) were one of the only three teams that solved it, and since I haven't seen any write-up on this, here is mine! Major props to @_antonio_bc_ and @subwire who heavily worked on this with me :)
Alright, here is the challenge. We were given one tar containing three files:
mmaps of a process running an Android app
output of dex2oat command run over the Android app's Dalvik bytecode
boot.oat
In recent Android versions, an app's Dalvik bytecode is converted into an OAT file (an ELF binary file) when the app is first installed. dex2oat is the program in charge of this process. More information on the OAT format can be found here. The boot.oat file is the OAT related to the main components of the Android framework.
This is the write-up for solving "pcapin", a challenge from CSAW CTF 2015. It was in the "forensic" category, and it was worth it 150 points....may I say, 150 points my ass!?! This felt like a 1337 points challenge...at least :D
So, we have a pcap (links to all files at the end of the post), and we know that it contains the dump of some sort of file transfer protocol, and that a "not so sophisticated" encryption was used.
This write-up will describe the "behind the scene" of DexWare, a service I wrote for the iCTF 2013. To the best of my knowledge, this is the first service in the history of CTFs to be based on Dalvik-bytecode!! I hope this write-up will be a useful starting point for those who will attempt something similar!
You can find the source code and the compiled binaries on github (link). Also, feel free to ping me on twitter (@reyammer) for any questions.
For those who haven't read the first blog post, ShellNoob is a shellcode writing toolkit that helps you dealing with the boring, error-prone, and painful steps, leaving only the fun part to you! At least that's the goal :)
From when I published the first version (exactly three months ago!) a lot of stuff happened. First, I'll be lucky enough to have a chance to give a demo and to present ShellNoob at Black Hat USA Arsenal! Here is the announcement/abstract: https://www.blackhat.com/us-13/arsenal.html#Fratantonio. Second, a shitton of new features got added!
This is my write-up for the Defcon CTF Quals 2013 - \xff\xe4\xcc 5 (lena). I partecipated to the quals with the Shellphish team (we ended up in 7th place!), and I needed to spend an entire night with the great @cavedon (one of the Shellphish's secret weapon) to solve this challenge. Also, we probably wouldn't have made it without @adamdoupe, that monitored our health conditions when we were trying to finalize our exploit, during the following morning. Needless to say, solving this was not easy (only 8 teams solved it!), but it was definitively super-fun and one of the best CTF challenges I've played with so far.
What if an unprivileged Android app could lock, instantaneously, any Android device out there? What if such an app exists and is also really simple to implement?
A few months ago, Antonio and I stumbled upon a paper titled Would You Mind Forking This Process? A Denial of Service attack on Android. In this paper, the authors describe a vulnerability they discovered related to Android's Zygote that could be exploited by mounting a DoS (Denial-of-Service) attack: this resulted in the target device becoming completely unresponsive after a minute or so. Without going too much into the details, the vulnerability was due to the world-writable permission access to the Zygote's socket, from which Zygote itself listens for "requests to fork new processes". With this technique, they were able to make Zygote fork a high number of processes, and that was enough to block the device.
Today I'm really happy to publicly release ShellNoob (and to publish my first blog post :-))
During the many CTFs I played, there always has been the need to manually write some shellcode (yep, most of time Metasploit is not enough, even if you are lucky and you get a working shellcode...)
Now, writing shellcode is always super fun, but some parts are extremely boring and error prone. And after googling for the n-th time "how to ", I just got tired and I wrote shellnoob.py, a simple Python script that makes some boring steps less boring.