*The CIA honeypot Wikileaks mirror * nice dam shit

Yesterday, I posted an item referencing a reddit thread and a widely-retweeted Google search string referencing a purported "CIA wikileaks mirror honeypot" that revealed itself as likely having been set up by the CIA. It wasn't. It was some guy's joke or something.
I'm traveling with wonky mobile internet, and in the process of attempting to update the post with a clarification late last night in a sleep-depped state, I screwed up. The post was deleted. There is no conspiracy here, and no reason to believe the CIA is setting up fake Wikileaks mirrors (though, not a bad idea, amirite?).
However, I can tell you this, no joke: I'm traveling in Texas, in an area with a high Muslim population. Last night, I saw ads on the hotel TV for the CIA. Clandestine services recruitment ads. I googled around, and apparently these are part of a broad campaign that began in 2009, to recruit more Arab-Americans. I can't find the actual ad I saw last night, but here are earlier examples from the same campaign. You may also want to fire up Tor, disable cookies, and take their personality quiz.
No, neither of those have anything to do with a misleading Reddit thread, or me screwing up a blog post. But! The TV ads were so bad (even the aspect ratio was messed up), I thought, yeah, I could believe.
byXeni Jardin

So dont visit this mirror http://wikileaks.psytek.net/ maybe is some trap from CIA hehehheh  or CIA trying doing something survey to find target and then shut down their enemy. and i try to trace their domain and server an this the result :
 13   253 ms   222 ms   228 ms  ge-11-2-0.mpr2.pao1.us.above.net [64.125.12.205]

 14   244 ms   231 ms   284 ms  xe-2-2-0.cr2.sjc2.us.above.net [64.125.31.70]
 15   236 ms   240 ms   262 ms  xe-0-0-0.cr1.sjc2.us.above.net [64.125.30.125]
 16   243 ms   237 ms   238 ms  xe-2-1-0.cr1.lax112.us.above.net [64.125.24.17]

 17   315 ms   317 ms   315 ms  xe-3-2-0.cr1.iah1.us.above.net [64.125.26.121]
 18   329 ms   318 ms   342 ms  xe-2-1-0.cr1.dfw2.us.above.net [64.125.30.58]
 19   365 ms   317 ms   337 ms  xe-1-1-0.er1.dfw2.us.above.net [64.125.26.210]
 20   321 ms   307 ms   307 ms  main1.above.net [209.133.126.42]
 21   362 ms   498 ms   336 ms  vlan907.core7.dfw1.rackspace.net [98.129.84.181]

 22   355 ms   347 ms   319 ms  aggr510a-2-core7.dfw1.rackspace.net [98.129.84.8
7]
 23   347 ms   350 ms   348 ms  psytek.net [173.203.241.80]

Psytek.net - Psytek Whois Information

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.


The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.domain: psytek.net[Who Is Domain]
owner: Brad -
email: [FIND OUT MORE ABOUT THIS EMAIL ADDRESS][Who Is Domain]
address: GPO BOX 3356
city: Melbourne
state: Victoria
postal-code: 3000
country: AU
phone: +613.98541544
admin-c: CNET-466771 [FIND OUT MORE ABOUT THIS EMAIL ADDRESS][Who Is Domain]
tech-c: CNET-466771 [FIND OUT MORE ABOUT THIS EMAIL ADDRESS][Who Is Domain]
billing-c: CNET-466771 [FIND OUT MORE ABOUT THIS EMAIL ADDRESS][Who Is Domain]
nserver: a.ns.joker.com[Who Is Domain]
nserver: b.ns.joker.com[Who Is Domain]
nserver: c.ns.joker.com[Who Is Domain]
status: lock
created: 2004-05-22 21:21:40 UTC
modified: 2009-09-04 13:20:41 UTC
expires: 2012-05-22 21:21:25 UTC

contact-hdl: CNET-466771
person: Brad -
email: [FIND OUT MORE ABOUT THIS EMAIL ADDRESS][Who Is Domain]
address: GPO BOX 3356
city: Melbourne
state: Victoria
postal-code: 3000
country: AU
phone: +613.98541544

source: joker.com[Who Is Domain] live whois service
query-time: 0.007335
db-updated: 2010-12-11 01:36:50
NOTE: By submitting a WHOIS query, you agree to abide by the following
NOTE: terms of use: You agree that you may use this data only for lawful
NOTE: purposes and that under no circumstances will you use this data to:
NOTE: (1) allow, enable, or otherwise support the transmission of mass
NOTE: unsolicited, commercial advertising or solicitations via direct mail,
NOTE: e-mail, telephone, or facsimile; or (2) enable high volume, automated,
NOTE: electronic processes that apply to Joker.com[Who Is Domain] (or its computer systems).
NOTE: The compilation, repackaging, dissemination or other use of this data
NOTE: is expressly prohibited without the prior written consent of Joker.com[Who Is Domain].

Is psytek on dedicated hosting? Check it out - Click here.

Psytek.net - Psytek

Psytek IP:

173.203.241.80

Psytek server location:

San Antonio in United States

Psytek ISP:

Rackspace Hosting

Email Trace

Who owns an email address?

WHO IS? What does that mean?

Everyone who registers a domain name has his personal contact information in a WHO IS database.

Our WHO IS database lets you search for the WHO IS of any Domain.
The WHO IS Entry in the WHO IS database normally includes the name, address, phone number, email address and domain name expiration date of the domain owner.
That means that anyone who lookups an WHO IS entry will find the contact information of the owner. Some domain registrars offer private domain registrations. In this case the WHO IS contact information of the registrar is shown and not the private Informations of the domain owner. Test our WHO IS lookup tool and see how it works.

psytek.net Traffic Statistics

Psytek Alexa Traffic Rank: 804,391

Email Trace

Who owns an email address?

psytek.net Server Location

Full-screen

psytek.net server location:
San Antonio in United States

psytek.net IP address: 173.203.241.80

and everything is change and the website have the screenshot was be down congrat CIA
so what do you think ?

Read More

Network admins must beware of Stuxnet

ometimes with mind-numbing frequency, patches and security advisories from Microsoft, Adobe, and Apple compete for an ever-increasing amount of attention from administrators. Little wonder then, that most will have greeted with a mild yawn the latest announcement of another zero day attack--this one named the "Stuxnet Attack". Just as I was about to file this latest message under "Priority--To Be Reviewed", the sender's name jarred me to attention: Managing Automation.
Managing Automation is a periodical with a healthy Web presence that tends to cover topics from the supply chain, manufacturing, process control, and product lifecycle management. Over the past five years or more, the editorial focus has branched out to cover additional topics more familiar to network administrators: e.g. security event management for industrial systems, defenses against industrial espionage, etc. Despite this new coverage area, Managing Automation topics are rarely vehicles for malware notification. It was noteworthy then, to see author Chris Chiappinelli's story begin with:

Manufacturers worldwide have been put on notice that an insidious virus targeting supervisory control and data acquisition (SCADA) systems is on the loose.
The targets of the malware are Siemens' SIMATIC WinCC and PCS7 software, integral components of the distributed control and SCADA systems that facilitate production operations in many process manufacturing companies…

Those not in the manufacturing and process engineering fields may be unaware of Siemens SIMATIC and PCS7 software. How important was this emerging threat, in a field rife with worries that are sometimes alarmist and self-serving? Important. This time there is legitimate cause for concern.
Wired's Kim Zetter wrote in a post the same day as the Managing Automation announcement that "the emergence of malware targeting a SCADA system is a new and potentially ominous development for critical infrastructure protection". Network World's Ms. Smith quotes F-Secure's warning that the vulnerability poses "a risk of virus epidemic at the current moment". Finally, it may be standard lingo for such announcements, but Microsoft's July 16th announcement of Security Advisory 2286198 advised customers to visit Microsoft's general support portal and to "contact the national law enforcement agency in their country".
All of this was more than enough to get my attention.
While SCADA systems are often not regularly connected to the Internet, they are networked and are subject to the usual array of vulnerabilities. (Promotional Web copy for the Siemens product that is the target of this attack explicitly mentions Ethernet switches and wireless LANs.) Public officials such as Richard Clarke have warned about risks to SCADA systems, but there have been few examples to rally the troops. While the particular vulnerability--a hard-coded password allowing access to the Siemens software's back end data base--is not especially remarkable (though it does both date the software and call into question software quality review processes at Siemens), the malware packs a punch.
Thought to mainly spread by USB stick, or possibly by network shares, it cannot be defeated by simply turning off Windows autorun; simply viewing an infected file system will install the malware. A security specialist at Tofino believes that this zero-day attack, which affects all versions of Windows, may have been in the wild for a month or more. Preliminary assessments indicate that the malware does not appear designed to cripple infrastructure, but rather to steal information from SIMATIC WinCC / PCS7 implementations--i.e., some form of industrial espionage. Of course that espionage could later be used to wreak havoc on these same or similarly configured systems.
Recent press and analyst coverage has addressed both the threats to SCADA networks, and also the broader Windows vulnerability which the worm uses to spread (it exploits a code that interprets Windows shortcuts, i.e., .lnk files). As Microsoft noted in their analysis of the exploit, which has been named the "Stuxnet" threat, this is a new method of propagation which leverages a flaw in the way the Windows Shell "parses shortcuts". Stuxnet has been cataloged as CVE-2010-2568 at Mitre's CVE. For its part, Microsoft has proposed a workaround of sorts, and updated its own detection engines.
There's more
As if that wasn't enough, the attack also involved theft of a signed Verisign digital certificate owned by Realtek Semiconductor. This certificate was used to authenticate drivers needed by Stuxnet when it self-installs, though Microsoft has since persuaded Verisign and Realtek to revoke the certificate. This was the icing on the trojan's cake.
The Dependency Syndrome
What does all this mean? One lesson--not new, but that is borne out by this incident--is that the Internet-centric orientation of most malware models could miss certain types of threats. SCADA vulnerabilities are just that sort of threat. And while infections might not spread directly from them to general purpose networks, those general purpose networks depend upon SCADA systems for connectivity, power--and even human habitability. The "Dependency Syndrome" asserts that connections between traditional networks such as those managed every day by network administrators, and nontraditional networks such as those hosting SIMATIC WinCC / PCS7, will sooner or later be impossible to detect--and defend against.

Read More

Protecting your self from the Firesheep extension

Recently a new plug-in was released for Mozilla Firefox called Firesheep. This plug-in is used to capture the user name and password of unsuspecting users connecting to a rather wide array of Web sites, such as Facebook and Twitter, via open wireless networks.
The plug-in was created to drive home the point that Web sites need to take better responsibility for the data of their users and require secure logins that make use of end-to-end encryption.
Firesheep makes hacking really easy (and scary)
Because trying out the technology is part of the fun of blogging, I decided to see what this plug-in was all about and installed it in Firefox. Then I thought I would test it out. Note: I used my own open wireless network and laptops for testing for this article. I did not compromise any user credentials in testing this plug-in.
After installing Fire Sheep, I connected to my Mi-Fi on that computer, and started looking for information.
Then I connected another laptop to the open network, and logged into Facebook. Almost faster than I was logged in, my credentials appeared in Firesheep. Then I logged into Twitter using the web client and the same thing happened there.
This being the first time I had used Fire Sheep, I was a bit surprised at how fast it gathered my information. WOW.
Not only does it capture credentials, logging in with the gathered information is as simple as a double-click.
What if I just stay off of open wireless networks?
This is a good idea in general, however, if someone on your own wireless network is running Firesheep and you log in to one of the affected Web sites, it will grab the credentials and display them in the side bar. The likelihood of anyone running the Firesheep plug in on a known trusted network, i.e., your workplace or home, is probably slim to none, however, it doesn't stop someone from trying.
Why anyone would be using either an open Wi-Fi network or a WEP-encrypted network in a business setting is a bit beyond me. The technology was good enough when it was the only technology available, but WPA runs circles around the older technology and is certainly better than an open network. Because access to information is just as crucial these days as access to the super-secret file cabinet in the HR manager's office, it is best to use the highest level of security offered to ensure the safety of your information, from employees and non-employees alike. The cost of access points today is relatively cheap (depending on what your needs are) and can get your wireless infrastructure up to the WPA standard with very little spend and configuration effort.
What about other browsers?
I tried Chrome, Internet Explorer and Firefox with Firesheep running and was able to capture the credentials for Facebook and Twitter.
What can I do to keep my information safe?
In a previous post, I covered a personal VPN service called WiTopia that encrypts your traffic from your PC all the way to WiTopia's servers. Requests for sites are then sent to the hosts and the response is encrypted back to you, virtually eliminating the problem.
Now that Fire Sheep is around, and I have seen how easy it is to get a hold of information for some sites, the US$60 annual price tag for encrypted data on any connection via a personal VPN is worth the price of admission for me. Especially since you are allowed to install the application on any computers you own (as long as you only use them one at a time).
Note: VPN Connections or other proxies connections that you may have access to will also encrypt your traffic and may be free or provided by your workplace.
Further research shows some Wi-Fi is okay
I tried several types of wireless networks to see which would allow Firesheep to gather information.

• Open - allows easy information capture
• WEP - allows information capture by other connected users
• WPA - does not allow information capture by Firesheep

I was quite surprised that WEP would still allow Firesheep to capture information and glad to know that attempts to collect information on WPA wireless networks did not work.
So what is the bottom line?
There have always been ways to get access to people's data via fairly simple hacking attempts, and especially on unsecured networks, but Firesheep makes it extremely easy for the masses. If you don't already have access to a VPN connection, services like WiTopia are a good way to help ensure your data is a bit more secure when using wireless networks, regardless of their security level.

« Previous pageNext page »

Read More

Create a simple, simulated network with the honeyd tool

Each piece of software in the FreeBSD ports tree comes with a pkg-descr file that offers a summarized description of the software. Using a tool such as pkgsearch, also from FreeBSD ports, you can print the contents of that file to the console without having to type the full path or go to the file the long way. Using pkgsearch to get a description of the net/honeyd port shows this:

:~> pkgsearch -d honeyd
/usr/ports/net/honeyd
DESC:
        Honeyd is a small daemon that creates virtual hosts
        on a network.  The hosts can be configured to run
        arbitrary services, and their TCP personality can be
        adapted so that they appear to be running certain
        versions of operating systems. Honeyd enables a
        single host to claim multiple addresses - I have
        tested up to 65536 - on a LAN for network simulation.

        WWW: http://www.citi.umich.edu/u/provos/honeyd/
        - Dominic 

The honeyd tool can be used to simulate an entire network of vulnerable computers. The standard use case for honeyd is to set up a honeypot network. Wikipedia defines a honeypot, as of this writing, thusly:

In computer terminology, a honeypot is a trap set to detect, deflect, or in some manner counteract attempts at unauthorized use of information systems. Generally it consists of a computer, data, or a network site that appears to be part of a network, but is actually isolated, (un)protected, and monitored, and which seems to contain information or a resource of value to attackers.

On most of the major open source Unix-like systems--including BSD Unix systems like FreeBSD and Linux-based systems such as Debian--installing honeyd is as easy as a single short command, because it is available through the operating system's standard software management system. Configuration is, in its most basic form, not much more difficult.
Configuration for honeyd is stored in a file of your choosing. A file called honeyd.conf is the most obvious choice. A relatively easy to follow explanation of configuration and deployment is available in the form of an entry in the Ulisses Costa Blog, "Deploying Honeypots with Honeyd".
The O'Reilly book Network Security Hacks offers an overview of setup and use as well. In the second edition, the setup explanation begins on page 400; between that and the following explanation of how to record honeypot activity, the section on honeyd spans thirteen pages.
Only the most cursory, and largely useless, explanation of honeyd could be offered in an article here. You are better off reading other sources for the information. Instead, let this serve as your introduction to where to find the information and why you might want it.
The usual purpose for a honeynet (a virtual network of honeypot hosts) is to serve as either a distraction and delaying tactic for malicious security hackers, allowing network administrators additional options for protecting themselves, or as a way to collect data on the activities of malicious security hackers without being attached to a network of any other hosts. An additional possible use that may not occur to many is that of a test network for practicing beginner-level penetration testing techniques.
One of the benefits of using something like honeyd for practicing some of the basic techniques of penetration testing--network enumeration for instance--is that it is a lot cheaper than building an entire physical test network, and a lot simpler than building a virtual network using virtual machine technology like Virtualbox, VMWare, and Xen.
Considering the licensing issues involved if you need MS Windows hosts in your test networks, the savings can be really shockingly large. Check that number above: the developer has tested honeyd simulating as many as 65,536 honeypot hosts. Doing that with actual MS Windows licenses would cost more than three million dollars with a very generous volume discount.
There are downsides to this approach to simulating penetration testing target networks as well, of course. The simulation of hosts that honeyd provides is in fact fairly rudimentary. If you want to start exploring the possibilities for rootkit installation, be prepared to move up from honeyd to something more robust.
In the end, honeyd's usefulness is whatever you make of it, but whether you want to start learning the ropes of penetration testing, set up a honeynet to delay and confuse would-be attackers, or simply perform some research, it is a tool worth knowing is available. Being open source software, it can be used without charge as well.

Read More

Unique password ,are you sure ? I dont think so

These days it seems like every time we turn around someone has written another article that gives "security" advice directly contradicting actual secure practice:

• Don't use strong passwords! Just use whatever you'll remember!
• It's okay to use one password for everything as long as it's a strong one!
• You don't have to use a strong password as long as it's uncommon!

Those of us that studied even a modicum of logic during our school years should be familiar with the idea of a false dichotomy. The false dichotomy, or false dilemma, is what is known as a formal fallacy of propositional logic. When someone makes an argument based on the idea that there are only two options, thus making a case for choosing one of those options over the other, despite the fact that there are other ignored options that may be preferable, that person is indulging in a classic fallacy of the false dichotomy.
My favorite solution to all of these convenience issues with using strong, unique passwords is to use a password manager. Unfortunately, doing so is still not as easy as using password123 everywhere, and as a result, a lot of people are willing to swallow any ridiculous swill being peddled about how bad security practice is actually "more secure".
The arguments for strong passwords are common and well documented. The most cursory searches should turn up something that will give you the gist of the idea. Unfortunately, the problem of convincing people that every password should be unique might be a little more difficult to solve. Explaining it is not too difficult; just slightly less easy than explaining the importance of a strong password, and its importance is slightly less obvious to the casual observer, so it is done less often.
The best example that comes to mind for what can happen if you do not use unique passwords goes something like this:
John and Jane each have accounts at 40 different Web sites. John uses the same password at all of them because it is too difficult to maintain multiple passwords in his head, while Jane uses a password manager to ensure she can use a different password for each site without having to remember any of them.
Both of them have memberships at example.com, and by some twist of fate, they both end up using the same password, OJ01GzVWR5. In fact, they both use the exact same 40 Web sites. Along comes Pat, a malicious security cracker. Pat manages to bypass the incredibly deficient security at example.com and download the unencrypted database of usernames and passwords.
With this database in Pat's grasp, the malicious security cracker makes a list of a 100 high-value Web sites, mostly including financial institutions. Pat starts running the username and password pairs in the unauthorized copy of the authentication database.
Because Pat's strategy involves entering each username and password combination only once, a direct attempt to access each of the 100 sites once per account name is all that is needed. This neatly avoids problems like the potential of being locked out of a highly secured site. In fact, it turns most sites -- however well-designed -- into a trivial exercise to access under someone else's credentials, as long as some people use the same username and password everywhere.
The end result is that Jane's bank account remains secure, while John's gets cleaned out the next day, and it is all because he took the advice of some security "expert" whose credentials largely consist of a piece of sheepskin and a job at a big-name security vendor that does not actually produce anything innovative. Sometimes, though, when advice sounds too good to be true, that is because it is not true. The perfect example is when someone tells you that you do not need unique passwords to be secure.

Read More

Two simple tricks for better shell script error handling

Word on the street is your shell scripts don't do any error handling. They just chug happily along even when    everything is broken.
Because a lowly shell shell script doesn't need any error handling right? WRONG!
Here are two simple tricks that are easy to use and will make your scripts much more robust.

1. Turn on -e mode (do you feel lucky - punk?)
   In this mode any command your script runs which returns a non-zero exitcode - an error in the world of shell - will cause your script to itself terminate immediately with an error.
   You can do that in your shebang line:
   

   #!/bin/sh -e

   Or using set:
   

   set -e

   Yes, this is what you want. A neat predictable failure is infinitely better than a noisy unreliable failure.
   If you REALLY want to ignore an error, be explicit about it:
   

   # I don't care if evil-broken-command fails
   evil-broken-command || true

   Oh and as long as you're messing with shell modes, -e goes well with -x (which I like to think of as shell X-ray).
   Like this:
   

   #!/bin/sh -ex

   Or like this:
   

   # turn -x on if DEBUG is set to a non-empty string
   [ -n "$DEBUG" ] && set -x

   That way you can actually see what your script was doing right before it failed.
   
2. Use trap for robust clean-ups
   A trap is a snippet of code that the shell executes when it exits or receives a signal. For example, pressing CTRL-C in the terminal where the script is running generates the INT signal. killing the process by default generates a TERM (I.e., terminate) signal.
   I find traps most useful for making sure my scripts clean-up after themselves whatever happens (e.g., a non-zero error code in -e mode).
   For example:
   

   
   #!/bin/sh -e
   
   TMPFILE=$(tempfile)
   trap 'echo "removing $TMPFILE"; rm -f $TMPFILE' INT TERM EXIT
   
   echo TMPFILE=$TMPFILE
   echo hello world > $TMPFILE
   cat $TMPFILE
   # gives user a chance to press CTRL-C
   sleep 3
   # false always returns an error
   false
   
   echo "NEVER REACHED"
   

   Note that you can only set one trap per signal. If you set a new trap you're implicitly disabling the old one. You can also disable a trap by specifying - as the argument, like this:
   

   trap - INT TERM EXIT

Read More