Enlaces

Temas

So, if you are a good postmaster, you probably know about SNDS, JMRP and similar non-Microsoft programs.

I find them extremely useful, and have integrated JMRP into my systems in such a way that I can tell exactly when some email issue affects my customers. Sometimes computers get infected by spam-sending malware, or new employees at some customer’s company start sending email marketing without adhering to company policy.

That’s the good thing about JMRP and similar programs: you can get to know what triggers a “bad reputation”.

SNDS and JMRP are linked by the hip, you cannot have one without the other, and SNDS also offers some sort of automatic status notification.

If you join SNDS (click https://postmaster.live.com/snds/– you will need a Live.com account), then you can add your IP addresses. I suggest you have a proper PTR (reverse dns) record setup, so SNDS will be able to send you the authorization link to abuse@YOURDOMAIN.COM (or hostmaster, postmaster, etc, depends on whois data).

Of those two addresses, one is for an ipStatus.aspx script (they have a special key for your account in the query string). Both scripts return CSV data, or no data if all is well. The web page provides this table (taken from the bottom of https://postmaster.live.com/snds/auto.aspx):

Situation

Response

Success with data rows

HTTP 200 OK and non-zero Content-size

Success with no data for your IPs

HTTP 200 OK but Content-size of zero

SNDS has no data for any IPs for the requested date
(i.e. future date or more than 90 days in the past), or
no sample message of that type for that IP and date

HTTP 204 No Content

Invalid or malformed request

HTTP 400 Bad Request

With that information, I came up with this syntax for check_http:
./check_http -S -H postmaster.live.com -u ‘/snds/ipStatus.aspx?key=YOUR_KEY_HERE’ –invert-regex -r ‘,’

When all is well, zero content is returned with a 200-OK http response. And we know in case of problem, we ALSO get 200-OK http response… but a CSV file in the content. So, by checking for a COMMA, and inverting the regex, we can instruct check_http to give us an OK when there is no data, and CRITICAL when CSV data is returned.

We need to configure this command so we can get it into Nagios, so add this define_command block in a proper location (I keep my specially tweaked commands in a buanzo.cfg file off /etc/nagios-plugins/config, as I keep a good /etc backup and standarized setups):

It might be immediately obvious if you read the Abusing the Past article (link up there ^^).

Basically, if you own or manage a website, or are hired to conduct a penetration test of a website, you probably know what to do. But many people fail to notice that websites have a history, and sometimes the past is definitely more vulnerable, as it is no longer maintained/updated.

Why would an old website still be configured in its old servers? Mismanagement? Bad security practices? Any combination of the above?

Truth be told, an old website (that is how I will be calling a website-still-configured-in-an-old-host in the context of Abusing the Past) contains information and potential vulnerabilities, which could provide access to the current (or present-host) website. Or just be useful for oldhost abusing, weakening a web service provider.

So, let’s define a target. www.example.com

First, you need to setup weblorean. That is quite easy with any current linux (osx too) distro with access to python3. And no, it does not currently work on Windows [TODO: remove pyvirtualdisplay requirement, which is mostly needed if you intend to take screenshots using weblorean, which is very easy to do from selenium-python).

WebLorean is just three files. Two if we take the README out of the equation. The main script is timetravel.py and it takes only one argument: the target.

So, we would run ./timetravel.py www.example.com and get the output.

The script first checks netcraft for the hosting history of www.example.com, which might or might not include the current IP. The second step involves getting the current IP addresses for www.example.com, and removing them from the hosting history IP list. WebLorean then proceeds to make a simple check to determine potential existance of www.example.com on the old servers. Of course, in many cases the past IP addresses might be down. WebLorean makes no assumptions.

If an old host seems to still have www.example.com configured on the server, weblorean will let you know. You should make a note, and start working.

Now, you would create a /etc/hosts entry for www.example.com for the first old-IP that weblorean reports as still configured, and run your web pentesting tools against it. Once finished, edit /etc/hosts, update for the next old-IP, and repeat until you run out.

Of course, if you are just a manager or web designer or some other non-pentesting interested party,you might just want to contact someone and let them know about this situation, which could affect the old web host, and the current web-host, plus anyone involved with the website (owners, customers, employees, etc).

Believe it or not, this technique IS used, and not really discussed much. I mentioned the technique to a couple of colleagues during Ekoparty 2011 (the BEST security conference in Latin-America, www.ekoparty.org) and they all agreed on it.

NOTE: Some people might claim using selenium is an overkill (and I agree), but I consider selenium a tool pentesters should use more, hence my using it in weblorean.

Anyway, as I have always wanted to cluster up all my fail2ban servers, especially without opening security holes between them, I cooked up these set of scripts that use the AWESOME zeromq messaging API: www.zeromq.org

I called them fail2ban-zmq-tools, also known as fail2ban-cluster. It consists of a Publisher, which receives messages from Monitor instances and broadcasts them to Subscriber instances.

You know, it’s not really clear in my mind. I close my eyes and music and equipment/technology go hand in hand. Playing the piano: it was an electric organ, full of lights and knobs and pedals and STUFF. And one of the first things I ever enjoyed doing with a computer was NOISES. Or music. Whatever.

That’s how I learned about ADC/DACs (Analogic-to-digital converters, and viceversa). A magazine here in Argentina decided to ship a printer-port (parallel, lots of pins, wide as hell. damn ESDs!) that allowed applications to abuse an interfaced that converted data into audio. You would plug the other end of the interface into your stereo’s inputs. Oh, that’s called RCA? Good to know. I hate those.

And so, trying to find something that could help me enjoy that interface, other than games… I found MODEDIT.

That was called a tracker. It had 4 channels I believe. Supported .SAM format samples, which you could then use on those four channels, to produce a .MOD file, that you would play somehow.

I used to program tunes using BASIC, playing thru the internal computer speaker. A tracker such as MODEDIT was a higher abstraction layer. Not TOO up there, but interesting enough.

And I played the guitar a lot. And came across more computer software for music production. And then synthesizers. Sequencers. OMG.

Today I found myself in the middle of a long email conversation with a young student from Germany. Someone related to fail2ban, one of the projects I contribute to.

We share a love of music, and security. Somehow, I ended up opening up, and telling my story. How I got into music, programming, Linux, security, and government work.

Professionalism is weird when it arrives, I know.

For instance, I began with Linux in 1994/1995. I was 12/13 at that time. I did not pursue an university degree, as IT Engineering here in Argentina was not in the state it currently is (and still needs MUCH more. How I would love to go back to teaching.).

I was best off by teaching myself! When I was 16-20, I used to write a lot of articles for the local Linux magazine, which I “funded” with other 2 editors (Damian Alonso, Facundo Arena) plus the editorial management staff, of course, from MP). I was in charge of the “Guru” section, programming, networking, etc. So my writings, as there weren’t many spanish-based articles (You can find some of them in www.buanzo.com.ar) at that time, at least in Argentina, ended up in the minds of many people. – And some even in use by one of the national universities, as reading material for their programming / operating systems courses. They called me when I was 19 to teach at that university. I was fresh out of high-school with a diploma in Electronics. I started the CBC, but dropped out. Today, I am really looking forward to finding a career. Probably not in IT, though. Something to expand my mind.

So, you want to become a Hacker. Here are some tips, right out from my personal experience.

#1 Get it into your mind. Hacker means ethics. Hacker means curiosity. Hacker means a desire to improve things. Hacking is fun. And healthy. As I usually say in my talks: “Does any of you drive a car? Does any of you drive REALLY WELL? Oh, so I guess you are probably a killer”.

Oh, so you are good with the computer. That means you are a criminal, right?

Get it straight. Any person can become a criminal. It is not hard. You just need to be a bad person. You can blame any other bunch of factors, but in the end, it means you are evil. Mistakes, that is something else. And you will make many… growing up. And then some. With or without the computer knowledge.

#2 You will need to open up. You can use any OS to do lots of things, but the more multi-platform knowledge you gain, the better. Use Windows. Use Linux. Use more than one OS. This is far easier to do today. Between your game console, your computer and your tablet/smartphone, you already have 2+ OSes, surely.

#3 Break things. Break yourself, too. Pursue a different area of knowledge, a different interest, such as music playing, literature, languages. Try new stuff. Enjoy the experience.

#4 Love those around you. That means respect, too. You will make it easy for them to support your interests, especially growing up. Yeah, I’m sure most people reading this on Linkedin are older, but luckily, some parent is reading this and might share the link.

#5 Find a team to share knowledge with. I suggest a 2600 meeting. http://www.buanzo.com.ar/sec/2600meet.html – You will find what areas of IT knowledge most interest you this way, too. For instance, I love defense, forensics and all things networking/comms, especially authentication and data sharing / analysis. But I get bored with the offensive side of things.

#6 Programming is a must. Stick to a limited number of languages at first. I would suggest python, C, assembler and some C# (it is quite an awesome language from which you will learn a lot). Try to attack your code. Debug as crazy. Attempt to understand why stuff breaks. In 1998 I coded a multiuser BBS for Linux, in plain C. It was the way to understand all things about Linux, as I had to learn IPC, sockets, processes, input handling, locks, filesystem, terminal capabilities, session control, etc, etc. Making it crash, and debugging it, allowed me to understand how an exploit would work. Learning how to code an exploit is also extremely useful, as it gives you the “other way round” knowledge of operating systems and code execution.

#7 Help others. I cannot emphasize this enough: your experience, your knowledge, has no value if you do not find a way to help others, in any way, using any methodology. Be loyal.

#8 Do not allow yourself to be used by evil people. Information gathering, one of the stages of “how to attack a problem”, can be applied socially. Avoid bad actors. But you will find yourself that “know your enemy” is also valuable. Remember I mentioned ethics?

#9 Get out in the open. Analyze your surroundings. Travel. Technology is everywhere, but subtlety is beautiful. Balance.

#10 You will one day die. Try to make the best out of life. Think about what you will leave behind. That is the real, the ultimate hack.

This article I wrote for 2600, was first published in 2600 Magazine (www.2600.com), Volume Thirty-Two, Number One, Spring 2015. As it has now been in physical circulation for some time, I now publish it online.

Enjoy.

Abusing the Past
by Buanzo

DISCLAIMER: If you do evil shit with this information, I hope something really bad happens to you. Information is free, but people are human.

It has been quite a long time since my last article, so I’ll keep it short.

In this day and age, there are mass scanning tools and several easy-to-query databases that make it
a simple thing to find sites with vulnerabilities. Hackers and other agents with all hat-colors use them every day to do their jobs. I will present you today
a very simple technique that will, when certain special circumstances are met, allow you to scan the past for vulnerabilities.

When we want to have a website, we obtain a [sub]domain name, point it to some web hosting server’s IP, and configure it to serve that
website. We also get DNS service somehow. I am sure you’ve done this before, so I’ll skip those details. So now, www.example.com is running on server A.

Yay, we got a website! By the way, it is Joomla or some other CMS like wordpress, etc.

The days/months/years pass, and we find ourselves in the need to move the website to another server, for whatever reason (luckily, cause we have so many
visits the old server cant handle them). The new website is configured on the new server, the DNS is updated, and voila, visits now arrive at the new server.

Nice.

But…

If we go to Netcraft, and check some domain name using their tools, we MIGHT find the hosting history of a website. Yes, www.example.com used to run on server A,
then server B, now server C! And, wow, thats weird, the old servers are still up and running.

So, www.example.com MIGHT still be configured in one of those servers. You know how hosting companies [dont] do their homework sometimes 😉

So, an attacker could fire up a scanner, and by any means available, target www.example.com thru the older IP addresses, and scan our OLD WEBSITE[s],
which, of course, we no longer keep updated (maybe not even the server, for that matter…). And you know what outdated usually means: holes. Lots of them.