Users of Tweetdeck, and possibly other Twitter apps, take note: old settings can come back to trip you up. Digital media strategist Kate Gardiner learned this lesson first hand on Tuesday, when she inadvertently caused at least a dozen separate news-oriented Twitter accounts to tweet "f gwenifill" in unison.

The errant tweets quickly triggered suspicions of another hack involving the hijacking of a high-profile Twitter account, only in this case at least 12 accounts would have been taken over and used to poke fun at PBS News Hour anchor Gwen Ifill.

The cause turned out not to be a hack, but rather the mismanagement of the Tweetdeck application Gardiner had used for years to send tweets for a variety of different media outlets. In the course of clearing out the old credentials, she said, she accidentally sent out tweet. Because her Tweetdeck was still associated with the Twitter accounts of her old employers or clients, it ended up broadcasting the "f gwenifill" tweet to all of them.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

(*): ISC rating

• We use 4 levels:
  • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
  • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
  • Important: Things where more testing and other measures can help.
  • Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
• The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
• The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
• Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
• All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.

(**): The exploitability rating we show is the worst of them all due to the too large number of ratings Microsoft assigns to some of the patches.

 

 

 

In the world of personal computing, hacks that exploit memory errors to allow for the execution of arbitrary (and often malicious) code are far from surprising anymore. What's more surprising is that such "arbitrary code" bugs are also present on the relatively locked-down computers inside of video game consoles.

This was demonstrated quite dramatically last week at Awesome Games Done Quick (AGDQ), an annual marathon fundraiser that this year raised over $1 million for the Prevent Cancer foundation. The event focuses on live speedruns of classic games by human players and included a blindfolded Mike Tyson's Punch-Out!! run that ranks among the most impressive live video game playing performances I have ever seen. The most remarkable moment of the weeklong marathon, though, came when a robotic player took "total control" of an unmodified Super Mario World cartridge, reprogramming it on the fly to run simple versions of Pong and Snake simply by sending a precise set of inputs through the standard controller ports on the system.

The two-and-a-half minute video of this incredible exploit is pretty tough to follow if you're not intimately familiar with the state of emulator-assisted speedruns. At first, it looks like the game must have been hacked in some way to allow for things like multiple on-screen Yoshis, item boxes that spawn multiple 1-ups, and the ability for Mario to carry items while riding on Yoshi. In actuality, these seeming impossibilities are just glitches that have been discovered over the years through painstaking emulated playthroughs by the community at TASVideos (short for tool-assisted speedrun videos).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Spamming and scanning botnets - is there something I can do to block them from my site?

 

This question keeps popping up on forums and all places popular with those beleaguer souls despondent of the random spamming and over filled logs from scanning. Although this isn't a Magic ball question answer does come out a: Maybe, Maybe not.

 

The reason behind the ambiguity is logical, to a degree; it’s easy trying to hinder, frustrate and reduce the effectiveness of automated botnet processes, like posting and scanning rather than stop them dead. 

 

Why? Glad you asked.

 

Botnets tend to a number of systems located in random locations globally, you'll get some that are regional specific, but the majority we at the Internet Storm Center (ISC) see are global in distribution. So unless you can pick out only the  six IP addresses you completely trust as good*, you’re accessible to every system on the planet that has an internet link. 

 

First and foremost you need to look at your logs find those non-human attacks or blog spamming posts. We keep saying here at the ISC you need to understand your logs. If you don’t understand what you’re seeing research it or writing in to us. It doesn’t take too long to be able to work out a real human interaction against an automated non-human one. Have a look at one our recent posts [1] to see the types of patterns automated processes leave behind in logs. 

 

Let say you are now at one with your logs files, so what next? From a random reader's submission for the bots they logged I did a little Excel shuffling, then some IP geo-locationing followed by more Excel-ing, finally braking the IP addressed down to which country they came from. The results were interesting as Spain has the highest set of bad IPs (13%), follow by: Argentina (9%), Italy(8%), Colombia (5%), United States (5%), United Kingdom (4%), Mexico (4%), Romania (4%) and Germany (4%).

 

So what can we divine from these random statistics? First we can acknowledge this is botnet has a significant portion of it bots in Europe, second the next biggest group is in South America, leave the United States well out of the picture. Yeah so what, I hear you yell. Now go back on look at the locations your human visitors came from. With a simple bit of review, you’ll be able to work out you never see visitors, say from South America and New Zealand IP address ranages. 

 

Now you can make the determination to black list (deny) net blocks in those countries from very be able to access your web site or blog. On the flip side you could block everything and white list (allow) certain countries. Or go crazy and play wack-a-mole by adding in every single bad IP address to a block list. It’s up to you.

 

The point of this piece is look at your logs, understand your visitors, work out who actually needs to get to your site and block out the rest if the now constant automated scans annoy you.

 

Remember Dshield loves logs [2] and Handlers love weird logs and packets, so start off your New Year by looking at your logs and sending in anything wild, crazy or that just seems plain odd to us at the Storm Center [3]. You’ll learn some new and might help someone who's been puzzling over the same questions you’re looking at now.

 

[1] https://isc.sans.edu/diary/Massive+PHP+RFI+scans/17387

[2] https://isc.sans.edu/howto.html 

[3] https://isc.sans.edu/contact.html#contact-form 

 

* This kinda of breaks the Internet model and takes us back to the good ol’day of having host file to resolve stuff on the ‘Net