Title: Recycling wargames/ctf challenges into papers and Blackhat talks Date: 2018-09-17 20:00 There is a trend in recycling challenges from various CTF or wargames into either papers or talks at security conferences like [Blackhat]( https://blackhat.com/ ), without giving any form of credits at all. It doesn't mean that those papers are necessarily bad nor uninteresting, simply that it's discouraging and frustrating to see people taking credit, inadvertently or not, for the work of others. The latest in date was the talk from [Sam Thomas](https://twitter.com/_s_n_t), [It's a PHP Unserialization Vulnerability Jim, but Not as We Know It]( https://github.com/s-n-t/presentations/blob/master/us-18-Thomas-It's-A-PHP-Unserialization-Vulnerability-Jim-But-Not-As-We-Know-It.pdf ) at the Blackhat USA 2018, presenting `phar://`-base unserialization as a "novel attack technique". This technique was the expected (and documented) solution to solve [Orange](http://blog.orange.tw/)'s (amazing as usual) [baby^h master php](https://github.com/orangetw/My-CTF-Web-Challenges#babyh-master-php-2017) challenge of the HITCON CTF 2017. It was also discussed a bit further on [rdot.org](https://rdot.org/forum/showpost.php?p=43331). The [Web Cache Deception Attack](https://drive.google.com/file/d/0BxuNjp5J7XUIdkotUm5Jem5IZUk/view) talk by [Omer Gil](https://twitter.com/omer_gil) presented at Blackhat US 2017 presented web cache abuse/poisoning as a "new web attack vector", while it was publicly documented by several people, since at least [2004](https://dl.packetstormsecurity.net/papers/general/whitepaper_httpresponse.pdf). [Hector Marco](http://hmarco.org/) is known to recycle things on a regular basis: His [Glibc Pointer guarding weakness]( http://hmarco.org/bugs/glibc_ptr_mangle_weakness.html ) disclosed the 5th of September, 2015 was [publicly documented]( https://hacktracking.blogspot.com/2013/06/utumno-wargame-level-7.html) as a solution to one of Over the Wire's wargame: [Utumno](http://overthewire.org/wargames/utumno/), since 2013, and part of the [State Threads Library documentation]( https://web.archive.org/web/20100218204147/http://state-threads.sourceforge.net:80/docs/notes.html)'s since 2010. It was also mentioned in the Doctoral Dissertation of *Željko Vrba*, [Implementation and performance aspects of Kahn process networks](http://home.ifi.uio.no/paalh/students/ZeljkoVrba.pdf), publshed in July 2009, on page 52: > New linux C libraries make the jmp_buf structure truly opaque by xor-ing the contents with a perthread random constant. This could be probably disabled by the undocumented `LD_POINTER_GUARD` environment variable on some Linux versions. The oldest public trace that I found about this bypass is from the 20th of October, 2006, on yupo5656's article [最近のglibcではatexit関数やjmp_bufを狙った攻撃は効かない (PTR_MANGLE](http://d.hatena.ne.jp/yupo5656/20060820) ("Attacks targeting `atexit` and `jmp_buf` aren't very effective anymore against recent versions of glibc" in English). Marco also gave [a talk](https://www.blackhat.com/docs/asia-18/asia-18-Marco-return-to-csu-a-new-method-to-bypass-the-64-bit-Linux-ASLR-wp.pdf) at Blackhat Asia 2018 entitled "return-to-csu: A New Method to Bypass 64-bit Linux ASLR". The title is misleading, it's about an universal gadget in constructors of ELF binareys (`__libc_csu_init`), documented in 2013 by [voidsecurity](https://v0ids3curity.blogspot.com/2013/07/some-gadget-sequence-for-x8664-rop.html) and in 2014 on [inaz2's blog](http://inaz2.hatenablog.com/entry/2014/07/31/010158). Finally, the infamous [offset2lib]( https://cybersecurity.upv.es/solutions/aslr-ng/ASLRNG-BH-white-paper.pdf) technique, presented at Blackhat Asia 2018, about the fact that you can bruteforce ASLR in case of a forking service to find the pointer to the previous stackframe, infer the base address and then use the constant offset between libraries to find where the libc is mapped. This is public knowledge since years, but the paper only has 7 references, with 4 of them authored by the author himself, and the others aren't specific to the paper's topic. And the list goes on and on… It's worrying to see that those talks/papers are reviewed and accepted at high-profile conferences, normalizing this kind of behaviour, while they should instead get comments pointing at the lack of citations, when not be straightly reject in some pathological cases. ## *edit* As pointed by [albinowax](https://skeletonscribe.net/), Thomas later [acknowledged]( https://www.youtube.com/watch?v=GePBmsNJw6Y&feature=youtu.be&t=2729 ) Orange Tsai's challenge at BSides Manchester, and Orange [knew](https://twitter.com/orange_8361/status/1029978797322293248) about Thomas' research. [Omer Gil](https://omergil.blogspot.com/), the author of the *Web Cache Deception Attack* paper [pointed](https://twitter.com/omer_gil/status/1042384177243611136) that "the paragraph stating that the web cache deception technique was "publicly documented by several people, since at least 2004", while giving reference to web cache poisoning, which is just... not the same technique at all." I would argue that it's a variant of cache poisoning, only the other way around: the victim is putting things in the cache that shouldn't be there, instead of the attacker. If I wanted to be picky, it would actually be a variant of caching sensitive pages, due to code issues, instead of the *classic* configuration issue. I wouldn't name it a "new web attack vector", but I understand why others might, albeit even in the case, citations are [still missing](https://www.blackhat.com/docs/us-17/wednesday/us-17-Gil-Web-Cache-Deception-Attack-wp.pdf). This blogpost generated some heat on twitter, so I feel like I need to clarify its purpose: I didn't want to discourage researchers from publishing new papers, nor to (as it's often the case on the internet) fire some free derisive shots at people who are doing their best to find and present interesting results. I only want to highlight that the computer security community should have better standards in regard to citations. I didn't want to imply that all the papers linked in this article are necessarily bad, nor that all they respective authors acted in bad faith.