Starting this post by admitting it took me a lot longer to get the answers to some of these questions than it should have, because I misunderstood some of the wording of the questions. I ended up going down a lot of RFC-related rabbitholes, only to find that certain parts were theoretical and others practical. Well, we all make mistakes, onto the post!

If you'd like to play along, the challenge has been archived here

Question 1

You have been asked to examine an IMAP mailbox. You will be interfacing with the Yahoo! Mail IMAP server directly.

Before you start, you need to verify the public key reported by Yahoo’s IMAP server. Enter the last 28 bytes of the server’s public key—excluding the post-encapsulation boundary and any line breaks.

To examine the IMAP mailbox for Yahoo mail we first have to find its details. To do that, we can see from this site that the URL is imap.mail.yahoo.com and port is 993. The site also says that access requires SSL.

A bit more Googling led me here, which gave me the correct command. I’m not sure what the correct command is on Windows environments, but I’m using a Mac so this worked for me.

openssl s_client -connect imap.mail.yahoo.com:993

This one took me a while to figure out because of the phrasing of the question. I used CyberChef to decode the Bas64 x509 certificate, which supplied a few different hex values, none of which were right. This was slightly confusing because the question asked specifically for “bytes” instead of characters.

I also converted the certificates base64 to hex, and tried that as an answer. That wasn’t right either. Probably a few other things as well, with no success.

Eventually, I took the last 28 characters of the base64 encoded data (basically the last line before the “end certificate” line (including the ==) and that was the correct answer.

Question 2

The server welcomes you with the following message:

* OK [CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=XOAUTH2 AUTH=OAUTHBEARER ID MOVE NAMESPACE XYMHIGHESTMODSEQ UIDPLUS LITERAL+ CHILDREN X-MSG-EXT OBJECTID] IMAP4rev1 Hello

You are given the following credentials:
Login: metaspikectf@yahoo.com
App Password: asdh1391ho1h2

Enter the IMAP command you would use to log in.

Note: The credentials above can only be used in the CTF environment and are not valid to authenticate with Yahoo.

So that last line, probably should have really focused in on that one. For some reason I thought that meant that I couldn’t login using the credentials through the Yahoo mail web interface, but could do so through IMAP commands. This led me down the path of looking into various RFCs related to IMAP, SASL-IR, OAUTH, and others with no success, because, the credentials didn’t work, as it says, right in the question. Moving on…

The answer was simply:

A login metaspikectf@yahoo.com asdh1391ho1h2

I made two mistakes; the first one thinking that the credentials would work and that I could test them before submitting the answer. The second being that I saw “oauth” and “app password” in the question and thought that I needed to follow the RFCs related to oauth and xoauthbearer despite not being given a oauth token. It involved writing some different Python scripts to generate the text command required to login but, of course, my credentials were wrong.

Moving on.

Question 3

The IMAP server responds back with the following:

A01 OK LOGIN completed

Enter the command you would use to select the mail folder named documents in a read-only manner.

Knowing now that I don’t need to actually login to the IMAP server made this question a bit easier. (I still created a test account to login, but more on that in the next question).

Googling around allowed me to find these two useful reference documents by atmail and a blog whose author was just hard enough to identify that I didn’t do it. Either way, thank you blogger because you gave me the command I needed:

a examine documents

The reason that we’re using the “examine” command instead of “select” is that we want to open the documents folder as read-only.

Question 4

The server responds as follows:
* 147 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1544554554] UIDs valid
* OK [UIDNEXT 40794] Predicted next UID
* FLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded $Junk $NotJunk)
* OK [PERMANENTFLAGS ()] No permanent flags permitted
* OK [HIGHESTMODSEQ 1410]
* OK [MAILBOXID (6)] Ok

A02 OK [READ-ONLY] EXAMINE completed; now in selected state

Enter the command you would issue to get a list of only the UID and INTERNALDATE values of all the items in this folder.

I mentioned that I had created a test account to log into the Yahoo mail IMAP server. This was one of the reasons why. It was fairly interesting to play around with the commands to navigate the server and try different commands to pull down the list of emails in a specific folder. I wasn’t 100% sure until I did the testing as I haven’t performed this before so I tried both the fetch-att and fetch commands.

Eventually I figured out that I could simply enter the following to get a list of all the emails with the two requested fields.

a fetch 1:* (uid internaldate)

This command was not the correct answer to the question, even though it worked. After some fiddling around I realised that the question had provided me with the number of emails that were in the specified folder, and so I replaced the * with 147 and was awarded the points.

When I spoke to Arman about how my original answer was still correct, he rightly pointed out that we may not want to list every email if the mailbox has a large number of emails in it. Instead we may want to incrementally list out chunks, which makes perfect sense.

Therefore the correct answer is:

a fetch 1:147 (UID INTERNALDATE)

Question 5

The server returns the following list of UID and INTERNALDATE values when sorted chronologically by internal date. One of the messages on the list makes you suspicious. Enter its UID.

For this one we were provided a csv that contained a list of UIDs and dates. One would expect that the UID would increment sequentially and correspond with the time. I found that this was not always the case, but one of them really stood out.

I solved this in a couple of ways. The easiest way is to just run a bash command to sort the UID. I used some extra sed’s to clean it up a bit though.

cat Message_List.txt | sort | sed "s/(UID //g" | sed "s/ +0000\")//g" | sed "s/ INTERNALDATE \"/,/g

As we can see, 40790 has a UID greater than the one right before it, but the date was a few days earlier.

If we sort by date rather than UID, which I did in Excel, it stands out quite a bit. The right hand column is just showing the difference between the UID and the previous UID. I would expect them to by 1 except for the answer, except I did see some other (much lower) numbers in there.

I want to understand this one a little more, so looking forward to the walkthrough of how this was generated. As well as a possible explanation for why UIDs may sometimes be slightly out or order.

Onto Week 5! I’m 2 out of 3 questions down for that one already, except while I thought I had the answer for Q3 it looks like I’m not quite there yet.

Metaspike are doing a walkthrough of the questions to date on Jan 21, and you can register here.