-atlas wandering-
Bloggorama for breaking things

\

• /(75)

Subscribe
Subscribe to a (RSS) feed of this weblog.

Archives


This Blog

atlasutils-2.2.19.tgz

release: grok-DerbyCon2014-final.pdf
latest grok-DerbyCon2014-final.pdf downloadable here

@

[] permanent link / /

New Location, same zany wacky wierdo!

Well, you made it here. That's the first hurdle!
Many thanks to Kurios for the use of his blog-space over at blogspot. He should be moving over this way soon too...

New feature: RSS Feeds!
So you don't like checking back all the time!? Well, feed the link at the left side here into your favorite RSS reader and you'll see the latest headlines. That's something Blogspot doesn't seem to offer.

Nothing new to report. Family responsibilities, getting ready for vacation, holidays, and on-call at work have made this a very interesting month, to say nothing of the GoogleHacking course I taught tonight (yes, the night of my first day of vacation... not likely the wife's going to forgive that one any time soon).

The class went pretty well, although there were a couple guys unhappy with the content. I'm going to see if I can't make it worth their while and do some more stuff behind the scenes. I started a mailing list for the class. Kinda silly since it was a one-nighter, but it introduces some interesting possibilities. We'll see how that goes.
They want to know when I can do more, but all that work for a very small amount of money... not sure. Great fun, though. I do love teaching. But all the prep work involved makes it pay less than my day job. Maybe I can improve on that next course. We'll see.

I haven't decided my next target for hacking yet. I'll have to decide that when I get back from vacation.

Ciao,
@

[] permanent link / /

release: rfcat-bt5r3-install.sh
latest rfcat-bt5r3-install.sh downloadable here

@

[] permanent link / /

longtime no post
Yes, thank you for noticing, I've not posted in a while. And with good reason. I'm afraid I still have not had the time to post more about fucktcpd, so if that's what you're looking for, don't bother reading the rest of this post.


I recently did 4 interviews with a large security company only to be turned down. They had four positions and apparently I wasn't in the top four. The friend who got me to interview tells me I was close, but he's a friend, what's he gonna say? There are potentially other jobs I could do there, even perhaps better matching my "break things" direction... we'll see. They seem too busy to talk to me, which I can understand. They're starting a brand new department.
Bottom line is I'm content in my current job and that may be why I didn't make the top four... :(

Meanwhile, back at the ranch, we've had kids sick and me sick within the last few weeks. We're all doing much better though. And the family is great. I'm very thankful. I wish I could say I made it out without an inappropriate encounter with the toilet, however :/

My consulting/network appliance business has kept me busy. I've much to learn about the low-price appliance market, and I've already learned so much. The appliance cost and maintenance costs must cover the amount of work it generates or you end up doing a lot of stuff for free! :\ My wife kept me from mass marketting the thing a couple years ago. I'm kinda glad she did, given some of these lessons I'm having to learn. We are waiting until such a time as it makes sense (time-wise)... if that ever happens.

Meanwhile, I've been working to get the v2.0 of the product ready. It's a shift from one major distro to another completely different distro of Linux for its base. That is proving interesting. I am glad I'm doing the shift now rather than later. The switch is getting it off an RPM-based distro onto a DEB-based Ubuntu platform. This gives me a better update mechanism. That's always been a problem. If I wanted to make my own updates it was always having to hack into SuSE's online update mechanism which is proprietary. Debian distros are all using APT, which is just as easy to package for and much easier to maintain a software repository.

Anyway, I'm probably 3/4 way through the major refresh of the build package, which handles all the building/configuring events. I have some holes to fill in for the Modem and DSL connectivity pieces, and a few other areas to be completed. Then I move into the "spot-check" phase, where I test every major subsystem to see what doesn't work right. The todo list then serves as the countdown to pilot (which is where I convert my own systems one-by-one). Somewhere before then I have to work out the inplace upgrade process, where all the hard drive locations get moved into the new locations (as the Ubuntu packages often place things in different locations than SuSE).

Meanwhile, I'm reading "Reversing: Secrets of Reverse Engineering". Seems pretty good so far. I'm only into the second chapter, but it promises to be very good. I'm also reading The Shellcoder's Handbook, and Hacker's Disassembly Uncovered is next on the list.

Meanwhile, I have a singing gig in a few weeks..... A friend of mine and I are doing a duet "Never Alone" by Barlow Girl (yes, we're male-ifying a girl song)

Meanwhile, I've been working to come up to speed on PyElf, and contribute a little bit. It tears apart an ELF binary and should allow you to modify it and put it back together when we're done. This is a project lead by Visigoth and Metr0 from Kenshoto.

Meanwhile, I've put together a proposal for a DefCon 14 presentation and tool release. So I've been updating my hack-assistance tools and am going to package them and release them at dc14 if I get selected.

Meanwhile, I've taught myself Python which is an awesome language. My day-job is getting me to learn C# and VB.NET. And a part of me would like to learn Ruby someday. Perhaps I should do it, since I clearly don't have enough going on. :)

Meanwhile, I'm going to be teaching SANS 504: Hacker Techniques, Exploits, and Incident Handling soon. This was how I got my start into this world. I'm *really* geeked! I just finished mentoring this same course, which of course was 12 weeks long (normally 10 weeks). I've been wanting to teach this class since I took it with Ed Skoudis. I'm no Ed... but I guess neither was Ed when he started ;)

Meanwhile, the day job has got me doing a wide array of things, some still relatively new to me, some old hat. From configuring Wireless bridges to firewall design and maintenance, to application security assessments, etc... they keep me busy. We are doing a good deal of systems design and replacement of legacy core systems. And they have me involved during various phases to ensure security is designed in. They've also got me doing security audits on existing systems, and code audits will be the next step (which of course is the direction I'm enjoying). That's why I'm learning C# and VB.NET, so we can not only point out issues, but come to the table literally speaking the developers' language. Granted, I'm learning it a bit differently than they are ;) But you can't expect every Windows developer to learn on both Visual Studio *and* Mono, nor to spend the time disassembling the IL. ;)

Well, time to head. I wanted to let both of my readers know why they haven't seen any new posts in a while. The job-interviewing and stuff really took it out of me. I picked back up the deadlisting of fucktcpd, though. We share overcome. It's enjoyable ;)

[] permanent link / /

Where the Code Has No Name

(To the tune of "Where the Streets Have No Name" by U2)

You might want to run, You might want to hide
I'm gonna tear down the walls that hold me inside.
I'm gonna reach out, and land a NOP sled where the code has no name.

I'm gonna point EIP anyplace.
I've seen the dust cloud disappear and seen your disgrace
There ain't no shelter from the poison rain where the code has no name.

Where the code has no name. Where the code has no name. I been building a code library
And when I take over, I'll pwn all of you... All I can do.

Buffers o'erflow and our love turns to rust.
Your reputation is dead and trampled in dust
I'll laugh in your face, flyin' high in cyberspace
Where the code has no name

Where the code has no name. Where the code has no name. I been building a code library
And when I take over, I'll pwn all of you... All I can do.

[] permanent link / /

Hacking the Word

The last three weeks have been amazing and awful at the same time.

Two and a half weeks ago my wife and I picked up our adoptive daughter from the hospital! She's wonderful and tiring. Why did we do this? Kids need a loving home. Not all of them get them. Why a newborn? Wow... good question. Newborns are the reminder that something can be wonderful and terrible at the same time. Baby Diva is an adorable little girl, mother from Zimbabwe, father is African-American. Aparently finding adoptive parents who are willing to adopt interracially are few, so we found out about our little wonder the day of our homestudy (the last part of adoption before the infamous "holding pattern"), 10 days before her due date! Standard time for waiting is between six months and two years. We are very blessed.

The wonderment did not stop there. And Biggel(her handle) is only responsible for half of my sleep-deprivation.

Friday, June 3rd saw the 10pm kick-off of the DefCon Hacking Capture-The-Flag(CTF) competition qualifying round. The new carriers of the DefCon CTF flag is the KenShoto group, and my hat's off to them. They did a great job!

Like a moron, I invited college friends to bring their three kids to visit for the weekend. They are not hackers... So, in order to avoid being rude (and incurring my wife's wrath) I relegated my hacking activities to post-bedtime... Friday and Saturday I didn't see the pillow before my ordinary alarm-clock setting. Surprising how 5:30am looks similar whether you're getting up or going to bed ;)

First stage was fun, with an easily hackable web-application using a hidden field and limited input-validation. It just took the appropriate amount of poking and guesswork. Finding the key was easy, so long as you took the logical route of grabbing /etc/passwd for all the information it contains. To be honest, I missed it. The "flag" was stored as the name of one of the users. I apparently was too busy looking for "real" information. In that respect, it was somewhat of a gimme, on the way to really hacking. I had already cracked a password and logged in before actually seeing the stage 1 key. The stage 2 key was provided when I logged in with the hacked user account. I was having fun already.

Stage 3 was much more difficult, and thus ultimately much more rewarding, and a great deal of the wonderment of my week. Logging into the account to get the stage 2 key, a binary file was pasted to my screen, the screen was blanked, the key was printed to my screen and I was logged out. Hmmmph.

That binary, upon inspection, appeared to be the program offering a service on port 6969. Attaining stage 3 meant finding a vulnerability in the binary and writing a remote exploit. As a talented security professional, this was still the territory of immortals. I nearly gave up when I realized what was required. I didn't.

I've been reading Erickson's book, "HACKING: The Art of Exploitation". Great book, but I had hit a dry patch (and been distracted by many other aspects of life) about page 20. It was dry because I knew it already... Given the challenge at hand, I looked in the table of contents to find buffer overflows (BOF) (which is the vulnerability-type I had determined to use). It started on page 23. DOH! So I quickly started back at page 20 and continued into the section on exploiting BOFs.

HTAE not only includes in-depth discussions of the hacking techniques, but provides examples which you can test and play with. Hands-on hacking. Nothing over the network (at least not where I was reading), but definitely enough to get started. That, coupled with a VMware installation of FreeBSD (the OS used on the "hackable" machine) and some debugging/reverse-engineering tools, and my blood/sweat/tears created a wholely original exploit (ok, so the payload was gratuitously stolen from the MetaSploit framework, thanks guys!) but I made the mechanics work.

I felt as if Ben Kenobi himself patted me on the shoulder and said "You've just taken your first step into a bigger world." But it was the KenShoto guys (Snit, Invisigoth) who congratulated me. I think they took pity on me, since they realized I was a sploit-virgin.

Hacking the Word: The process of learning more and understanding the scripture better than the average joe. Hacking is about knowledge and understanding, exploring and devouring. The use of such knowledge is really superfluous to the actual meaning of hacking.

Hacking the Word is going beyond the normally accepted platitudes and trite phrases of religiosity, much like poking and prodding IIS to see what undisclosed "goodies" it has to offer, past that which mere mortals choose to accept. Much like Hacking computer systems, Exploiting the Word lies in how you make use of it. Scouring the Word to find the unknown gems (or just proving them for yourself) will yield interesting brain-fodder for discussion, digestion, and a perspective which is lacking in this world of despair and mortality. 'leet Word-Hackers find riches without the threat of prison (at least for the moment). Hacking the Word can be more difficult and even more intriguing than computer hacking. In order to understand the Word, it takes more than just finding an unchecked buffer and overwriting a return address. It requires context, which means that an understanding of the whole source code is important. That's why hacking teams are formed, which are able to bring the experience of many to the table for discussion. Often these hacking groups are lead by experienced Word-Hackers, but they tend not to be exclusionary. leet-ness is gained through knowledge, not exclusion. The best line I've heard from one of these groups is "Don't take _my_ word for it. _Prove_me_wrong_!"

About a year ago I was introduced to new toolz and introduced to a new methodology to studying the writings of God's dudes (aka Biblos or the Bible, which means book). I attribute the new toolz and methodology to divine inspiration since nobody really "taught" me. I was met with a new way to get depth of understanding, at the same time I found a driving passion to learn more that what I'd been taught growing up.

The ensuing "devouring" of the Word lead to intriguing discoveries and understandings. Many of the principles had been taught me since birth, but the context and word-origins were refreshingly new and gave me the ability to take a skeptic's view on the "obvious" meaning.

What were these toolz of mine, you ask? The Sword Bible libraries and modules, front-ended with BibleTime bible-study software.

The Sword provides many types of modules in many different languages. Being Open Sourced and openly available, the NIV is not an option (apparently the copyright owner supports a lot of missions work with the royalties). I've found I like the WEB (World English Bible) for readability. I tie that to the King James Version (yes, like a parallel bible) because the KJV has ties to "Strong's Numbers" which are an indexing and definining of the original Greek or Hebrew words! Talk about using the Source, Luke! Since I have not been able to learn either of those langauges to any real extent, using the definitive definition, and being able to compare word numbers between verses with like words, has been incredibly eye-opening. English jumbles and combines words; for instance, there are 8 definitions of "Love" in the Hebrew language, two definitions of the verb "to Know" in Spanish, etc...

Kate has also added to my experience! Kate is the MDI advanced text editor of the KDE project. Why does Kate make that big a deal? Well, I've been pretty lax about taking notes during BibleStudies and Church Sermons. Kate makes it simple to at the *very least* keep track of Bible verses in use throughout the teaching. That way, even if I don't agree with the interpretation or usage I can always return later and do more digging. Since that time, I've found a reason to get up early in the morning and spend time with the Architect, learning about the Creator and communing/submitting myself to His will. In fact, that's where I'm going right now.

Oh, by the way... I believe I have qualified for the Capture the Flag in July! So, if you're in Vegas the last weekend of July, stop by Def Con and we'll meet. You can email me ahead of time at atlas_THAT_AT_THINGY_r4780y.com

@145

[] permanent link / /

atlasutils release: atlasutils-2.2.19.tgz
latest atlasutils downloadable here

@

[] permanent link / /

Stick a fork in echod

echod is now on life support only. Officially dead, I now wish to clean up my sploit to have it continue execution. We'll have to see about that one. :\ Can't say I've ever written a sploit to return, but this seems like a great time to start.

It's actually been a week since I've been able to touch it, so I'm not feeling quite as lame as I was last week. Work has extended into the evenings and then there was the wedding I had to liven up :) (kudos to Ryan and Rachel!)

This round in my fight with echod was much less confounding. I had already structured the exploit code so I could tinker with the header (as the term suggests, I'm speaking of the initial set of bytes which hold the address to overwrite the return pointer and some other goodies used to reconstruct the stack... remember that everything is reversed). The string dynamically generates NOPs to correct the buffer size from any changes.

Since that was already in place, I simply pumped some net-bind shellcode through "reverse()" and appended the resulting string to the sploit header (thanks again, Metasploit!). This broke stuff at first. It seems some of the memory the shellcode was occupying gets altered before execution. Solution? Add some NOPs after the header, before the shellcode, and check again. I ended up using 96 (nice round number) NOPs for this as 32 and 56 were not enough. Surprisingly, that provided a stable/consistent exploit.

As an exercize, I then wrote three while loops:

*) one to check the service and restart it if dead

*) one to run the exploit, connect using netcat, read, then overwrite a simulated "key" file, like in the CTF

*) one to check the "key" file and overwrite it with the correct value if overwritten

These have been going now for some time and working quite nicely. Now, I just need to turn my attention to returning gracefully. I believe the appropriate course of action is to "mov 0x<someaddress> 0x4(%ebp)" and then call "ret" instead of calling "exit()". We'll see how that works out.

I'll let you know. I feel awful right now and am driving home from Skelletones, so coding has stopped. Between the fog and deer-hazards, blogging is all I can manage! Perhaps if I felt better ;)

@

[] permanent link / /

Stack Rebuilding

Well, as for the "next target", I've selected visigoth's "fucktcpd". But that's another post. Right now I wanted to share a little about rebuilding echod's stack so it returned properly.

*) Start with the basics (I know nothing about this, so I'm feeling my way): Returning in the program
A quick backtrace from the "reverse_echo_cmd" sub (using the debugger gdb) shows that returning correctly should send the instruction pointer to 0x804916a.
Hmmmmm, I know that at the beginning of each sub is a

push %ebp
mov %esp,%ebp

and checking the contents of the stack show the address at %ebp+4, aka 0x4(%ebp):

13: x/32xw $ebp - 92
0xbfaedeec: 0x00000000 0x00000000 0x00000000 0x00000000
0xbfaedefc: 0x00000000 0x00000000 0x00000000 0x00000000
0xbfaedf0c: 0x00000000 0x00000000 0x00000000 0x00000000
0xbfaedf1c: 0x00000000 0x00000000 0x00000000 0x00000000
0xbfaedf2c: 0x00000000 0xbfaedf50 0x0804c6bb 0x0804c6bc
0xbfaedf3c: 0x00000000 0xbfaedfec 0x08054700 0xbfaedfb8
0xbfaedf4c: 0x0804916a 0x00000004 0x00000002 0xbfaedf70
0xbfaedf5c: 0x00000000 0x00000000 0x00000000 0x0804a748
(%ebp is in bold and 0x4(%ebp) is shown in italics)
We already knew this since that's the address we had to overwrite. We'll refer to this snippit later on as we clean up the stack.

So I set a breakpoint at the "leave" instruction for this sub. Then, allow the instruction to execute using "si".
I'm next left with the stack looking like this:

14: x/32xw $esp
0xbfaedf4c: 0x0804916a 0x00000004 0x00000002 0xbfaedf70
0xbfaedf5c: 0x00000000 0x00000000 0x00000000 0x0804a748
0xbfaedf6c: 0x00000002 0x0804a900 0x0804a904 0x00000000
0xbfaedf7c: 0x00000000 0x00000000 0x00000000 0x00000000
0xbfaedf8c: 0x00000000 0x00000000 0x00000000 0x00000000
0xbfaedf9c: 0x00000000 0x00000000 0xbfaedf70 0x0000007d
0xbfaedfac: 0x00000004 0x00000000 0x00000000 0xbfaedfd8
0xbfaedfbc: 0x2807faf1 0xbfbfecc4 0x00000000 0x00000000
13: x/32xw $ebp - 92
0xbfaedf5c: 0x00000000 0x00000000 0x00000000 0x0804a748
0xbfaedf6c: 0x00000002 0x0804a900 0x0804a904 0x00000000
0xbfaedf7c: 0x00000000 0x00000000 0x00000000 0x00000000
0xbfaedf8c: 0x00000000 0x00000000 0x00000000 0x00000000
0xbfaedf9c: 0x00000000 0x00000000 0xbfaedf70 0x0000007d
0xbfaedfac: 0x00000004 0x00000000 0x00000000 0xbfaedfd8
0xbfaedfbc: 0x2807faf1 0xbfbfecc4 0x00000000 0x00000000
0xbfaedfcc: 0x00000000 0x00000000 0x280964bc 0x00000000
(the top part shows the stack starting with %esp. the bottom views the stack so that %ebp is on the right side of the sixth row, or the third from the bottom. in case you can't tell, these are two of my favorite "display" settings in gdb)

Key point: See our favorite address at the very top of the stack. After poking around, the "leave" function reverses the beginning of the sub:

mov %ebp, %esp
pop %ebp


All that's left to do after that is to return to the calling function...
So, when we're done with the shellcode (I broke the execve() call to tinker), we'll simply push 0x804916a and then ret... Let's try it:

push $0x804916a
ret


This did indeed return me into handle_client where we left off, but I get a segfault soon thereafter.
hmmm... it appears we have thrashed the stack, and must so some rebuilding.

Comparing at the start of the NOP sled to post-shellcode (sorry, no screenshots for this one), it seems the shellcode used leaves 0x58 bytes on the stack.  Well, they can't be blamed for not expecting us to return here.  Let's try readjusting %esp like so:
add    $0x58,%esp            ---------------------   clean up stack (messy, messy shellcodeses!)

Comparing again, %esp is where it should be.  %ebp, however, is *completely* smashed.  Remember, the "leave" command did the "pop %ebp"?  Well, my initial sploit overwrote everything up to the return address with "A", so of course, %ebp looks like "0x41414141".  So, I make the change in my sploit to overwrite this space with the correct value of %ebp afterward (which we'll find is a problem later), and a couple other fixes:
$string = "REV \x05\xbf\xae\xdb\x50\xbf\xae\xdf\xb8\x08\x04\xad\x04\xbf\xae\xdf\xec\xbf\xae\xdf\x3d" . "A"x94 . reverse($shellcode) . $NOP;
    (you may wonder about the initial \x05.  The string ends in 0x00, and this byte overwrites the significant part of the next value on the stack: 0x00000005.  By prepending the \x05, we overwrite the *next* byte with the 0x00, which happens to already equal that )

This worked!  However, in the process of figuring this out, I ran across another nifty fact about Multithreadded apps which I'll get into in a few minutes.

So, we have returned into the calling sub, reset %esp to it's appropriate place, and %ebp now returns to its appointed position.  That should be good, right?  wrong.  Don't get me wrong, this was quite an accomplishment, but I'm not quite there yet.  We are returning into handle_client fine, and disconnecting the connection does allow handle_client to exit, and the thread looks like it's about to be recycled... then it SegFaults.  

What?  Hmmmm....  So what are we missing?  Well, apparently the thread destructor does a jmp %ebx or somesuch.... and of course, %ebx is used in the shellcode.  DOH!  So, ok, I'll push %ebx at the beginning of the shellcode, then pop it off later.  That seems to work, at least as far as I have pursued it so far...  More on that later (perhaps in another post).  

The problem that keeps nagging me at this point is as follows:  I'm discovering that this sucker assigns a chunk of stack space for each thread.  So the first thread might be at 0xbfaeXXXX, the second thread is then at 0xbfadXXXX, and the next thread at 0xbfacXXXX and so on.  I can predict where *within that space* the data is going to reside, however, I can't predict what thread I'll get...  And worse yet, this puppy doesn't just affect returning gracefully, this affects exploit execution altogether.  I'm returning into the stack, so that stack has to be the same, or my sploit has to magically change on-the-fly prior to any sploit-execution...  Not very possibly in *this* universe.  I had been experiencing odd inconsistencies on occasion, and it looks like this is the culprit.  
The solution, however, was quite nice.  Ok, so the stack space is dynamic and a change of threads can totally screw up the exploit.  There happens to be a place in memory this data gets copied to for every thread: 0x804a904  
This is shared memory, so it's still possible to run into issues if other threads write to it before we can execute the shellcode, but it's the best things I can find.  One key point: This data is *PRE-REVERSING* so the shellcode has to go back to straight-forward.

So the sploit code starts to look like this:

 $string = "REV \x05\x08\x04\xa9\x50\xbf\xae\xdf\xb8\x08\x04\xad\x04\xbf\xae\xdf\xec\xbf\xae\xdf\x3d" . "A"x93 . $shellcode . $NOP;

We dropped the return pointer a little after the start of the memory buffer so as not to try to execute the "stack repairing" data as code.

Ok, so we can execute code regardless of thread... but now we have the whole return gracefully thing.  If we hard-code the %ebp replacement (as we currently are) we could really cause nasties, as the %ebp for thread 2 would then point to the stack for thread 1!  Not good.   Solution?  

My choice was to compare %ebp to %esp.  Luckily the relationship appears static at this point in the code.  %ebp is consistently 0x68 bytes greater than %esp.  So we just add 0x68 to %esp and we get %ebp, right?  Well, sorta.  There are two tricks to it:

1. We have to make %ebp = %esp, then do the addition to %ebp.
2. We can't simply add 0x68, since that compiles to \x81\xc5\x68\x00\x00\x00 and that is not String-friendly  (ie.  The string ends at the first \x00, boys)
3. We're not only interested in %ebp's location, but also interested in the content there.  This determines the *next* part of the stack trace, apparently 0x20 bytes north of here.

[] permanent link / /