No Tech Hacking

the_Grinch

Great video!

http://video.google.com/videoplay?docid=-2160824376898701015&ei=-Q-eSMDXGpCYrALU77Qf&q=no+tech+hacking

jbrown414

I caught the first 15 minutes of it as I'm at work. It was funny and informative and I'll definitely watch the rest when I can.

darkuser

hi my name's johnny
i hack stuff

dynamik

JD posted this awhile back, if you're interested in the other DefCon stuff: https://www.defcon.org/html/links/defcon-media-archives.html

Tyrant1919

Watched the whole thing, nice...

the_Grinch

Sorry for the double post and thanks for that site!

JDMurray

Actually, this video is from Defcon 15 in 2007. I would be nice if a few TE members were to look through the last few years of Defcon videos and post their "must watch" recommendations.

dynamik

the_Grinch wrote:

Sorry for the double post and thanks for that site!

Oh, that wasn't what I was getting at. I just meant if you liked that video, you'd probably like the other stuff there.

JDMurray wrote:

Actually, this video is from Defcon 15 in 2007. I would be nice if a few TE members were to look through the last few years of Defcon videos and post their "must watch" recommendations.

I'm in for that! I've been wanting to go through that ever since you posted it anyway. I just need to wrap this class up first

JDMurray

dynamik wrote:

I'm in for that! I've been wanting to go through that ever since you posted it anyway. I just need to wrap this class up first

I feel ya. I'm just waiting to wrap-up the CISSP exam myself. *groan*

jryantech

Very nice, I enjoyed that a lot.

the_Grinch

Not from DefCon, but great video that shows the power of social engineering!

http://video.google.com/videoplay?docid=-6271800786378394176

38 mins long, but well worth it!

jryantech

the_Grinch wrote:

Not from DefCon, but great video that shows the power of social engineering!

http://video.google.com/videoplay?docid=-6271800786378394176

38 mins long, but well worth it!

Wow this was very good as well.

I'm going to blockbuster after my class tonight to pick up "Catch me if you can" never saw it but have heard of it.

Thank you. Keep posting these interesting videos!!

rbutturini

If you get the chance pick up the "No Tech hacking" Book by Johnny from Syngress Publishing. It's a great read and contains more material like he had in his talk.

dtlokee

All the really good stuff at Defcon goes on when the cameras aren't on, in the back rooms where the smaller meetings form after a presentation like this. And yes everyone is looking at everyone else and thinking "He/she is a Fed".

the_Grinch

Just picked up the No Tech Hacking book yesterday. Figure once I'm done with my certs and school I'll read it. Lots of interesting topics!

sexion8

Lares Consulting has some neat pentesting/tiger team videos of the extreme kind

http://www.trutv.com/video/?id=870&link=truTVshlk

Chris is a pretty cool person as I've had the pleasure of speaking with him and he's extremely knowledgeable when it comes to security PERIOD. The methods used by Lares are often overlooked (social engineering, dumpster diving, etc.) Definitely worth seeing if you consider yourself a security engineer. I tried to mentor under him but he sadly reversed it on me and told me there would be nothing he could teach me via pentesting/technology... Bastid!. Seriously, he'd be one of the top guys I'd like on my team.

the_Grinch

Weakest link in the chain is the person who sits behind the computer. I've always had an interest in social engineering. Sadly, not many schools out there that teach it! One of my professors wrote a course for it, but the college refused to allow it to be run.

sexion8

the_Grinch wrote:

Weakest link in the chain is the person who sits behind the computer. I've always had an interest in social engineering. Sadly, not many schools out there that teach it! One of my professors wrote a course for it, but the college refused to allow it to be run.

Social engineering isn't always something that can be taught. I believe someone needs to have it kind of ingrained in them to understand it. For example I went through a scenario as follows for an idea...

Upon being called to audit a company, while sitting in the client's conference room, we'd ask for the names of the IT personnel and ask to speak to them individually. We'd have the CSO call them in individually while telling the CSO NOT TO DISCLOSE who we were and why we were there...

Upon arriving in the conference room, either myself or a colleague would grab our portfolio out of our bag (see this link to understand why: http://tinyurl.com/NSAportfolio). We'd then begin to tell him that we were looking for a specific file in our investigation. Now mind you, nothing said or done is illegal, we haven't identified ourselves as anyone. We merely had the CSO bring individuals in. We'd then ask them to log into their account via OUR machines which were rigged.

Gone in sixty seconds I can guarantee you that I'd be able to get at lowest, 80% of people to comply with logging in through our machine. How insane, simple, quick would that be. People are and will forever be the weakest link in the security chain.

So ask yourself, your most senior person in IT calls you into a conference room. You have zero idea why, he doesn't tell you and you meet a half dozen or so complete strangers with legal pads telling you "you haven't done anything wrong, and we're not accusing you of anything. We're doing an investigation to find a particular file and we'd like you to log into your account. If you feel uncomfortable doing so we can also get HR if your CSO who just left wasn't sufficient" You're alluding to something sure, but never offering anything identifying you which WOULD BE illegal (impersonation). Guarantee you most would fold.

the_Grinch

lol very nice. I'd imagine that the course was more of teaching people what to be on the look out for more then how to social engineer. I agree it is a skill that can't always be taught!

dtlokee

I would really hope no one in an IT role would fall for that, plus I'm not sure if it is a good example of social engineering as it requires the CSO to initiate it. People always want to keep their boss happy.

The oldest trick in the book is to simply put a key logger on your machine and call for tech support, wait for the admin to come out and log in with his/her credentials.

the_Grinch

Well, I believe it could work out. You could in theory identify yourself as law enforcement and run that entire scenario. How often do you hear of people being pulled over by someone who identified themselves as a police officer and then taken somewhere or had their belongings taken? You can find some amazing things on the internet these days (I have seen reports and auctions where actual police badges were made available). In the post 9-11 era people tend to not put up as much of a fight as they normally would. I've worked at school distracts and walked through schools without being challenged once. I've been buzzed in and wave to the ladies in the office who have never seen me before and they waved back. On many occasions when I have been challenged I'd say "I'm with IT" and that was enough. I will say though that at one school I was challenged by a teacher and she came closer and asked for my ID. But as Kevin Mitnick has said employees almost always want to help someone they believe is a coworker.

dtlokee

the_Grinch wrote:

You could in theory identify yourself as law enforcement and run that entire scenario.

really, really bad idea, that is a federal offense.

Also going outside of the previously agreed upon limits of a pen test is also illegal and could get you a heap of trouble. I try to advise clients it's in their best interest to not limit the test (an attacker would not have such constraints) but there are typically going to be systems they cannot afford to have compromised or the potential for a pen test against to take it offline which sometimes happens.

the_Grinch

Granted, I wrote that with the assumption that your client would be in on it. But as always thanks for keeping me clear on things

sexion8

dtlokee wrote:

the_Grinch wrote:

Also going outside of the previously agreed upon limits of a pen test is also illegal and could get you a heap of trouble. I try to advise clients it's in their best interest to not limit the test (an attacker would not have such constraints) but there are typically going to be systems they cannot afford to have compromised or the potential for a pen test against to take it offline which sometimes happens.

My scenario is perfectly legal period, no mention of myself outright identifying myself as an LEA nor would this be performed if it wasn't spelled out. As for "unpentestable" systems. There isn't such a thing period. I find anyone who would label something that wouldn't be a true pentester. I've done work on mission critical systems running live taps which couldn't afford to be disturbed and were flaky. We were still able to modify our timing, methods to find the same holes we would have during the course of a normal machine. It all depends on your methods. Timing values could be adjusted, number or connections, or solely doing a bit by bit copy, then taking that copy and creating a replica would suffice most of the time.

Its EXTREMELY important to look SPECIFICALLY at those systems since they're so invaluable. An attacker would never take a glimpse at a machine labeled gas-pipeline-mission-critical-machine.utility.com and say "Gee better pass this up, too mission critical for me" for any client whose concern was the availability, we'd work with it, but to get a full scope of the security posture, we'd need to see that machine, no ifs ands or butts

sprkymrk

dtlokee wrote:

I would really hope no one in an IT role would fall for that, plus I'm not sure if it is a good example of social engineering as it requires the CSO to initiate it. People always want to keep their boss happy.

The oldest trick in the book is to simply put a key logger on your machine and call for tech support, wait for the admin to come out and log in with his/her credentials.

+1.

And as far as social engineering being ingrained rather than taught, well that applies to any carreer, doesn't it? You could place me under the best auto mechanic in the world to try and teach me that stuff, but if I am not mechanically inclined or if I have no interest, I certainly won't get much out of it.

Anyone remember a great movie on social engineering called "The Sting"?

http://www.answers.com/topic/the-sting

dtlokee

sexion8 wrote:

dtlokee wrote:

the_Grinch wrote:

Also going outside of the previously agreed upon limits of a pen test is also illegal and could get you a heap of trouble. I try to advise clients it's in their best interest to not limit the test (an attacker would not have such constraints) but there are typically going to be systems they cannot afford to have compromised or the potential for a pen test against to take it offline which sometimes happens.

My scenario is perfectly legal period, no mention of myself outright identifying myself as an LEA nor would this be performed if it wasn't spelled out. As for "unpentestable" systems. There isn't such a thing period. I find anyone who would label something that wouldn't be a true pentester. I've done work on mission critical systems running live taps which couldn't afford to be disturbed and were flaky. We were still able to modify our timing, methods to find the same holes we would have during the course of a normal machine. It all depends on your methods. Timing values could be adjusted, number or connections, or solely doing a bit by bit copy, then taking that copy and creating a replica would suffice most of the time.

Its EXTREMELY important to look SPECIFICALLY at those systems since they're so invaluable. An attacker would never take a glimpse at a machine labeled gas-pipeline-mission-critical-machine.utility.com and say "Gee better pass this up, too mission critical for me" for any client whose concern was the availability, we'd work with it, but to get a full scope of the security posture, we'd need to see that machine, no ifs ands or butts

I didn't say your scenario was illegal, but the subsequent one that was proposed (identifying oneself as a LEA would be.) Also many pen tests do have limits, period. I have advised clients against this but there are times when they just won't budge. If a company identifies a system or method outside the scope of the agreed upon pen test, and you use that method or preform a pen test against that system it now falls under illegal access/use of a computer system. Legally this is subject to the same laws as "hacking" into a system of a company that you don't have a pen test agreement with, period. I agree it is important to have an agreement without limits since an attacker will not have such constraints, but when you are working with people with little technical skill it can be an impossible sell if they are afraid a test will impact business operations. You also need to admit that when doing a pen test it is possible to cause issues with the system you are testing regardless of how careful you are. It's a double edged sword because the people who are best suited to provide an acceptable scope are the IT staff/administrators but they are the same people we don't want to be aware of a pen test because they will inevitably go and tighten their security policies.

sexion8

dtlokee wrote:

Also many pen tests do have limits, period. I have advised clients against this but there are times when they just won't budge. If a company identifies a system or method outside the scope of the agreed upon pen test, and you use that method or preform a pen test against that system it now falls under illegal access/use of a computer system. Legally this is subject to the same laws as "hacking" into a system of a company that you don't have a pen test agreement with, period. I agree it is important to have an agreement without limits since an attacker will not have such constraints, but when you are working with people with little technical skill it can be an impossible sell if they are afraid a test will impact business operations. You also need to admit that when doing a pen test it is possible to cause issues with the system you are testing regardless of how careful you are. It's a double edged sword because the people who are best suited to provide an acceptable scope are the IT staff/administrators but they are the same people we don't want to be aware of a pen test because they will inevitably go and tighten their security policies.

Firstly prior to anything being done, contractual agreements would be laid out. I disagree with it being "important" to have an agreement, an agreement is mandatory period. There is no in-between, no contract, no work period.

As for IT staffers/admins tightening up their security beforehand, either way it doesn't make a difference to me. The tighter the system, the more challenging it is from the pentester perspective. There is a misconception commonly about auditing/pentesting which sends fears down the spines of admins who know they're being audited. Everyone turns on their "Cover Their Ass" mode. As a pentester, I feel its best to take the NSA IAM approach and remind those involved that placing blame won't accomplish much. Far better to consolidate the energy and time spent on the blame game securing/addressing any issues found. Just an opinion.

As for causing issues doing a pentest, there is that possibility however, due care and properly trained penetration testing can avoid these issues. Its called education. The sloppy pentester will fire off dozens of tools and attempt unstructured attacks. In the end many will try to create an overblown report often generated by one of their tools. "We've found vulnerability X!". These are what I call the unprofessional inexperience pentesters. Toolmonkeys.

Depending on the type of pentest one is performing - Blind, Double Blind, Gray Box, Double Gray Box, Tandem, Reversal ... I personally prefer ISECOM's methods - these issues are to be addressed way before any kind of testing is done... However, let me take it a few steps back for those others reading this as well...

Prior to anything being done on any system, prior to any tools being discussed, even thought of, parameters MUST be in order before proceeding. Parameters include the type of testing to be done, contracts signed, points of contact addressed, etc., for this portion I PREFER the NSA IAM method: Pre-Assessment - Post Assessment - On Site. The pre-assessment phase will address all issues before any technical work is done. This includes specifying what kind of testing will be done.

Most companies I've dealt with prefer Grey Box tests:

Grey Box testing as defined by OSSTM: The auditor engages the target with limited knowledge of its defenses and assets and full knowledge of channels. The target is prepared for the audit knowing in advance all the details of the audit. A gray box audit tests the skills of the auditor and the preparedness of the target to unknown variables of agitation. The nature of the test is efficiency. The breadth and depth depends upon the quality of the information provided to the auditor before the test as well as the auditor's applicable knowledge.

Most companies with the budgets to allocate for penetration testing - which is costly - aren't exactly concerned with what a black hat would consider a risk, they're mainly concerned with the management, analysis, assessment and mitigation of risks. Their bottom line is effective security governance as opposed to what is new in 0day land and are we vulnerable to it. Most prefer executive reports detailing baselines, common core logics and topic. Speak with any CSO about 0day versus governance and you will find many CSO's will look like deers looking at headlights when it comes to 0day. They mainly deal with financial aspects of security versus the technical side.

As a pentester/security professional, its up to you to explain the differences in testing methodologies to your client during the Pre-Assessment phase. Your client must be made aware of what the possibilities are including a potential Denial of Service (and this does not mean ping of death) on their infrastructure. They have to be made aware of potential risks, this falls on you the pentester/security salesman/etc._in_your_company to make know. Even if your client asks for a Blind test (aka Blackhat/zero knowledge), they need to be aware of the risks beforehand. Whether the information is trickled down to their employees is another story. As long as you've made the issues known, you've got the contract signed, come to agreements, your job is to do as specified under contract. Blind/Blackhat... Sure. Oh, I took out your database, wasn't intentional, maybe now you can also look into your DRM. Anyhow, enough rambling from me

dtlokee

Keep reading the part you want to read and ignoring the parts you don't. I said it is "important to have an agreement without limits", but I agree it is absolutely mandatory to have one otherwise your actions are now illegal. I am involved in the initial customer engagements and contract negotiation, I don't do pen tests. We do not bring in the team that is responsible for the pen tests to meet with the customers so there is no possibility of them being recognized during later pen test activities.

We choose not to tip off the admins because if they are on heightened alert and securing their systems it does not represent a true measure of normal operating conditions. It's not a matter of making it less challenging for our team, just to ensure the results represent normal conditions. We noticed known security issues would be removed and then reapplied after the completion. Because these conditions didn't exist when the tests were done they didn't make it into the reports, and security policies could not be updated appropriately. Just how we choose to approach it, I am not saying it is the only way to do it.

That is all I have to say about it.

sexion8

dtlokee wrote:

Keep reading the part you want to read and ignoring the parts you don't. I said it is "important to have an agreement without limits", but I agree it is absolutely mandatory to have one otherwise your actions are now illegal. I am involved in the initial customer engagements and contract negotiation, I don't do pen tests. We do not bring in the team that is responsible for the pen tests to meet with the customers so there is no possibility of them being recognized during later pen test activities.

We choose not to tip off the admins because if they are on heightened alert and securing their systems it does not represent a true measure of normal operating conditions. It's not a matter of making it less challenging for our team, just to ensure the results represent normal conditions. We noticed known security issues would be removed and then reapplied after the completion. Because these conditions didn't exist when the tests were done they didn't make it into the reports, and security policies could not be updated appropriately. Just how we choose to approach it, I am not saying it is the only way to do it.

That is all I have to say about it.

There is no reading the part I want to read, there are facts, its not important to have agreements without limits, most of the times its mandatory when performing a black hat test. Its important to be happy, doesn't mean it's always achievable, its MANDATORY that you will have to deal with whatever you are dealt, important or unimportant. So when hired to perform these (what are supposed to be) realistic tests, a client should either know, or be informed as to the best extent you can perform this test. Sometimes it isn't even about technology most of the times. At times it may be best to emphasize the need for social engineering, in fact, as a business strategy it would make sense if you had intentions on offering training atop your testing.

As for your methods of choosing which test you want your pentesting team to perform, for me it's all spelled out beforehand, before I begin anything. Seems you prefer to hire out Blackhat/zero_knowledge like tests, yet you state "but they can cause a denial of service" if I read it correctly beforehand:

dtlokee wrote:

they cannot afford to have compromised or the potential for a pen test against to take it offline which sometimes happens.

So what kind of realistic testing are the guys you hired performing? Your wording to me makes me infer an image of a martial arts expert who was hired to perform his fighting skills against someone yet he steps in the ring and says "ok wait, don't hit me too hard".

Personally, I prefer structured pentest in fact via the patenting process I have a patent coming out on a method to perform pentesting. To me there is outside and there is inside, many forget this little tidbit. When we perform our tests, we prefer to perform dual gray hat tests (one inside and one outside). We use the information correlated and prepare a variety of scoring methodologies to risks. Its often a mixture of CVSS combined with other practices used in the industry. We've had much success in getting a realistic view of what a malicious hacker would see attacking from outside of the network as well as inside the network. We've tested servers down to C2 level security when asked to do so and have pentested C2 level machines down to the physical locations.

I understand what kind of testing you prefer, and maybe its just my inference but it sounds unrealistic. If you're asking for a tiger team full scale test, zero knowledge, me being a hacker trying to get in, I will do my best to find a way in. I would have also explained to you beforehand the issues surrounding the testing (again), machines potentially becoming inoperable, and would have likely developed a strategy to test during optimal times. Optimal timing is also crucial in order to perform realistic testing. For example, I know many an admin who have time based rules who keep things rather lax during working hours. To me, there is no cookie cutting what you spelled out was a black hat test, sorry it either is as realistic as possible, or its a skewed method of testing security.

sprkymrk

sexion8 wrote:

Personally, I prefer structured pentest in fact via the patenting process I have a patent coming out on a method to perform pentesting.

sexion8 wrote:

To me, there is no cookie cutting what you spelled out was a black hat test, sorry it either is as realistic as possible, or its a skewed method of testing security.

So you have a patent pending for a structured process of pentesting, isn't that a cookie cutter method? And if it's not, then how does it differ with dtlokee's preferred method? Having a "preferred method" as a guideline from which to perform a pen test does not necessarily make it a cookie-cutter method, provided you allow for personal actions based upon findings. I'm not sure how you drew the conclusions you did on dtlokee's method based upon what he wrote.

sexion8

sprkymrk wrote:

So you have a patent pending for a structured process of pentesting, isn't that a cookie cutter method? And if it's not, then how does it differ with dtlokee's preferred method? Having a "preferred method" as a guideline from which to perform a pen test does not necessarily make it a cookie-cutter method, provided you allow for personal actions based upon findings. I'm not sure how you drew the conclusions you did on dtlokee's method based upon what he wrote.

The method going through patenting is based on how the test is conducted which is similar to performing grey, black and white hat tests all in one or intermingled. My inference on his words were based on his statements, re-read them, on the one hand he prefers a realistic test with zero knowledge, at the same time his wording eludes to him preferring to "avoid" certain systems out of fear they will be subject to a DoS (taken offline). How can a realistic test be performed if machines will be skipped. What kind of scope is gathered when a machine isn't tested, what realistic results do you have. Are the pentesters guessing whether or not the machine he doesn't want tested is vulnerable.

On the one hand he wrote:

We choose not to tip off the admins because if they are on heightened alert and securing their systems it does not represent a true measure of normal operating conditions.

On the other he stated:

but there are typically going to be systems they cannot afford to have compromised or the potential for a pen test against to take it offline which sometimes happens.

So here I inferred: "We test all the machines without admins knowing because we want to see a real world view... BUT, because some machines can be taken offline during the course of the pentest, the customer might not want this. Bottom line, if you're not going to test them in this fashion, you're going to have skewed results, how realistic of a pentest is it.

Analogy time... Someone calls a plumber to check for specific leaks, there are certain pipes that might be more fragile than others. During the testing of the pipes, say the plumber had to use a certain tool to detect a leak. Before he begins his test to find the leak, you tell him not to test those fragile pipes even though THEY might be the cause of the leak.

So what did you really get for your money? Now if I were the plumber, I would explain to you the need for me to test those pipes anyway - as they could be the source of the problem. I would explain to you that I would do my best to ensure nothing happened during the course of my testing however, by not testing them, what am I actually doing for you at the end of the day.