Thursday, November 9, 2017

Question 1

Question: Given what you learned about CALL and RET, explain how you would read the value of EIP? Why can't you just do MOV EAX, EIP?

Answer: The easiest way I could think of to read the current value of EIP was to do the following:

CALL *instruction after this call instruction* <- 5 Bytes

POP EAX <- 1 Byte (the instruction that we will point to)

ADD EAX, 4 <- 3 bytes

Essentially we will do a CALL to the POP EAX instruction, at which point ESP will point to the address where "POP EAX" is located in memory (aka the return address for the CALL instruction). POP EAX will ensure EAX gets set to this value. Adding 4 to EAX will ensure we add 1 to this value to compensate for the "POP EAX" instruction, then we add another 3 for the bytes that formulate the "ADD EAX, 4" instruction.

Question 2

Question: Come up with at least two code sequences to set EIP to 0xAABBCCDD.

Answer:

Option 1

PUSH 0xAABBCCDD ; PUSH value onto the stack

RETN ; POP the value at the top of the stack into EIP and resume execution from this location.

Option 2

JMP 0xAABBCCDD ; Just straight up redirect execution. Why not make it simple after all?

Question 3

Question: In the example function, addme, what would happen if the stack pointer were not properly restored before executing RET?

Answer: Well considering the stack pointer would be the part where we do the PUSH EBP instruction, we would return execution to EBP, which would basically mean we would return execution to the stack. What happens from here depends on the data that is on the stack. If this results in invalid instructions we would crash. On modern systems the more likely scenario is that DEP would kick in and you would get an ACCESS VIOLATION as the stack would be marked as non-executable.

Question 4

Question: In all of the calling conventions explained the return value is stored in a 32-bit register (EAX). What happens when the return value does not fit in a 32-bit register? Write a program to experiment and evaluate your answer. Does the mechanism change from compiler to compiler?

Answer: I honestly haven't played around with this much due to compilers deciding to fail over at the time of testing :( However the one I did get something to work on, Visual Studio 2017, appeared to give a warning that it was going to truncate the return address value down to a 32 bit value during compilation. I have heard other compilers may try use EDX:EAX as a way of returning the value as well, but yet to verify this further via my own experiments.

Problem

"This function uses a combination of SCAS and STOS to do its work. First, explain what is the type of the [EBP+8] and [EBP+C] in line 1 and 8 respectively. Next explain what this snippet does."

Disassembly:

1: MOV EDI, [EBP+8]

2: MOV EDX, EDI

3: XOR EAX, EAX

4: OR ECX, 0FFFFFFFFh

5: REPNE SCASB

6: ADD ECX, 2

7: NEG ECX

8: MOV AL, [EBP+0xC]

9: MOV EDI, EDX

10: REP STOSB

11: MOV EAX. EDX

Explanation:

Line 1: We set EDI to be the value at EBP+8

Line 2: We save the value of EBP+8 to EDX.

Line 3: Clear out EAX, aka set EAX to 0.

Line 4: Set ECX to 0xFFFFFFFF or -1 by OR'ing all of its bytes with 0xFFFFFFFF. As 0x1 OR 0x1 = 1, and 0x1 OR 0x1 = 1, all bits will be set, making it -1.

Line 5: Read value held in EDI, aka the value pointed to by EBP+8, and check it if it is the same as EAX, or 0. When we look at the REPNE instruction, we can see this is essentially a strlen operation as we will keep repeating this operation and decrementing ECX by 1 each time until we hit a NULL byte terminator aka 0.

Line 6: Add 2 to ECX. If we performed the STOSB instruction 8 times, the value in ECX would be -9. Adding 2 to this value will make it -7, aka the negative equivalent of the number of characters in the string before the null byte.

Line 7: Use the NEG ECX instruction to do a 2's compliment operation on ECX and in effect flip the sign bit of ECX, transforming it from a negative number to a positive one. In our example, ECX would go from -7 to 7.

Line 8: Move byte held at EBP+0xC into AL.

Line 9: Set EDI back to the address pointed to by EBP+8 using EDX, where we had saved the original EBP+8 value.

Line 10: For ECX times, aka the number of characters in the string as determined earlier, write the byte contained at EBP+0xC, aka AL, into the string array pointed to by EBP+8, aka EDI.

Line 11: Move EDX, aka the start of the string buffer or EBP+8, into EAX so we can return it to the calling function.

So in essence this could be simplified down to the following in C:

int len = strlen(*(EBP+8));

memset(*(EBP+8), (BYTE *)(EBP+0xC), len);

We also can answer the other question as we now know that [EBP+0xC] is a pointer to a byte value to use for the memset operation, and [EBP+8] is a pointer to a NULL terminated string which we want to memset to the value pointed to by [EBP+0xC].

Monday, January 16, 2017

Intro

Heyo folks. So on Twitter I asked a number of you what you wanted me to post about, and a number of you said that you'd like to hear what I've learned from working about a year in pentesting. Well, without further do I'm going to try and explain what I think are some of most important lessons I have learned from some of my recent and past jobs. There is a lot to cover so this post might be a little long but hopefully it will help some of you out there when encountering similar situations.

Lessons

Okay we are going to do this on a mixture of anonymised situation based scenarios which I have encountered as well as some general tips as I can't remember every situation :P

Always Relate To The Client

So this is one of the lessons that I had more trouble with but I had some specific scenario with a client that made me realise the importance of this. I was onsite with the client working a particularly disorganized job where things weren't working out and my technical contact was constantly pulling me off the job for various things such as updates on the testing and meetings with various people. This lead to tension between me and my technical contact as I was not particularly happy with being taken off the job to do these various elements and we were not seeing eye to eye with some of the arrangements that were being made to try get the pentest back on track.

Eventually though, I did find a solution that worked. What was it you ask? I looked at the situation from the perspective of the client. I realized that I needed to stop pushing the job from a pentester's perspective and start looking at how I could try help the company from the perspective of my technical point of contact. This is an important lesson and one I still use on my jobs today as it is important to realize that there is a time and place for being stern and pushing the fact that organizations need to get their shit together, organise themselves to be ready for a pentest, and make sure they fix their issues, but there is also a time to understand that there is a lot that goes on in order for an organization to be ready for a pentest and that there may be a lot of things going on behind the scene that you are not fully aware of that may explain why the organization can't patch that high risk issue you reported or get those credentials that you need to test the web API.

Therefore realize that everyone you work with is just another human trying to do their job. Once you realize that, you'll realize that even managers are just another person you need to relate to, albeit at a different level than an engineer which you might have to relate to on a more technical level. Get to understand the person, their problems, and think about how you can work to solve those problems, and you'll not only help to solve their problems, but you'll likely solve your problems in the process and will speed up your pentest in the process.

Realize That Not Everyone Has the Mindset for Pentesting

So this is more of something that I have noticed from watching people who have left pentesting as a whole, but I would like to point out that some people join pentesting but just don't have the right mindset for it. Now I may be wrong about this to some extent and I could look back on this and ask myself why the hell I wrote it but I have noticed some people who have joined pentesting recently who have no real self-seeking passion for knowledge and that intrinsic passion to learn more and experiment with things to figure out how to really solve the issue.

The problem with this is that your not always going to be able to ask people for help when your on site on a client site. You may have a website that requires some specific method to interact with it, and without being able to investigate, discover the internal details and craft a solution, your not going to be able to fix the issue. A somewhat better example though is that without having the drive to learn more, your not going to be able to push yourself to learn new technologies and exploitation methodologies that will allow you to provide the best possible solutions to your companies' clients. You are then facing the risk the company seek out more capable pentesters in the process, which leaves you with a situation of job instability if the company doesn't think you are doing as good a job as it expects from its pentesters.

This has lead to some people that I know leaving pentesting and going into software development instead; if I am being completely honest, I am really happy that they did. They were clearly more driven by the programming side of pentesting and did not always have the skills needed to deal with variety of customer situations that a pentester inevitably encounters. They did however know how to craft programs to solve a variety of problems, had good knowledge of programming and associated programs, and had the drive to create solutions to common problems they encountered, all things that are well suited for a programming job.

So, yeah that was a bit long winded, but essentially realize that you may end up working with people who are quite simply just not suited to pentesting. You're just going to have to deal with it and try and help them as much as you reasonably can, and hope that for their own sake they may find something that better suits their available skills and makes them happy, as you are not responsible for their decisions in life and ultimately they must make their own decisions regarding their job.

Your Going to Live in Hotels

One thing that I think people don't fully realize is just how much time you may end up spending away from home, family, etc as a consultant. Being a consultant isn't just a 9 to 5 (or in our case 5:30) job. It will require you to travel down to the client on the weekend, work after normal hours to understand that job that you have coming up, or edit the report for a previous client.

In fact this was actually one of things that I have seen several people complain about when they start working as a full time consultant. My response honestly? Get used to it. We have people in our office that I rarely if ever see. Why? Well some of them are just working from home as its too expensive to come into the office, but a fair number of them are onsite working for a client, and spend most of their month traveling between various client sites for associated onsite jobs. Its not uncommon to be fully booked for the month on onsite jobs with no associated "white days" (aka free days where you can catch up on work, do research, or whatever you like within reasonable limitations) for that month.

As a consultant you are expected to be able to travel to jobs as and when clients ask for you. That job could be up in Scottland, it could be way down South on the coast, it could be easily accessible by train, it could be a long car drive away, it all depends. You need to be ready to go anywhere, and adjust your travel and hotel plans to suit situations that may come up (prime example: train strikes, all the 3 star hotels being booked leaving you with only a local 2 star hotel to stay in (happened to me twice)).

So yeah, if your not ready to be flexible on a daily basis, pentesting may not be for you.

Be Prepared for Things to Go Wrong, and Realize Its Not Always Your Fault

I literally can't tell you about the number jobs where things have gone wrong. From missing credentials, to the client updating the site in the middle of testing, to missing authorization forms, to credentials being incorrect, to documentation not being supplied, there are many things that can go wrong in a pentest. Sometimes you may even feel that you caused all of this to happen and it can be overwhelming at times thinking that you might have forgotten something that you think caused all of this to happen.

The best way to deal with these sorts of situations I find is to expect that you may have to spend a day or a few hours on the first day dealing with issues and trying to get things sorted out, especially if its an onsite job (I find remote jobs typically tend to go quite smoothly minus potential access issues as there is less for the client to deal with in most cases). Be prepared to take an active part in trying to help the client out as it is likely that they may not fully understand what you need to conduct your test so you will have to explain it to them keeping in mind they may not be technical.

Also realize that most times when something goes horribly wrong its not entirely your fault. Sure, there may be some situations where you really did mess everything up, but 95% of the time, its either going to be both the client's and you or your company's fault. This may be because the job was not scoped correctly, because the client didn't supply appropriate details, because there was a lack of understanding of the technology, or any number other reasons. All you can do is try do your best to solve the situations you are responsible for and realize that you are not responsible for everything, and there are things that are beyond your control.

Ask Questions to Colleagues But Only If You Can't Find The Answer Yourself

Whenever you are pentesting, one of the most important things to realize is that your colleagues are around to help you. If you are seriously stuck or need advice about something, send them an email or walk up to them and ask them your question(s). Even managing pentesters still have questions about their job; everyone is still constantly learning and we all need to ask each other for help from time to time.

Do be careful though, as you can fall into a trap of asking questions too often instead of looking things up yourself, and you can end up just bothering fellow colleagues (something that I personally am trying to improve on). Therefore always make sure you have a concrete question you want to ask and that you have tried to look up the answer beforehand. This will prevent you asking questions that are a simple Google or internal website/wiki/documentation/etc lookup away from an answer.

Conclusion

Hopefully that helps some people who are starting out in pentesting. I may expand this more in the future, but this is what I was able to come up with in one night from my recollection of past events and jobs within the last year that stood out to me as being prominent in shaping my day to day activities pentesting or which taught me an important lesson.

Let me know if there are any lessons from your pentests you have learned - I would be interested to hear other people's experiences.