JF's security (and other things) log

How to rework your network infrastructure for security

From here:

For years, managers and directors have taken the approach of throwing boxes and money at IT problems. In the past this technique may have provided the result needed; either in function or in checkbox requirements.

IT security needs pose a slightly different challenge for a secure network infrastructure. Throwing boxes and more stuff at security issues is not sufficient and often leads to a false sense of protection in the organization. In this tip, we'll explore four ways to build a secure network infrastructure by retooling your existing network investments.

Avoid adding complexity to network infrastructure
In a world where switches and firewalls talk to servers, and endpoints talk to switches, a holistic approach can save money while remaining a sustainable solution for years to come. Security solutions are thorny enough as it is. Don't over-complicate your project by building a house of cards doomed to collapse when the next big storm blows through. Focus on basic staples in the network including switches, centralized authentication, firewalls and UTM devices, patching and reporting, as well as policy management built into your directory services. Layering disparate management, reporting and authentication for access to the LAN, wireless and remote access will quickly result in a train wreck.
Infrastructure must support security layers
Layering network security on top of an infrastructure not designed to support it is just as ill-advised as building a house on a wobbly foundation. Most organizations don't get the luxury of fresh start by redesigning the network every couple of years. Even if the hardware is upgraded, chances are slim that the underlying infrastructure design has changed significantly. When these networks were originally provisioned 10 years ago, we weren't planning for bulk wireless authentication or port-based security. Layering LAN-enforced security such as firewalls, IDS/IPS, zoning, NAC, 802.1X, application firewalls or wireless on top of a poorly designed (or out of date) network results in poor security policy enforcement and leaks that result from compromising security for the more immediate necessity to continue operations without interruptions.
Properly use VLANs and network segmentation
VLANs and network segmentation are one of the most widely understood but globally misused tools in a network infrastructure. Vendors go out of their way to make plug-and-play solutions to save you the trouble of understanding these key concepts -- often to the demise of the overall goal. In a recent white paper, we identified four commonly used degrees of VLANs in the network. The use cases ranged from the improper (but common) use of untagged (access) VLAN assignments in a core, with each downlink to edge switches left in the default VLAN to full VLAN extrusion in multi-VLAN environments carried through from core to edge and beyond.
In many cases, what we would normally deem to be improper use of VLANs may simply be the misuse of VLANs for the desired outcome. For example, if we started with a flat network and wanted to layer in a VoIP network, we would need the ability to carry that VLAN tagging throughout the network. The same goes with wireless, and the most impact is often seen with RADIUS-assigned VLANs pushed during NAC, 802.1X or standard RADIUS authentication. If you can't globally push group-based VLAN assignments out to the edge without mucking up your current access rights, then you've landed yourself in quite a mess.
Document network connections, review security policies for leaks
Don't lock the windows and leave the doors wide open. Big and small, there are a variety of mischievous holes often overlooked in network designs. Searching for holes raises questions. You enabled SSH, but did you lock down the Web access? You recently provisioned secure wireless, but do you still have other devices using legacy WEP keys? Did you know about those two dialup lines coming into the server room? Is your firewall implementing policies across every possible path out of your network? Can you really identify the weakest link in your network?
As network and security administrators, we worry about data leaks as well as management leaks. We don't want critical data, personal identifiable information or intellectual property seeping out of the network, nor do we want a malicious user to gain unauthorized access to our device management. Finding holes is a tedious undertaking and requires a close look at the network, an extremely granular documentation of connections and a review of security policies and posture of all devices.

There is no single tool set that can reproduce the discriminating human review of a secure network infrastructure; however, there are products and resources that provide a good start for documenting, reviewing and searching for holes.

About the author
Jennifer Jabbusch is an infrastructure security consultant with Carolina Advanced Digital, Inc., a security integrator based in North Carolina. She specializes in areas of network security, NAC/NAP, 802.1X and wireless security, and consults for a variety of government agencies, educational institutions and Fortune 100 and 500 corporations. She serves as a contributing SME on access control, business continuity and telecommunications, and lead SME in the cryptography domains of the official (ISC)2 CISSP courseware and maintains SecurityUncorked.com blog.

By JF
August 21st, 2009
Posted in Security
489 views

Streaming TV channels for .nl

By JF
July 30th, 2009
Posted in Fun stuff
423 views

Malware IN Registry a.k.a If It Can?t Be Done, Why Am I Looking At It?

From here:

July 28th, 2009 cutaway Posted in Incident Response, Malware, Microsoft, Security | 27 views

I have to say that reading the Windows Incident Response blog has been very useful on several occasions. Particularly last month while helping at a client?s site. I had been called in to assist with detecting the Initial Infection Vector of a piece of malware that was propagating to random systems throughout a very large network. Luckily when I got onsite I was pleased to find that the company?s security staff were squared away and knew how to user their incident response procedures and tools very effectively. Really they just needed an extra set of hands and a little more organization to help them get over the hump.

After gathering some information from systems around the world (literally) I started doing some memory analysis information captured from one of the infected systems. Memory analysis quickly identified one process that had used for DLL injection. One of the exported functions of a DLL we had already flagged as ?interesting? was exporting a function called ?StartLoopRunDoor.? Although this could just be anomalous it sounds an awful like ?backdoor? so we noted it. I moved onto generating timeline information from the systems files, folders, Event logs, and registry modifications and the security administrator helping me added ?door? to his keywords and ran another search on the system. As he was reviewing the hits I heard him say, ?What the hell. Hey come look at this.? As I Peeked over his shoulder he pointed me to a registry key that had the value ?door.? I started to say, ?Yeah, no big deal? when he asked me ?Can you store executable files in the registry?? Smiling, I said, ?As a matter of fact, you can.?

It turns out that just days before heading to the site Harlan had mentioned it in his post ?More Links?. Basically Harlan points us to a write-up over at Sophos Labs titled ?Persistence is Futile?. They outline one such infection very nicely and Harlan concludes his post with some interesting capabilities that we might want to take into consideration. Had I not read Harlan?s post I might not have been surprised by the malware hidden in the registry key values, but I would not have known where to go for immediate resources to help with the situation.

So, what am I really talking about. Well, luckily I have a few screen shots for you. First lets start with reviewing the Registry Key in question. Using Mitek?s Registry File Viewer we drilled down into \\Software Hive\Microsoft\SysMgr. The are several key values as you can see. One key value that is hidden is ?addr? which contains the IP address of the infected system and one other IP address (not sure the reason).

SysMgr Key

Now, many of you will be quick to recognize ?4D 5A? which corresponds with ?MZ? located at the beginning of Windows-based executable and DLL files. For a better look, here is some of the information in the ?ssdt? key value.

SysMgr SSDT Value

Definitely an executable or DLL. Turns out, that this file was getting written to disk. Funny thing is, Symantec and Microsoft were not detecting it at the time. (I have to say, at the time they were detecting the file in the ?hide? registry key value but only on disk.) So, we gave them a call. First we started with the company?s Symantec contact. We explained what we were doing and then what we had found. His first words were ?You can?t do that.? We politely informed him that we were looking right at it and it can be done. Next we pointed him to the SophosLab post so that he could do a little research and spin up on the concept. Next we asked if they could start working on signature for the malicious code injected into memory and the malicious files stored in the registry. His response ?No and No.?

Let me break down why quickly. Basically Symantec does not scan memory. Oh it will look at memory. It detects what is running and then scans the files, executables, DLLS, etc on disk to see if they contain code that triggers one of their signatures. But beyond that they cannot detect malicious code that has been injected into memory. NICE!!! Next, although the engine (he said engine, not definitions) can look at certain ?hard-coded? locations in the registry, it does not actively scan the whole registry looking for malicous behavior. NICE!!! Whether or not he new what he was talking about the answer we got at the end of the phone call was, ?Send us your files and we?ll see if we can do anything.? Which, in the end, they did. But the situation as it occurred was not very promising.

TIP: You can export the file in any key value by clicking ?Save data?.? Hashes of the extracted file and malware found on the system were identical.

Next we called Microsoft. We explained the situation again to their support representative and the first words out of his mouth were ?You can?t do that.? The rest of the conversation was very similar to the Symantec call.

Of course, while we are talking to these representative we were also looking at the other keys. Remember ?door?? Well, a quick peek at its contents started to get us a little worried. Here is what we saw.

SysMgr Door Value

Notice the ?db? at the beginning? What about the ?yyy? (I know, deal with it!!) and ?vk? values? Well, my friends, that is a little database right there in the registry. The first entry is the file that is located in the ?ssdt? key value. I cannot show you the other entries in this database because they are related to client information from the registry. Stuff like account information, group policy settings, and software that was run on the system. Just little things like that.

So, not only do you have to be worried about the registry being used as a part of a malware?s persistence mechanism, you also have to be concerned about the registry being used as a staging area for your intellectual property, credit card information, user information, etc. All this with limited methods to detect these situations.

The next question is pretty obvious. If my anti-virus program cannot help me, what can I do to protect myself. Well, as I am tired, that is going to have to wait until tomorrow. Check back as I?ll have a registry detection script modeled after Harlan?s RegScan and three RegRipper timeline plugins.

Go forth and do good things,

Don C. Weber

By JF
July 28th, 2009
Posted in Security, Programming
454 views

Identity theft ? knowing me, knowing you

From here:

It was National Identity Fraud Prevention Week last week ? and frankly, like Jeremy Clarkson, I do not give a toss that millions of people can find odds and ends of information about me online. So now you know I like Kraftwerk and reside somewhere in Dublin? ? that?s hardly the makings of the successful theft and abuse of someone?s identity.

I can imagine it now. Using a print-out of a picture of me found online, and armed with my name, city of residence and my job description, someone will procure a loan, bleed me dry and run off to Mexico. Whatever.

So I came up with a simple plan. I decided to approach Brian Honan of online security consultancy BH Consulting, challenge him to build a comprehensive profile from whatever he could find about me online and see if he had enough to do some damage in the real world.

A few minutes after agreeing to this and clicking send I sat there feeling quite smug, and when I got an email back a little while later with a few nuggets of information, I felt even better because I knew this was the result of a simple Google search. I was still in control.

Anyone who spends any amount of time online will find this to be the case, after all, it is part and parcel of living in a connected world. If everyone?s basic information is out there, then we?re all equal, right?

Wrong. Some are more equal than others. I make sure to keep my social networking profiles locked down so only my friends can see information such as date of birth, mobile number, family photos and the like, but this is not enough to protect yourself on these sites.

If your friend is taking the risk of leaving his or her profile open, then this is a great backdoor through to your information. This is actually how Honan found my date of birth ? something I was not happy he was able to do. It wasn?t very obviously laid open, but accessible nonetheless, and as Honan pointed out, this was without doing anything illegal, just some snooping.

And here?s another thing ? dated photos on some hosting service like Flickr with captions like ?my birthday? are obviously a good way of getting this information (this is how Honan double-checked my date of birth), but thankfully, while not a model student, I was not a complete dunce about protecting my identity.

?It did take a while to build up that information. You have kept your information well protected,? remarked Honan.

?Normally, in a case like this, most people would have a lot of information on their Bebo or Facebook or MySpace page. In your case, you keep your stuff private.?

Phew. So what would he normally do if he ran up against a brick wall like this?

?I?d try to become one of your friends on those sites, but I figured that would tip you off to what I was doing. But a real ID thief would have tried that route anyway.

?I could have set up a fake profile of someone who went to school/college or work with you, and then tried to become your friend that way. This would be time-consuming as it would require me to ensure I picked someone who would have been a distant colleague, but not someone you would have kept in touch with regularly.

?Normally this would be done by doing up a matrix of your online friends and cross-referencing the lists of your friends (from various sites/services) until I found a person on one of your friend?s lists but not on yours.

?Once I became one of your online buddies, then I would have access to whatever information you would have in your profile. If that was not informative enough for me, I could then use some social engineering-type games to get the information I need.?

This is pretty chilling stuff, but I think I would be too wary to become friends with someone unless I knew them better, so Honan was down on his luck for now.

?The biggest challenge was finding the time to trace through all the sites and links. There were many dead-ends that led nowhere and I had to retrace my steps. So if someone had the time and patience then yes, they could do what I done. It also helped that Boran is not a common name. I?m glad you?re not Marie Smith.?

I?m not. It seems like a mixture or patience, luck, circumstance and such that will get you this information, and we all have it out there, but I was still sceptical ? what was the worst that could happen?

Actually Honan managed to get some information that I was definitely uncomfortable to have out there, and it resulted in me going back and erasing and/or tightening up my online security. As I already said though, you cannot control publicly available information on government sites, your friends? social networking profiles and blogs and so on.

Also, I think nothing of casually mentioning on blogs or the like that I shopped here, ate there or holidayed in such a place, and Honan recommends against this: ?Even something as simple as letting people know that they are going on holidays is information a criminal could use to target an empty house to break into.

?I think people are not aware enough that information they put on the internet is available to anyone, and what you may think is a private online conversation or interaction may not necessarily be so.?

Honan thinks that to some extent we are quite blasé about the information we put out on the web: ?I am not sure whether that is a generational thing or lack of understanding of technology. For example, I know my parents? generation would be more circumspect about information they would share with others than my generation, and equally my generation appears to be more circumspect about what we share with others than today?s teenagers and young adults are.

Honan thinks part of the problem is that people do not realise that when you are on the internet, the information you put up there remains there and can be viewed by anyone.

?Also, people engage with others on the internet from the safety of their office or home; this can lead to a false sense of security as you may feel that you are being private because you are not in public.?

Guilty as charged, but with this newly created profile, what could Honan theoretically have done?

?The information I got on you would allow me, providing I got a sex change, shed 10 stone and 20 years, to actually become you.

?I can then take out loans or mortgages in your name leaving you with a ruined credit rating and a lot of hassle trying to clean up the mess.?

Wait, hold the phone. Become me? I can honestly say that I was quite shocked and a bit angry with my ?blasé? attitude to my digital breadcrumbs. Here?s a few things Honan found that surprised me: he knew what shade of blusher I wore, my bus timetable and a fair bit about my education.

And before you go googling, yes, based on this, Honan could have done the same to you. And remember, this is without doing anything illegal ? he is one of the nice guys.

By Marie Boran

By JF
July 24th, 2009
Posted in Security
591 views

How I Stole Someone's Identity

From here:

The author asked some of his acquaintances for permission to break into their online banking accounts. The goal was simple: get into their online accounts using the information about them, their families and acquaintances that is freely available online

By Herbert H. Thompson

As a professor, a software developer and an author I've spent a career in software security. I decided to conduct an experiment to see how vulnerable people's accounts are to mining the Web for information. I asked some of my acquaintances, people I know only casually, if with their permission and under their supervision I could break into their online banking accounts. After a few uncomfortable pauses, some agreed. The goal was simple: get into their online banking account by using information about them, their hobbies, their families and their lives freely available online. To be clear, this isn't hacking or exploiting vulnerabilities, instead it's mining the Internet for nuggets of personal data. Here's one case. I share it here because it represents some of the common pitfalls and illustrates a pretty serious weakness that most of us have online.

Setup: This is the case of one subject whom I'll call "Kim." She's a friend of my wife, so just from previous conversations I already knew her name, what state she was from, where she worked, and about how old she was. But that's about all I knew. She then told me which bank she used (although there are some pretty easy ways to find that out) and what her user name was. (It turns out it was fairly predictable: her first initial + last name.) Based on this information, my task was to gain access to her account.

Step 1: Reconnaissance: Using her name and where she worked, I found two things with a quick Google search: a blog and an old resume. Her blog was a goldmine: information about grandparents, pets, hometown, etcetera (although it turns out I didn't need to use most of this). From the resume I got her old college e-mail address and from her blog I got her G-mail address.

Step 2: Bank Password Recovery Feature: My next step was to try the password recovery feature on her online banking site. The site didn't ask any personal questions, instead it first sent an e-mail to her address with a reset link which was bad news, because I didn't have access to her e-mail accounts. So e-mail became my next target.

Step 3: G-mail: I tried to recover her G-mail password, blindly guessing that this was where the bank would have sent its password-reset e-mail. When I tried to reset the password on her G-mail account, Google sent its password reset e-mail to her old college e-mail account. Interestingly, G-mail actually tells you the domain (for example, xyxyx.edu) where it sends the password reset e-mail to, so now I had to get access to that?ugh.

Step 4: College E-Mail Account: When I used the "forgot my password" link on the college e-mail server, it asked me for some information to reset the password: home address? (check?found it on that old resume online); home zip code? (check?resume); home country? (uh, okay, check?found it on the resume); and birth date? (devastating?I didn't have this). I needed to get creative.

Step 5: Department of Motor Vehicles: Hoping she had gotten a speeding ticket, I hit the state traffic courts' Web sites, because many states allow you to search for violations and court appearances by name. These records include a birth date (among other things). I played around with this for about 30 minutes with no luck when I realized that there was probably a much easier way to do this.

Step 6: Back to the Blog: In a rare moment of clarity I simply searched her blog for "birthday." She made a reference to it on a post that gave me the day and month but no year.

Step 7: Endgame (or How to Topple a House of Cards): I returned to the college e-mail password recovery screen and typed in her birth date, guessing on the year. Turns out that I was off on the year of birth but, incredibly, the university password reset Web page gave me five chances and even told me which field had inaccurate information! I then changed her college e-mail password, which gave me access to her G-mail password reset e-mail. After clicking the link, Google asked me personal information that I easily found on her blog (birthplace, father's middle name, etcetera). I changed the G-mail password, which gave me access to the bank account reset e-mail, and I was also asked for similar personal information (pet name, phone number and so forth) that I had found on her blog. Once I reset the password, I had access to her money (or at least I would have).

Needless to say, Kim was disturbed. Her whole digital identity sat precariously on the foundation of her college e-mail account; once I had access to it, the rest of the security defenses fell like a row of dominoes. What's striking about Kim's case is how common it is. For many of us, the abundance of personal information we put online combined with the popular model of sending a password reset e-mail has our online security resting unsteadily on the shoulders of one or two e-mail accounts. In Kim's case some of that information came from a blog, but it could just as easily have come from a MySpace page, a sibling's blog (speaking of their birthday, mom's name, etcetera) or from any number of places online.

Battling this threat requires us to make better choices about how we prove who we are online and what we make available on the Internet. Go and do a self-check. Try to reset you passwords and see what questions are asked to verify your identity. Some questions are better than others. Date of birth, for example, is bad. In addition to the DMV, there is a wealth of public records available online where folks can track down when you were born. Most account reset features give you a choice of questions or methods to use. Go for questions that ask about obscure things that you won't forget (or can at least look up), like your favorite frequent flyer number. Avoid questions that are easy to guess, such as which state you opened your bank account in. All of these are, of course, stopgap measures until we find better ways to prove our identities online.

It's also critical to remember that once you put data online, it's almost impossible to delete it later. The more you blog about yourself, the more details you put in your social networking profiles, the more information about you is being archived, copied, backed up and analyzed almost immediately. Think first, post later.

As for Kim, she's still blogging, but now she's a little more careful about the information she volunteers and has cleaned house on her old passwords and password reminder questions. Next time I do this, I'll have to figure out the name of her favorite primary school teacher.

By JF
July 24th, 2009
Posted in Security
136 views

JF's security (and other things) log

How to rework your network infrastructure for security

Streaming TV channels for .nl

Malware IN Registry a.k.a If It Can?t Be Done, Why Am I Looking At It?

Identity theft ? knowing me, knowing you

How I Stole Someone's Identity

JF's security (and other things) log

Search

Categories

XML Feeds