Posts Tagged ‘network’

Hackers pop German steel mill, wreck furnace | The Register

Tuesday, December 23rd, 2014

Talented hackers have caused “serious damage” after breaching a German steel mill and wrecking one of its blast furnaces.The hack of the unnamed mill, detailed in the annual report of the German Federal Office of Information Security, was pulled off after a victim fell for a phishing email.Hackers then pivoted to the production network, a feat that should not be possible according to best practice that requires separation between industrial control systems and the public internet.”The result was that a blast furnace could be shut down,” the agency wrote in a report (page 31, Deutsche).”The attackers were knowledgeable in conventional IT security and had extensive knowledge of applied control and production processes.”

The advanced persistent threat hackers specifically targeted industrial plants but their location was not specified.The attacks likely demonstrated the mill had not employed sufficient separation of internet-facing and critical production networks.Attacks against industrial control systems were common but public reporting of resulting physical damage was rare.In June, Finnish malware probers F-Secure reported that remote access trojans had infected manufacturers of industrial control and SCADA software in France, Germany and Russia by a group that was not considered overly advanced.Last year, Trend Micro researcher Kyle Wihoit proved the hacker interest in industrial systems through a SCADA honeypot that was attacked within 18 hours of being established on the public internet.

Vendors have throughout the year pushed out patches for various industrial control systems. Patching however could due to configurations and dependencies be difficult to near impossible to complete for some operators. ®

via Hackers pop German steel mill, wreck furnace • The Register.

Google Releases ‘nogotofail’ Network Traffic Security Testing Tool

Tuesday, November 11th, 2014

 

 

Google Releases 'nogotofail' Network Traffic Security Testing Tool

Google introduced a new security tool to help developers detect bugs and security glitches in the network traffic security that may leave passwords and other sensitive information open to snooping.

The open source tool, dubbed as Nogotofail, has been launched by the technology giant in sake of a number of vulnerabilities discovered in the implementation of the transport layer security, from the most critical Heartbleed bug in OpenSSL to the Apple’s gotofail bug to the recent POODLE bug in SSL version 3.
The company has made the Nogotofail tool available on GitHub, so that so anyone can test their applications, contribute new features to the project, provide support for more platforms, and help improve the security of the internet.
Android security engineer Chad Brubaker said that the Nogotofail main purpose is to confirm that internet-connected devices and applications aren’t vulnerable to transport layer security (TLS) and Secure Sockets Layer (SSL) encryption issues.
The network security testing tool includes testing for common SSL certificate verification issues, HTTPS and TLS/SSL library vulnerabilities and misconfigurations, SSL and STARTTLS stripping issues, and clear text traffic issues, and more.

Google is committed to increasing the use of TLS/SSL in all applications and services. But ‘HTTPS everywhere’ is not enough; it also needs to be used correctly,” Brubaker wrote in a blog post.

Most platforms and devices have secure defaults, but some applications and libraries override the defaults for the worse, and in some instances we’ve seen platforms make mistakes as well. As applications get more complex, connect to more services, and use more third party libraries, it becomes easier to introduce these types of mistakes.

Nogotofail tool, written by Android engineers Chad Brubaker, Alex Klyubin and Geremy Condra, works on devices running Android, iOS, Linux, Windows, Chrome OS, OS X, and “in fact any device you use to connect to the Internet.” The tool can be deployed on a router, a Linux machine, or a VPN server.
The company says it has been using the Nogotofail tool internally for “some time” and has worked with developers to improve the security of their apps before releasing it. “But we want the use of TLS/SSL to advance as quickly as possible,” Brubaker said.
The Nogotofail tool requires Python 2.7 and pyOpenSSL>=0.13. It features an on-path network Man-in-the-Middle (MiTM), designed to work on Linux machines, as well and optional clients for the devices being tested.

via Google Releases ‘nogotofail’ Network Traffic Security Testing Tool.

InfoSec Handlers Diary Blog – UDP port 1900 DDoS traffic

Wednesday, August 27th, 2014

I guess this is my day for asking for feedback from our readers.  Again, I’m going to ask “Got packets?”  On 22 Aug, one of our readers (Paul) commented on the Port 1900 page that he was seeing a DDoS on port 1900, with packet sizes of 300 bytes.  This is a development we’ve been watching at $dayjob, too, but I was wondering if anyone (including Paul) has packets so we can try to figure out what the amplification mechanism might actually be (if you have the packets, please share via the contact page).  What we’re seeing in Dshield data is a little odd and different from what I’m seeing at $dayjob.  You’ll note below that there were a more targets until they suddenly dropped off on 18 Jun.  On the other hand, the sources seem to be trending upward (at least, peaking higher).  Unfortunately, we only have source and target counts in the Dshield data, not byte volumes.  Compare that with what we’re seeing at the $dayjob as shown in the webcast we do weekly there (from 39:55 in this video — watch to about 47:00 if you want to see our discussion of all the reflective DoS ports we’re watching).

via InfoSec Handlers Diary Blog – UDP port 1900 DDoS traffic.

Trolling Memory for Credit Cards in POS / PCI Environments |InfoSec Sans.EDU

Wednesday, August 27th, 2014

In a recent penetration test, I was able to parlay a network oversight into access to a point of sale terminal. Given the discussions these days, the next step for me was an obvious one – memory analysis.

My first step was to drive to the store I had compromised and purchase an item.

I’m not a memory analysis guru, but the memory capture and analysis was surprisingly easy. First, dump memory:

dumpit

Yup, it’s that simple, I had the dumpit executable locally by that point (more info here https://isc.sans.edu/diary/Acquiring+Memory+Images+with+Dumpit/17216)

or, if you don’t have keyboard access (dumpit requires a physical “enter” key, I/O redirection won’t work for this):

win32dd /f memdump.img

(from the SANS Forensics Cheat Sheet at https://blogs.sans.org/computer-forensics/files/2012/04/Memory-Forensics-Cheat-Sheet-v1_2.pdf )

Next, I’ll dig for my credit card number specifically:

strings memdump.img | grep [mycardnumbergoeshere] | wc -l

171

Yup, that’s 171 occurences in memory, unencrypted. So far, we’re still PCI complaint – PCI 2.0 doesn’t mention cardholder data in memory, and 3.0 only mentions it in passing. The PCI standard mainly cares about data at rest – which to most auditors means “on disk or in database”, or data in transit – which means on the wire, capturable by tcpdump or wireshark. Anything in memory, no matter how much of a target in today’s malware landscape, is not an impact on PCI compliance.

via InfoSec Handlers Diary Blog – Trolling Memory for Credit Cards in POS / PCI Environments.

Fear and Loathing as Telecom Policy | Jeff Pulver

Thursday, August 7th, 2014

global telecom

The adoption of the "Pulver Order" by the Federal Communications Commission FCC in 2004 recognized the madness of applying 70-year-old Title II telecom regulations to IP communications. Ten years later friends in telecom policy circles spend their days weighing the implications of legal hypotheticals that imagine discrimination by network operators as the primary threat to the communication future. Net neutrality relies on the fear and loathing of telephone companies as a basis for applying Title II regulations to IP networks. This reversal by civil society and entrepreneur friends who had supported Pulver Order puts the madness back in play. The reversal includes circumstances making the network operators allies in preserving the Pulver Order’s deference to technology innovation and Moore’s Law.I did not find anyone who could point to a substantial problem caused by the Pulver Order’s recipe of non-regulation during a recent return visit to Washington, DC. The potential of IP communications won the day in 2004, and the still ever-expanding breadth of communication services make the case stronger a decade later. The 1000 fold expansion of routine connectivity to 10Mbs cost $10,000 per month when I founded Free World Dialup in 1995. The transformation of communication over the last two decades makes the pre-Internet limitations to "long distance" telephone calls and waiting for the mailman seem medieval by comparison. We might convene a conversation to start work on the next 1000 fold expansion, but no one can dismiss the remarkable expansion of communication capacity arriving with IP networks.The fact everyone agrees about the sacred nature of communication explains the power of the fear, uncertainty, and doubt energizing the net neutrality debate. The magnitude of the stakes makes action seem better than inaction and dispassionate reason difficult to muster, but principle of innocent-until-proven-guilty exists for good reasons. In 2004, we argued the experiment known as IP communications should continue without regulation absent an explicit cause for intervention. Preemptive action against the mere perception of risk is always problematic, but the pace of change makes it impossible in the case of IP networks.The madness motivating the Title II enthusiasts and one million comments in the FCC Open Internet proceeding traces to the suffering of a communication public during 20th century. Telephone calls remained an expensive luxury justifiable for narrow personal or business purposes from the invention of the telephone in 1876 through the year 2000. Anyone born before 1980 likely still feels the ticking clock anxiety when talking on the telephone even though IP communications made charging by the minute obsolete. The endorsement of Title II rules for IP communications fails as a solution, because Title II and FCC stewardship caused of the communication drought underlying the upset.The fact Title II makes innovation illegal became clear with my first experience of Voice over Internet Protocol VoIP in the 1993. The ability to "talk" over the Internet felt like running a car on tap water. The conversation always came back to the question of the legality of using IP networks for voice services. The uncertain legal atmosphere made it extremely difficult to attract investors in Vonage. Everyone assumed the FCC would put a stop to startup’s "bypassing" the telephone networks via the usual all-good-things-come-to-an-end sentiment. The history of telecommunications policy includes plenty of examples where government prosecuted innovation as a crime under Title II rules. The first FCC petition after the arrival IP communications argued for declaring VoIP software illegal.

via Fear and Loathing as Telecom Policy | Jeff Pulver.

TOR network vulnerable and de-anonymized!

Saturday, August 2nd, 2014

A critical vulnerability in Tor — an encrypted anonymizing network considered to be one of the most privacy oriented service, which is used by online users in order to hide their activities from law enforcement, government censors and others — was probably being used to de-anonymize the identity of Tor users, Tor project warned on Wednesday.
115 MALICIOUS ToR RELAYS WERE DE-ANONYMIZING USERS
According to a security advisory, Tor Team has found a group of 115 malicious fast non-exit relays (6.4% of whole Tor network), those were actively monitoring the relays on both ends of a Tor circuit in an effort to de-anonymize users.
“While we don’t know when they started doing the attack, users who operated or accessed hidden services from early February through July 4 should assume they were affected,” Tor said.
When you use Tor anonymizing network, your IP address remains hidden and it appears that your connection is coming from the IP address of a Tor exit relay or nodes, making it very difficult for anyone — malicious actor or a government spy agency — to tell where traffic is coming from and going to.

Netflix agrees to end network warnings in Verizon slowdown spat • The Register

Monday, June 9th, 2014

verizon sucks

Netflix is backing down in its battle with Verizon over the speed of its streaming video service on the carrier’s network, albeit just a little.

A Monday post to the Netflix US and Canada blog said that the company will stop issuing users error messages blaming carriers for slow performance, saying the notifications were part of an experiment to introduce greater “transparency.”

“As part of this transparency campaign, we started a small scale test in early May that lets consumers know, while they’re watching Netflix, that their experience is degraded due to a lack of capacity into their broadband provider’s network,” the company said. “We are testing this across the U.S. wherever there is significant and persistent network congestion. This test is scheduled to end on June 16.”

The announcement comes just days after Netflix found itself facing the ire of Verizon’s legal team when the carrier discovered that the video service was informing Verizon subscribers that problems in video performance were the ISP’s fault.

Netflix alert warning of slow speeds on Verizon

Netflix knows whose network you’re on, and it thinks it’s too slow

The telco issued a cease and desist order demanding that Netflix stop presenting Verizon customers with “the Verizon network is crowded right now” messages and provide evidence that Verizon was to blame for the slowdowns.

In the letter, which was both released publicly and delivered to Netflix counsel, Verizon lawyers suggest that the Netflix traffic issues are the fault of the video service and its network of third-party providers, which experience slowdowns before data ever reaches the ISP.

Netflix indirectly responded to the claims by posting its latest US Speed Index, ranking service providers by average speed. The index ranks Verizon’s DSL service last among the 16 US providers with an average speed of 1.05 Mb/sec. Verizon FiOS ranked tenth with a 1.90 Mb/sec average, while Cablevision was tops with a 3.03Mb/sec average rate.

Netflix also objected to the notion that its delivery network was causing slowdowns, shifting blame to the “last mile” networks of ISPs.

“We pay some of the world’s largest transit networks to deliver Netflix video right to the front door of an ISP,” the company said. “Where the problem occurs is at that door – the interconnection point – when the broadband provider hasn’t provided enough capacity to accommodate the traffic their customer requested.”

Meanwhile, Netflix continues to simultaneously work to roll out direct interconnect deals with Verizon and other ISPs while also lobbying for the shutdown of such “fast lane” agreements by way of net neutrality provisions. ®

via Netflix agrees to end network warnings in Verizon slowdown spat • The Register.

How to run a wireshark capture on a device without crashing it from over memory utilization | ShoreTel

Friday, May 30th, 2014
Details
Wireshark is a great network packet capture and analysis tool. Its graphical interface uses copious amounts of memory, causing Wireshark to crash after some period of time capturing packets. The crashes may be delayed somewhat by using the packet capture filter (the packet display filter does not help). Use Wireshark for:

  • short periods of time
  • in low-throughput environments
  • for offline packet analysis of packet-capture files.
Answer
For long-term packet capture, use dumpcap.exe (included with Wireshark). It runs independently of Wireshark to capture packets to a file or series of files on disk.
Wireshark must be installed on the server before starting these steps:

  1. Create a directory on the server to hold the files (i.e. c:\PCAP_files\)
  2. Open a command window and navigate to the Wireshark install directory

    User-added image

  3. Run “dumpcap.exe –D” to identify interface number

    User-added image

  4. Start captures by running the following command “dumpcap -i 1 -b duration:1800 -b files:12 -w” “c:\PCAP_files\DVS.pcap” (-i equals the interface number from step 3, -b duration equals times in seconds, -b files equals the number of files before it overwrites -w equals the folder created in step one plus a file name) Must leave the command window open and to stop the captures use Ctrl-C

    User-added image

via ShoreTel | Support – How to run a wireshark capture on a device without crashing it from over memory utilization.

Tor anonymity network to shrink due to Heartbleed flaw | [PCWorld]

Friday, April 18th, 2014

The Tor Project has flagged 380 Tor relays vulnerable to the critical Heartbleed flaw to be rejected from the Tor anonymity network, reducing the network’s entry and exit capacity.

 

The decision has already been implemented on a Tor directory authority—a server that maintains a list of Tor relays—controlled by Roger Dingledine, the Tor Project leader, and is likely to be followed by other directory authority operators.

The 380 relays flagged for rejection are trusted entry relays, also known as guards, and exit relays. As a result, the immediate impact of this decision would be a 12 percent reduction in the network’s guard and exit capacity, Dingledine said Wednesday in an email sent to the tor-relays mailing list.

Traffic from clients typically flows through the Tor network in three hops. The first hop is through a guard relay and the final hop, before the traffic is returned on the Internet to reach its intended destination, is through an exit relay.

Twelve percent might not sound like much, but guard and exit relays play an important role on the network and are not easy to replace. Many relays are run by volunteers, but they need to be trusted and need to have enough bandwidth at their disposal to handle traffic from multiple clients.

“I thought for a while about taking away their Valid flag rather than rejecting them outright, but this way they’ll get notices in their logs,” Dingledine said.

Tardy patches seem to be the reason

It seems that the ban might be permanent. Dingledine said that he wouldn’t want those relays back on the Tor network even if they upgraded their versions of OpenSSL because their operators didn’t patch the flaw in a timely manner.

The Heartbleed vulnerability was announced on Apr. 7 and affects versions 1.0.1 through 1.0.1f of OpenSSL, a library that implements the TLS (Transport Layer Security) encrypted communication protocol and which is used by many operating systems, web servers, browsers and other desktop and mobile applications.

via Tor anonymity network to shrink as a result of Heartbleed flaw | PCWorld.

Shoretel IP Network Migrations – How to engineer shoretel VoIP

Thursday, February 13th, 2014

This is an article I am writing about how to engineer Shoretel VoIP.

Basically while working for a healthcare company in western Washington state I realized it was going to be a difficult task to change the ips of all the devices whether dhcp or static Ip due to the VLAN ID and the dhcp scope 156 policies that allow the shoretel to sync up with the ShoreTel Director / HQ server.

I realized that while logged into the phone via telnet and watching the activities in the vxworks / u-boot environment that there was an nvram process going on when you dial MUTE+C-L-E-A-R (MUTE+25237) to erase the nvram cached settings of the network.

I also noticed that this command does not always wipe the nvram on the first attempt for some reason, ie: the nvram address possibly being accessed when the engineer walks to the phone and issues this command or something similar.   While using the tools “ipbxctl.exe” as well as “phonectl.exe”  which enable telnet access for 60 seconds on an appliance like an sg90 or t1k {ipbxctl.exe} or a phone {phonectl.exe} – (both tools are located in c:\program files x86\ShoreLine Server\ directory I believe on the HQ / ShoreTel director or Voicemail server).

I have written a few perl scripts and I recommend installing cygwin on a machine and copying those two files to the root c: directory of your machine you install cygwin on.

 

The reason cygwin is so powerful and useful in this situation is because of a set of tools that can be compiled into cygwin while remaining in the windows environment.  I will touch on these tools quickly and leave research up to the reader… YOU 🙂

1) install the perl cpan bundle – all the compiling bundles but mainly the Net:: bundle which includes telnet from a command prompt.

2) once you have cygwin installed with the telnet tools (Net::) and perl you’re pretty much ready to migrate enterprise networks on the fly with ShoreTel.

 

Here’s how I did it in 2013:

You need a batch script to run and turn telnet on via phones:

After you build your script it essentially looks like a .bat file containing something like:

ping 10.0.0.1 -n 5 > nul
C:\\Program Files (x86)\Shoreline Communications\Shoreware Server\phonectl.exe -pw 1234 -telneton 10.0.1.1
ping 10.0.0.1 -n 5 > nul
C:\\Program Files (x86)\Shoreline Communications\Shoreware Server\phonectl.exe -pw 1234 -telneton 10.0.1.2
ping 10.0.0.1 -n 5 > nul
C:\\Program Files (x86)\Shoreline Communications\Shoreware Server\phonectl.exe -pw 1234 -telneton 10.0.1.3
ping 10.0.0.1 -n 5 > nul
C:\\Program Files (x86)\Shoreline Communications\Shoreware Server\phonectl.exe -pw 1234 -telneton 10.0.1.4
ping 10.0.0.1 -n 5 > nul
C:\\Program Files (x86)\Shoreline Communications\Shoreware Server\phonectl.exe -pw 1234 -telneton 10.0.1.5

10.0.1.0\24 in this example is the network with the ip phones we want to open telnet on.

I found it quicker to use the cygwin tool along with the up arrow key to edit the last octet every command like this:

cyg$> cygstart.exe “/cygdrive/c/phonectl.exe -pw 1234 -telneton 10.0.1.1”

(command prompt with access enabled flashes by)–

cyg$> telnet 10.0.1.1

once you have accessed the ShoreTel phone, it looks like this:

>dhcpEraseCache

and it should give you something back saying you erased 0x16 or something and you’re good to go.

 

Press control + ] to get back to this prompt:

telnet> quit

and then type quit.

YOu’ll be back to the cygwin prompt

cyg$> cygstart.exe /cygdrive/c/phonectl.exe -pw 1234 -telneton 10.0.1.2

up arrow to start again and edit the ip and once telnet is enabled follow the same activity again:  telnet into the device and dhcpEraseCache two times.