Posted: 10 Aug 2008 07:43 AM CDT
Mark Bristow gave a presentation on his ModScan tool at Defcon. Control system community attendees where underwhelmed, which is not necessarily a bad thing. Evidently this tool did little more than identify if there was Modbus server on TCP/502 and discover the slave ID.
What is odd about this is there has been a much more full featured Modbus scanner available for at least two years. Under an I3P program, the University of Tulsa developed a Modbus scanner that not only identifies Modbus servers, but also does a complete function code scan. After that is scans the coils and registers to determine the points list.
We played around a bit with it last year, and it worked will on some Modbus servers, but not all. Where it failed was it did not provide consistent results on certain PLC’s, mainly because of delay issues in a SCADA network as opposed to a lab or DCS. I believe Tulsa has done more testing and addressed these issues.
The black/gray hat events seem to be a bit desperate to get a “SCADA” talk in the agenda that quality control suffers.
Posted: 10 Aug 2008 05:53 AM CDT
A team of superheroes known as "the Squadron of Justice" protect America with their awesomeness and superpowers!
Finally, a team of heroes has decided to defend all that is good and just on our networks. It's not anymore Marty Roesch of Snorting fame, it's not Markus Ranum, it's not Thomas Ptacek, it's not me either.
It's the Squadron of Justice. Stay tuned.
Posted: 09 Aug 2008 06:00 PM CDT
It's blackhat days, we all know. And Alan's blog has been hacked. More precisely the whole security bloggers network at feedburner has been hacked, badge modified, image modified and injuries added.
I realized while visiting my own blog, and viewing the new badge image:
There was no need to add those horrible a** [...]
Posted: 09 Aug 2008 08:38 AM CDT
Posted: 09 Aug 2008 08:00 AM CDT
Posted: 09 Aug 2008 07:25 AM CDT
After a long day yesterday, which featured 12 hours of travel, 3 hours of time difference, 4 hours of sleep, 2 hours of pre-con breakfast, 6 hours of convention and 4 hours of post-convention, I am now awake at 5am (pacific time) in my hotel room. Since this as good a time as any to get my thoughts together, I figured I'd try to get some itemized comments out
Posted: 09 Aug 2008 12:33 AM CDT
Seriously? Why? If you haven't been keeping score, the 'hackers' who set of various viruses, worms and other malware over the past several years just can't seem to spell right, and clearly don't have any regard for proper grammar...
As I was reading about this latest FaceBook "worm"... I came across an article on TechCrunch that details some of the messages being left on the "wall" of hacked users. The messages are hillarious..
."LOL. You've been catched on hidden cam, yo"Who writes like that?
This isn't the first time, and definitely won't be the last time some [presumably foreign] hackers have had incredibly poor grammar and spelling... oh well.
Posted: 08 Aug 2008 10:59 PM CDT
Posted: 08 Aug 2008 06:14 PM CDT
Posted: 08 Aug 2008 10:47 AM CDT
Tenable recently announced an additional feature for the Nessus compliance checks — support for WMI (Windows Management Instrumentation). I have used WMI for some scripting in the past and even played with WMIC. Still I wasn’t sure how or if this capability would help with Bandolier so I decided to use the WMI Object Browser to do some investigation.
The first thing that caught my eye was the Win32_UserAccount object group. Since most control system applications leave some default accounts behind, verifying that they have been removed is an important part of an audit. In *nix OSes, we’ve been able to do this very easily with the passwd file but it has been a challenge on Windows. Could WMI and Win32_UserAccount give us a reliable equivalent on the Windows side? I was disheartened by my first tests which looked like this:
The problem: the check always reported compliant, even when the account existed. Since there were other accounts that were not equal to operator1, it passed. The check type “CHECK_NOT_EQUAL” was functioning as designed, but not how I wanted. Thanks to some guidance from our friends at Tenable, I realized that what I need to do is combine CHECK_EQUAL_ANY with some condition checking like this:
Success! This yielded the results we were after. We now have a more reliable way to test for default accounts on Windows servers and workstations.
I plan to spend some more time with WMI to determine what other information may be useful for Bandolier checks and will keep you updated.
Posted: 08 Aug 2008 09:16 AM CDT
Posted: 08 Aug 2008 09:02 AM CDT
Unfortunately, I'm not at BlackHat/Defcon this week so I don't have any really cool stories about 0-day attacks, vendor parties or Vegas. However, its been a week since my last post so I thought I'd put something on. (In reality I'm avoiding writing a report.)
Khallenge has come and gone. I was able to get through the first level in 36 minutes. Not bad, but I should have been able to do better than that so I'm personally disappointed. The level 1 password was XOR's encoded so it was pretty easy to find once you found the right section of code. I got level 2, but due to other pressing issues (ie. work) I was unable to finish it. I'm pretty sure the password was RC4 encrypted, but I'm not 100% sure. I'll have to wait for F-Secure to post the results.
One funny thing did happen during the contest. At one point something happened to the Khallenge website and the directory index came up instead of the page. Using that I was able to download all of the contest binaries. F-Secure fixed it pretty quickly and changed the directories the binaries were in.
Because of agent0x0, who is living it up in Vegas as we speak, I've become addicted to Twitter. I have to admit I was skeptical at first, but it is a great tool for information sharing and meeting others in the field, as well as just fooling around. Whats worse is that I have my phone hooked up to it now. :) If you're on it, follow me.
Posted: 08 Aug 2008 08:31 AM CDT
Clear® Registered Travel Program and Verified Identity Pass, Inc. CEO Stephen Brill released the following letter to his customers today. In statements made in the email, he makes it quite clear that no one logged into the system, so no data was compromised! FAIL.
Evidently he is unaware of digital imaging techniques and tools. Someone please give him a call and relieve him of his information security security mis-conceptions and ask him to demand full disk encryption on all systems at Clear®….and now the letter:
Posted: 08 Aug 2008 02:00 AM CDT
The second and final day of Blackhat has come and gone. Some good presentations today, and probably more interesting to the critical/control system area of security. The activity at Defcon is already starting to pickup, and lots of parties going on tonight from the major and minor players and generally a lot of winding down for the presenters.
I started the day with a great presentation from Felix Lindner on forensics in Cisco IOS. Essentially examining full memory dumps, and some of the configuration and debugging techniques available on IOS. This is something that I think we could see applied to PLCs, assuming the PLC has some sort of rudimentary debugging interface it could be trivial to checksum the RAM/ROM and detect changes, both intentional and unintentional. Also interesting pickup from the presentation is that there are estimated to be somewhere in the neighborhood of 100,000 different IOS builds out in the wild and approx 15,000 of which are currently supported by Cisco.
Travis Goodspeed has done some interesting work on dumping and reprogramming the firmware on the MSP430 microcontroller. Fascinating research, but honestly I didn’t have enough of an electrical engineering background to completely understand it, lots of waveforms.
The SCADA fuzzing presentation was interesting. There was a lot of buzz leading up to the talk and rumors floating around about vendor lawyers and court orders, but in the end the presentation was given. Essentially Sergey Bratus of Dartmouth College, working with TCIP was able to cause a lot of damage to some real SCADA systems. With no real knowledge of the proprietary protocols Sergey was able to use some compression techniques along with some evolutionary fuzzing to completely crash the system. No details of exploits and such were given, and the presenters were careful not to give any real details about the vendors affected. There is quite a mess of protocols floating around these critical systems and anyone who’s looked at them knows that they aren’t exactly the cleanest/clearest, and the only solution to that is open and peer reviewed standards. A lot of side talk after the presentation about asset owners pushing vendors, and government intiatives/requirements.
Lastly, there was a big announcement from Microsoft. I was unable to attend as I was in the SCADA talk above, but it appears that they’re going to begin sharing information with customers and partners on a more official basis. From the Q&A that I caught the last bit of there seemed to be hints of MS working with 3rd party software developers to fix vulnerabilities in their software running on the Windows platform. Few details were given, and they were clear that they wouldn’t be acting as a CERT, but clearly they’re preparing to be more involved with the process. I have to think that they’re going to be most interested in Enterprise software, but without a doubt there will be some interested in critical systems as well. It will be interesting to see how the program shapes up over the coming months.
Thats all for now, the chaos of Defcon really gets going tommorrow, should be some interesting stuff, and one very interesting on involving cell phones.
Posted: 08 Aug 2008 12:00 AM CDT
Posted: 07 Aug 2008 10:59 PM CDT
Posted: 07 Aug 2008 08:14 PM CDT
As you are reading this, my flight back to ATL should be climbing up through 10,000 feet on my way back home. Another year, another Black Hat, another set of things that are sure to kill us somewhere down the line, another few parties, and another frantic ride back to the airport.
Day 2 was a bit more sedate than Day 1, though that may have more to do with my hangover (that I finally chased away about 3 PM). I also skipped the keynote, though I heard it was pretty good. Here's a brief rundown of the sessions I did today.
And that's all she wrote. Back to a regular publishing schedule next week. Enjoy your weekend.
Posted: 07 Aug 2008 08:01 PM CDT
Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security." Here is an issue #6, dated August 7th, 2008.
Posted: 07 Aug 2008 06:39 PM CDT
Posted by Cody Pierce
Anti-reversing tricks have been around for a long time. They most commonly occur in malware or spyware applications. However, in recent times more applications are incorporating them into their code. This might be to thwart reversing of intellectual property, or perhaps modification of the binary at run time. So today we take a quick look at some of the most common categories anti-reversing techniques fall into, and a few examples from each type.
MindshaRE is our weekly look at some simple reverse engineering tips and tricks. The goal is to keep things small and discuss every day aspects of reversing. You can view previous entries here by going through our blog history.
Anti-reversing tricks are pieces of code added to a binary that deter a disassembler or debugger. In general they serve no other purpose to the execution of the program. These tricks generally fall into several categories that we will cover. It is a good idea to have a cursory knowledge of several anti-reversing tricks in case you come into contact with them. If you are doing malware reversing then knowing these is imperative. Otherwise you could find yourself wasting hours going in circles.
I have come up with the following categories of anti reversing tricks. I am aware that there are many more, but in general these are the ones I see most often. Look for a more complete list and discussion in the links following this post.
- Debugger Presence Detection -
Detecting the presence of the debugger is probably the number one method of anti-reversing. This is done via Microsoft APIs, internal structure flags, window titles, and anything that might tell an application it is being debugged. Lets first look at some of the Windows API calls that will give us up quickly.
IsDebuggerPresent() is the most common API that is used to detect the presence of a debugger. It is the easiest to use, returning true if we have a debugger connected, or false if we do not. Here is an example.
004012E1 call IsDebuggerPresent
004012E6 test eax, eax
004012E8 jnz DebuggerPresent
An obvious way to get around this is to patch any jump that occurs when this returns true. The problem with patching in this manner is you may be doing it hundreds of times. Lets look at what the function IsDebuggerPresent in kernel32.dll does.
7C813093 IsDebuggerPresent proc near
7C813093 mov eax, large fs:18h
7C813099 mov eax, [eax+30h]
7C81309C movzx eax, byte ptr [eax+2]
7C8130A0 IsDebuggerPresent endp
A little understanding of the windows internals tells us that fs:18h is a pointer to our current threads TEB data structure. Knowing this we can see that TEB+0x30 is a pointer to our process PEB. I know this is a hassle, but at PEB+0x2 we can see what is being checked by IsDebuggerPresent.
0:002> dt _TEB 7ffdd000
+0x000 NtTib : _NT_TIB
+0x01c EnvironmentPointer : (null)
+0x020 ClientId : _CLIENT_ID
+0x028 ActiveRpcHandle : (null)
+0x02c ThreadLocalStoragePointer : (null)
+0x030 ProcessEnvironmentBlock : 0x7ffdb000 _PEB
0:002> dt _PEB 0x7ffdb000
+0x000 InheritedAddressSpace : 0 ''
+0x001 ReadImageFileExecOptions : 0 ''
+0x002 BeingDebugged : 0x1 ''
We can easily verify this like so
0:002> db poi(7ffdd000+0x30)+0x2 L1
BeingDebugged is a flag that is set when a debugger loads, or attaches, to a process. This is much easier to fix on a global scale. In our debugger we can simply load/attach to a process and at initial breakpoint do the following.
0:002> eb poi(7ffdd000+0x30)+0x2 0x0
0:002> dt _PEB 0x7ffdb000
+0x000 InheritedAddressSpace : 0 ''
+0x001 ReadImageFileExecOptions : 0 ''
+0x002 BeingDebugged : 0 ''
That will fix any calls to IsDebuggerPresent, or any checking of the internal PEB structure.
CheckRemoteDebuggerPresent is another API that is frequently used to check if a debugger is attached. This one works slightly different than IsDebuggerPresent. It takes a handle to a process (can be current process or remote process) and returns the value in the pointer passed to the function. The way it works is by gathering process information via NtQueryInformationProcess.
7C859B35 lea eax, [ebp+arg_0]
7C859B38 push eax
7C859B39 push 7
7C859B3B push [ebp+arg_0]
7C859B3E call ds:_imp__NtQueryInformationProcess
This call will request the PROCESSINFOCLASS.ProcessDebugPort dword from the kernel. If we have a debugger attached this will obviously not be zero. Since this is handled by the kernel defeating it may be a little harder and might include patching, or running with a modified kernel32.dll (Which is what I have done before).
Another, more novel, way debuggers are detected is by checking for the presence of the debugger applications window name. This sounds cheesy but it happens sometimes. Calls to FindWindow() with the target debuggers window class name can tell the application if the specified window exists. This is not as efficient as the others, since you have to specify the proper window name for each debugger you want to detect, but it is something to look out for.
- Timing checks -
Timing checks involve the checking of a time at a certain point in the binary with another later in execution. The point of this is to utilize micro timers like clock cycles to detect that the process has paused for a fraction of time. This can be very useful when dealing with clock cycles. Breaking into the debugger alone will cause these values to be off quite a bit. This can be done at say startup, and then each time a function is called it can check the delta for a possible debugger. One example is the use of the Windows API GetTickCount() to grab the time since startup in milliseconds. Pausing in execution will cause this value to skew since the tick count continues even when the debugger is broken in.
The one I see more often is the Intel instruction rdtsc (read double time stamp counter). This instruction will pull off the clock cycles that have occurred since boot. The low dword is stored in EAX and the high dword of this 64 bit number is stored in EDX. The precision of this lends itself well to detecting how long execution has taken. Lets look at an example of this.
Beginning of process execution.
xor eax, eax
xor edx, edx
mov dword_High, edx
mov dword_Low, eax
Later in process execution
xor eax, eax
xor edx, edx
sub edx, dword_High
cmp edx, dword_Delta
This example is obviously contrived, but in general this is how the timer works when detecting a debugger.
- Binary Modification Checks -
Binary modification happens all the time in a binary. For instance when setting a break point in a function. In a debugger you cannot tell that anything is different about the function, but in memory we are in fact modifying the instructions in the program. As you may know break points are instructions inserted at the desired address (int3). When execution hits this instruction it tells the process to break into a debugger. So behind the scenes we have modified the code portion of a binary by inserting an interrupt instruction.
This is good for people trying to detect the presence of someone debugging the program, and people that may have patched the binary. This is done by having a checksum for the code section of a binary and an associated routine for calculating and detecting if a function has been modified (via patching or a break point).
Another form of detecting writes or modifications of data is through guard pages, or page permissions. Often times the application will set a guard page on the code section and any writes to that page will call through the SEH chain. In most cases this is a minor nuisance, but an effective way of determining code section writing.
- Anti-Disassembling -
While most anti-reversing tricks are focused on live analysis they may also try and trick a static disassembler such as IDA. A good example of this is inserting a jump in a function to a location that contains a valid instruction. The problem occurs when IDA does its analysis. When IDA finds a jump, and a valid instruction at that jump, it will create a cross reference and disassemble the destination as code. The problem is that during execution the jump will not be taken, and in fact the instruction being executed is at a different address. This is easier to see in an example.
004010C0 sub_4010C0 proc near
004010C0 push eax
004010C1 push edx
004010C2 xor eax, eax
004010C4 jnz short loc_4010DB
004010C6 push 2DC431h
004010CB pop eax
004010CC sub eax, 0DB353h
004010D1 ror eax, 10h
004010D4 xor al, 60h
004010D6 ror eax, 10h
004010D9 jmp eax ; 004010de
004010DB mov eax, 310FD3FFh
004010E0 and edx, 0FFh
To IDA, this makes perfect sense. We have a cross reference to loc_4010db and it disassembles to a valid instruction. That has to be right, right? No not really. The jump will never be taken because the xor will always be 0. This should raise a red flag when you encounter an impossible branch. If we follow it to the next branch (jmp eax) we can see what is really happening when the function is being executed. I have added the comment above after calculating eax which takes us to the proper branch at 0x004010de. As we can see this doesn't exists in IDA so we need to fix it. Put your cursor over the invalid instructions at 0x004010db and hit "U" (Undefine). This will turn all the code back into their byte representations. Lets move to the real branch destination at 0x004010de and hit "C" (Make Code). We should see the proper instructions appear like this.
004010D1 ror eax, 10h
004010D4 xor al, 60h
004010D6 ror eax, 10h
004010D9 jmp eax ; 004010de
004010D9 sub_4010C0 endp
004010D9 ; -----------------------------------
004010DB unk_4010DB db 0B8h ;
004010DC db 0FFh
004010DD db 0D3h ;
004010DE ; -----------------------------------
004010E0 and edx, 0FFh
004010E6 mov eax, edx
004010E8 shr edx, 8
If you want you can go and fix up the function and make it all pretty, but in this case I didn't bother. This is a very typical anti-disassembler trick, and can occur in many different forms.
We have covered just a small snippet of anti-reversing techniques. This is always a fun area of reverse engineering because its an arms race. New tricks are invented every day, and new anti-tricks are discovered in response. I certainly had to cut this discussion short as it is a much larger topic than I can handle in a single post. I suggest reading through the following links to get a more in depth dissection of the most common anti-reversing techniques.
I hope you enjoyed this weeks MindshaRE.
Posted: 07 Aug 2008 06:00 PM CDT
You have a package sitting in your shipping department addressed to "U R Owned, INC." ? Well, it may be David Maynor, CTO of Errata Sec, trying to Warshipping you !
In my opinion this is the most clever research I've heard so far in the war driving field. Basically David, is using an iPhone, empowered with passive sniffing tools to make a reconaissance tour of the inner [...]
Posted: 07 Aug 2008 05:11 PM CDT
Well, I’m offstage now having just presented my talk on “SQL Injection for Fun & Profit” at Blackhat in Las Vegas. One of the main aims of the talk was to provide more coverage on the mass SQL injection attacks that started earlier this year (and are still going on). The Internet Storm Center has some good discussion and coverage on this topic from earlier this year. The other aim was to point out some of the ways it could have, and probably will be in the near future, much much worse.
Posted: 07 Aug 2008 04:58 PM CDT
Posted: 07 Aug 2008 04:00 PM CDT
I already mentioned how I like stuff like port knocking. It can’t be used as replacement for other security measures, but it’s a nice way to keep important stuff out of radar. Imagine if you had some SSH daemons remotely accessible when that OpenSSL PRNG crisis started. I saw lots of admins running to replace flawed keys for servers because of that. If those daemons were hidden behind some portknocking stuff, it wouldn’t be necessary to rush.
Today I read some interesting stuff about SPA, or Single Packet Authentication, to protect SOA resources published on the web. I must say that it’s a nice way to avoid too much attention on them. It would be nice to see this being integrated into frameworks.
Posted: 07 Aug 2008 03:37 PM CDT
UPDATE: The 12-page Call for Input document is now posted. It definitely answers the intellectual property question, but will anyone bite on giving away useful IP?
Interesting that they adopted the Level 1 and Protocol certifications levels that we worked with Wurldtech to structure as part of their Achilles Certification.
Finally, it seems like a very aggressive timetable. Intention to submit input must be made by August 15th and input is due by the 31st during a vacation heavy month. 1st draft Embedded Controller SA conformance specification by September 30th.
At the last ISA99 meeting in West Palm Beach, I raised some red flags about a pay to play organization dictating an ISA standard’s structure and schedule. Well this Call for Input is another red flag. Why would any non-ISCI member want to contribute to this effort?
It costs at least $5,000 a year to even participate in an ISCI technical meeting, and the price goes up based on company size. Would you contribute to an unproven, fledgling effort that then makes you pay to even get in the room to work on the specification?
Who owns the intellectual property [IP] of the contributions? ASCI/ISCI has made a point in presentations that the test specifications and certification programs they will develop have value and are ISCI’s IP. And this is wise because creating effective test specs and programs is difficult. But how can ISCI take another company’s input and say they own the resulting IP? I would be amazed if the two prominent vendors in this space, Mu and Wurldtech, would hand over their IP. [FD: Wurldtech is a current advertiser and past Digital Bond consulting client].
As the ISA>ACSI>ISCI efforts have rolled out it appears to me they made two fundamental mistakes.
1. Perhaps the fatal mistake was they started too early. If ISA99 or some other control system security standard that had testable requirements was available they could apply resources to build a test spec and certification program. We are not close to this so now ISCI needs to develop a set of ISCI proprietary requirements and the test spec.
2. ISA viewed this as a significant new revenue source - - my speculation. It is one thing to raise money to cover efforts, but the pay to play aspect is another. First, why did they need all that money? They have not hired a team to write test specs; they are relying on volunteers from member companies. If I’m a member seeing year two dues coming up I’m asking some hard questions.
Also, how would it be viewed if Mu or Wurldtech or Digital Bond or Industrial Defender said everyone contribute non-trivial upfront money to our commercial effort. Not only do we own the IP, but the efforts and results from your benevolent contribution will not be available to the control system community unless they pay up. Admittedly I’m biased as part of a commercial entity, but I’m continually amazed at how non-profit organizations, labs and academia are considered pure when in fact they are equally greedy and ‘commercial’ as everyone else. Nothing wrong with their motives but the illusion of purity . . .
Posted: 07 Aug 2008 03:36 PM CDT
One of the more interesting session I went to yesterday was a talk by Chris Hoff called "The Four Horsemen of the Virtualization Apocalypse." (If you've never read Hoff's blog, you should check it out at http://rationalsecurity.typepad.com/.)
I thought I was keeping a close eye on security and virtualization issues, but this talk illustrated how wide and varied the topic really is. This was not about Blue Pill and it wasn't about having security monitors in the hypervisor - instead he focused on how virtualizing physical devices (e.g. switches, systems) will cause lots of problems for security architects and administrators.
Briefly, here are the four horsemen:
Now, if you want to read the much more thorough version, see Hoff's original post here.
Okay, how does this all relate to the title of my post? Not much. However, much later on day one, things really started rolling.
After being crowded out of the Shadow Bar, a bunch of us ended up over at Casa Fuente (A cigar bar in Caesars forum). Five minutes after arriving, someone spilled a drink in my lap, big fun! It turns out that it was Stepto's birthday, and Hoff makes sure everyone has a drink and we all sing happy birthday to Stepto. Check out part of it, courtesy of Jack Daniel:
Immediately after the toast, Jennifer Jabbusch knocks over a table, falls to the floor and begins having a seizure. Stepto rushes over, trying to help, and just about that time, she flips over and starts laughing - total fakeout! Everybody bursts out laughing.
Shortly after that, they closed for the night and kicked us out and we all headed over to Cleopatra's Barge. There weren't enough seats or tables for us, but I noticed that the "reserved" barge seating was empty. Drawing upon a clever technique (i.e. sometimes called "asking") I social engineered a waitress into letting us have the reserved area. Within mere minutes, several security geeks are on the dance floor, doing us proud.
This leads me to the Four Horsemen of Cleopatra's Barge. (Though I was out there too, I am excluding myself since simply because I can.)
Though our collective dancing does not signal the end of the world, it certainly capped an excellent day
Posted: 07 Aug 2008 01:16 PM CDT
The indictment of 11 people on a mass card theft is all over the news this week. I’ve seen reports about software developed to steal cards, war driving and other stuff that I really don’t know if it’s just bad press or actual facts. There are some good info here and here.
Of course PCI will be brought into the middle of the discussion about the methods used by the group. It seems that the attacks happened a long time ago (2003), but it’s interesting to look into the story with the eyes of the standard. Like, why was so easy to these guys to go into the card data environment (CDE)? PCI has very specific rules about wireless networks, what I’m almost sure that those companies were not following. Besides that, it seems that all that information was being transmitted without proper encryption.
An interesting aspect of the attacks is that they used tools developed specifically to steal card data. In the same way that there are tools being designed to identify sensitive data in order to protect it (DLP tools, e-discovery stuff), tools designed to steal that data will also be developed. I was reading on Hay’s blog today about the Coreflood Trojan. Criminals developed a trojan and deployed that in a clever way to avoid being detected. They used a strategy that we have been using on “penetration tests” for years, to leverage access to a workstation and wait for an domain administrator to log in there to steal his passwords (and the keys to the kingdom). The results? According to Joe Stewart from SecureWorks, “463,582 user names and passwords to more than 35,000 domains. Nearly 8,500 passwords were for banks and credit unions in the United States and overseas. ”
So, we can see that criminals have leveraged the ability to go into large corporate networks with high privileged access rights. They also know what information they need to get, and the technology to look for that is improving everyday. It’s not hard to play the oracle and say that in a near future we will witness some huge scams performed by very organized criminal groups. Welcome to the future.
Posted: 07 Aug 2008 12:20 PM CDT
August 5th brought news of the CRTLD or the Clear® Registered Traveler Laptop Debacle (our new internal acronymical codename for Information Security Incompetence). Evidently, from reports, the machine under discussion, was found in the same office it had been reported missing from…..
Posted: 07 Aug 2008 11:39 AM CDT
Day 1 of Black Hat 2008 is in the books. It's great to see a lot of old friends, and it seems this year (more than the last two) many of the folks I'm talking to are more focused on the networking than on the session. Not me. I'm still fired up about seeing really smart guys discuss what they are up to and give me a lot of food for thought about how we need to continue protecting ourselves.
I ended up hitting almost all the sessions I wanted to, so let me go through some quick observations.
The Mogull and I recorded a quick podcast yesterday as well. We talk about Kaminsky and Hoff's pitches and come the conclusion that basically we're screwed. You can check it out at the Network Security Podcast site.
Before I head off to Day 2, I have to relay my latest Vegas star sighting. To wrap up the night Shimmy, Mitchell, Adrian Lane and I are catching a little late night breakfast at Caesars. Sitting right next to us is Jeff Dye, one of the finalists on this season's Last Comic Standing. You all know what big fans of comedy the Boss and I are, so it was great to see him in person. He's a very nice guy and he really is that pretty. They are announcing the winner of the show tonight, so I told Jeff we'd be pulling for him.
Only in Vegas...
Posted: 07 Aug 2008 10:44 AM CDT
In one of the more heartwarming stories emerging from BlackHat 2008 is Kim Zetters’s quick post at Wired’s ThreatLevel blog. During Dan Kaminsky’s SRO presentation on his recently discovered DNS flaw, his grandmother baked cookies for attendees.He affectionately labels the confections as ‘session cookies‘.
|You are subscribed to email updates from Insecurity Bloggers Network |
To stop receiving these emails, you may unsubscribe now.
|Email Delivery powered by FeedBurner|
|Inbox too full? Subscribe to the feed version of Insecurity Bloggers Network in a feed reader.|
|If you prefer to unsubscribe via postal mail, write to: Insecurity Bloggers Network, c/o FeedBurner, 20 W Kinzie, 9th Floor, Chicago IL USA 60610|