China's surprisingly open hacking culture

A hacker freelancing for a privately owned company can earn up to $100,000 a year overseas

By Chris Gayomali | May 23, 2013

Two young men participate in the annual Hack-In-The-Box Security Conference in Malaysia, Oct. 6, 2004.

REUTERS/Bazuki Muhammad BM/LA

A

lthough the notion has been proved laughably wrong on more than one occasion, in the U.S., the term "hacker" can still conjure up shadowy images of cyberpunk wizards pressing keys in front of glowing terminals. That's not the case at all, though, at least not in China. The loose categorical term "hacking" is treated with surprising levity, whether it's recording your neighbor's keystrokes, or hiring freelancers to hack a rival businesses' network to steal a peek at their financials.
According to The New York Times, "the culture of hacking in China is not confined to top-secret military compounds where hackers carry out orders to pilfer data from foreign governments and corporations." Instead, the practice is commonplace, openly discussed "at trade shows, inside university classrooms and on internet forums."

The Ministry of Education and Chinese universities, for instance, join companies in sponsoring hacking competitions that army talent scouts attend, though "the standards can be mediocre," said a cyber-security expert who works for a government institute and handed out awards at a 2010 competition.

Corporations employ freelance hackers to spy on competitors. In an interview, a former hacker confirmed recent official news reports that one of China's largest makers of construction equipment had committed cyber-espionage against a rival. [New York Times]

The Times suggests that hacking can be something of a lucrative — and perhaps viable — career in China, even if you don't want to work for the government. For the right privately owned company, a computer wizard can use his or her skills to earn $100,000 a year.
Yet China's relaxed attitude toward cyber-espionage could partially explain why U.S. companies have been the targets of a growing number of hacks from overseas. Earlier this year, The New York Times fell victim to a critical infrastructure breach, which security experts traced back to Shanghai and the People's Liberation Army, which was purportedly gathering intel regarding a Times story set to be published about top-ranking Chinese officials.
Indeed, the threat of cyber-warfare is a growing concern domestically. Out of fear of an imminent, serious cyber-attack — or perhaps one that's already underway — The Verge reports that a former group of government officials and private executives are calling on Congress to "consider passing laws allowing U.S. companies to 'counterattack' against such hackers, whoever they may be."

The controversial idea of giving U.S. companies legal protections to "hack back" against intruders on their networks has been proposed before by some legal experts and companies, and some companies are even alleged to already be engaging in the practice, despite the fact that there is no legal framework in the U.S. permitting it. But the new recommendations from Huntsman's group may be the highest-profile yet, as they come from former Obama Administration officials. [Verge]

To its credit, "China has said that its government is not the hack-happy entity that the U.S. says it is," CNET notes. In fact, Chinese officials claim that the "U.S. and other foreign governments have made attempts to hack into [China's] systems and networks." It seems the hacking goes both ways

Read More

Apple stuck bond buyers with a '$280 million loss'

As if Apple's bonds were the only ones whose price fell as interest rates climbed.

From Apple's prospectus

FORTUNE -- As John R. noted in the comment stream of Mary Childs' latest story on the Bloomberg newswire, she is not an idiot: "She knows using a sensational headline containing 'Apple' will attract readers."
Thus a rise in interest rates across the board is reported on Bloomberg as Apple (AAPL) news:

Apple Bonds Stick Buyers With $280.6 Million Loss as Rates Climb

But perhaps John R. is being unfair. The article was edited by Alan Goldstein. Maybe he wrote the headline, in which case he should be reading the comments her piece drew. A sample:

• feedback12: Must be a new low for Apple bashing and link-bait for Bloomberg. So Apple bonds specifically are the only ones affected by the raise in rates? Ridiculous!
• alice.georger: The "Apple Witch hunt" still going strong with idiot reporters, I see. I think investors in those bonds, knew the risks that were involved. Wow, Mary Childs, you're "just a dynamite" reporter, aren't you!!!!
• David Shapiro: Did all corporations "stick it" to investors by taking advantage of the low interest rate environment? Interest rate risk comes with the territory, why single Apple out...short position on the equity?
• sabaj_49: of course if APPLE JUST PAID ITS TAXES there would be no need for these bond

To which I might add that a bond still has its face value if you hold it to maturity.
As is customary at Bloomberg, Childs and Goldstein attached their e-mail addresses to the bottom of the piece. I've never known a Bloomberg reporter to return e-mail sent to those addresses, but you're welcome to try.

Read More

10 reasons websites get hacked

10/10/2007 Written by Jakub Maslowski

Below you will find list of top 10 web vul­ner­a­bil­i­ties clas­si­fied by OWASP, here is also descrip­tion of the prob­lem and some examples.

I will just give you the list in case you missed it before, i will not com­ment on any of these as there is already hot dis­cus­sion about this mat­ter on sev­eral sites/​forums.

So here it starts:

1. Cross site script­ing (XSS)

The prob­lem: The “most preva­lent and per­ni­cious” Web appli­ca­tion secu­rity vul­ner­a­bil­ity, XSS flaws hap­pen when an appli­ca­tion sends user data to a Web browser with­out first val­i­dat­ing or encod­ing the con­tent. This lets hack­ers exe­cute mali­cious scripts in a browser, let­ting them hijack user ses­sions, deface Web sites, insert hos­tile con­tent and con­duct phish­ing and mal­ware attacks.

Attacks are usu­ally exe­cuted with JavaScript, let­ting hack­ers manip­u­late any aspect of a page. In a worst-​case sce­nario, a hacker could steal infor­ma­tion and imper­son­ate a user on a bank’s Web site, accord­ing to Sny­der.

Real-​world exam­ple: Pay­Pal was tar­geted last year when attack­ers redi­rected Pay­Pal vis­i­tors to a page warn­ing users their accounts had been com­pro­mised. Vic­tims were redi­rected to a phish­ing site and prompted to enter Pay­Pal login infor­ma­tion, Social Secu­rity num­bers and credit card details. Pay­Pal said it closed the vul­ner­a­bil­ity in June 2006.

How to pro­tect users: Use a whitelist to val­i­date all incom­ing data, which rejects any data that’s not spec­i­fied on the whitelist as being good. This approach is the oppo­site of black­list­ing, which rejects only inputs known to be bad. Addi­tion­ally, use appro­pri­ate encod­ing of all out­put data. “Val­i­da­tion allows the detec­tion of attacks, and encod­ing pre­vents any suc­cess­ful script injec­tion from run­ning in the browser,” OWASP says.


2. Injec­tion flaws

The prob­lem: When user-​supplied data is sent to inter­preters as part of a com­mand or query, hack­ers trick the inter­preter — which inter­prets text-​based com­mands — into exe­cut­ing unin­tended com­mands. “Injec­tion flaws allow attack­ers to cre­ate, read, update, or delete any arbi­trary data avail­able to the appli­ca­tion,” OWASP writes. “In the worst-​case sce­nario, these flaws allow an attacker to com­pletely com­pro­mise the appli­ca­tion and the under­ly­ing sys­tems, even bypass­ing deeply nested fire­walled envi­ron­ments.”

Real-​world exam­ple: Russ­ian hack­ers broke into a Rhode Island gov­ern­ment Web site to steal credit card data in Jan­u­ary 2006. Hack­ers claimed theSQL injec­tion attack stole 53,000 credit card num­bers, while the host­ing ser­vice provider claims it was only 4,113.

How to pro­tect users: Avoid using inter­preters if pos­si­ble. “If you must invoke an inter­preter, the key method to avoid injec­tions is the use of safe APIs, such as strongly typed para­me­ter­ized queries and object rela­tional map­ping libraries,” OWASP writes.


3. Mali­cious file exe­cu­tion

The prob­lem: Hack­ers can per­form remote code exe­cu­tion, remote instal­la­tion of rootk­its, or com­pletely com­pro­mise a sys­tem. Any type of Web appli­ca­tion is vul­ner­a­ble if it accepts file­names or files from users. The vul­ner­a­bil­ity may be most com­mon with PHP, a widely used script­ing lan­guage for Web devel­op­ment.

Real-​world exam­ple: A teenage pro­gram­mer dis­cov­ered in 2002 that Guess​.com was vul­ner­a­ble to attacks that could steal more than 200,000 cus­tomer records from the Guess data­base, includ­ing names, credit card num­bers and expi­ra­tion dates. Guess agreed to upgrade its infor­ma­tion secu­rity the next year after being inves­ti­gated by the Fed­eral Trade Com­mis­sion.

How to pro­tect users: Don’t use input sup­plied by users in any file­name for server-​based resources, such as images and script inclu­sions. Set fire­wall rules to pre­vent new con­nec­tions to exter­nal Web sites and inter­nal sys­tems.


4. Inse­cure direct object ref­er­ence

The prob­lem: Attack­ers manip­u­late direct object ref­er­ences to gain unau­tho­rized access to other objects. It hap­pens when URLs or form para­me­ters con­tain ref­er­ences to objects such as files, direc­to­ries, data­base records or keys.

Bank­ing Web sites com­monly use a cus­tomer account num­ber as the pri­mary key, and may expose account num­bers in the Web inter­face.

“Ref­er­ences to data­base keys are fre­quently exposed,” OWASP writes. “An attacker can attack these para­me­ters sim­ply by guess­ing or search­ing for another valid key. Often, these are sequen­tial in nature.”

Real-​world exam­ple: An Aus­tralian Tax­a­tion Office site was hacked in 2000 by a user who changed a tax ID present in a URL to access details on 17,000com­pa­nies. The hacker e-​mailed the 17,000 busi­nesses to notify them of the secu­rity breach.

How to pro­tect users: Use an index, indi­rect ref­er­ence map or another indi­rect method to avoid expo­sure of direct object ref­er­ences. If you can’t avoid direct ref­er­ences, autho­rize Web site vis­i­tors before using them


5. Cross site request forgery

The prob­lem: “Sim­ple and dev­as­tat­ing,” this attack takes con­trol of victim’s browser when it is logged onto a Web site, and sends mali­cious requests to the Web appli­ca­tion. Web sites are extremely vul­ner­a­ble, partly because they tend to autho­rize requests based on ses­sion cook­ies or “remem­ber me” func­tion­al­ity. Banks are poten­tial tar­gets.

“Ninety-​nine per­cent of the appli­ca­tions on the Inter­net are sus­cep­ti­ble to cross site request forgery,” Williams says. “Has there been an actual exploit where someone’s lost money? Prob­a­bly the banks don’t even know. To the bank, all it looks like is a legit­i­mate trans­ac­tion from a logged-​in user.”

Real-​world exam­ple: A hacker known as Samy gained more than a mil­lion “friends” on MySpace​.com with a worm in late 2005, auto­mat­i­cally includ­ing the mes­sage “Samy is my hero” in thou­sands of MySpace pages. The attack itself may not have been that harm­ful, but it was said to demon­strate the power of com­bin­ing cross site script­ing with cross site request forgery. Another exam­ple that came to light one year ago exposed a Google vul­ner­a­bil­ity allow­ing out­side sites to change a Google user’s lan­guage pref­er­ences.

How to pro­tect users: Don’t rely on cre­den­tials or tokens auto­mat­i­cally sub­mit­ted by browsers. “The only solu­tion is to use a cus­tom token that the browser will not ‘remem­ber,’” OWASP writes.


6. Infor­ma­tion leak­age and improper error han­dling

The prob­lem: Error mes­sages that appli­ca­tions gen­er­ate and dis­play to users are use­ful to hack­ers when they vio­late pri­vacy or unin­ten­tion­ally leak infor­ma­tion about the program’s con­fig­u­ra­tion and inter­nal work­ings.

“Web appli­ca­tions will often leak infor­ma­tion about their inter­nal state through detailed or debug error mes­sages. Often, this infor­ma­tion can be lever­aged to launch or even auto­mate more pow­er­ful attacks,” OWASP says.

Real-​world exam­ple: Infor­ma­tion leak­age goes well beyond error han­dling, apply­ing also to breaches occur­ring when con­fi­den­tial data is left in plain sight. The Choi­ce­Point deba­cle in early 2005 thus falls some­where in this cat­e­gory. The records of 163,000 con­sumers were com­pro­mised after crim­i­nals pre­tend­ing to be legit­i­mate Choi­ce­Point cus­tomers sought details about indi­vid­u­als listed in the company’s data­base of per­sonal infor­ma­tion. Choi­ce­Point sub­se­quently lim­ited its sales of infor­ma­tion prod­ucts con­tain­ing sen­si­tive data.

How to pro­tect users: Use a test­ing tool such as OWASP’S Web­Scarab Project to see what errors your appli­ca­tion gen­er­ates. “Appli­ca­tions that have not been tested in this way will almost cer­tainly gen­er­ate unex­pected error out­put,” OWASP writes.


7. Bro­ken authen­ti­ca­tion and ses­sion man­age­ment

The prob­lem: User and admin­is­tra­tive accounts can be hijacked when appli­ca­tions fail to pro­tect cre­den­tials and ses­sion tokens from begin­ning to end. Watch out for pri­vacy vio­la­tions and the under­min­ing of autho­riza­tion and account­abil­ity con­trols.

“Flaws in the main authen­ti­ca­tion mech­a­nism are not uncom­mon, but weak­nesses are more often intro­duced through ancil­lary authen­ti­ca­tion func­tions such as logout, pass­word man­age­ment, time­out, remem­ber me, secret ques­tion and account update,” OWASP writes.

Real-​world exam­ple: Microsoft had to elim­i­nate a vul­ner­a­bil­ity in Hot­mail that could have let mali­cious JavaScript pro­gram­mers steal user pass­words in2002. Revealed by a net­work­ing prod­ucts reseller, the flaw was vul­ner­a­ble to e-​mails con­tain­ing Tro­jans that altered the Hot­mail user inter­face, forc­ing users to repeat­edly reen­ter their pass­words and unwit­tingly send them to hack­ers.

How to pro­tect users: Com­mu­ni­ca­tion and cre­den­tial stor­age has to be secure. The SSL pro­to­col for trans­mit­ting pri­vate doc­u­ments should be the only option for authen­ti­cated parts of the appli­ca­tion, and cre­den­tials should be stored in hashed or encrypted form.

Another tip: get rid of cus­tom cook­ies used for authen­ti­ca­tion or ses­sion man­age­ment.


8. Inse­cure cryp­to­graphic stor­age

The prob­lem: Many Web devel­op­ers fail to encrypt sen­si­tive data in stor­age, even though cryp­tog­ra­phy is a key part of most Web appli­ca­tions. Even when encryp­tion is present, it’s often poorly designed, using inap­pro­pri­ate ciphers.

“These flaws can lead to dis­clo­sure of sen­si­tive data and com­pli­ance vio­la­tions,” OWASP writes.

Real-​world exam­ple: The TJX data breach that exposed 45.7 mil­lion credit and debit card num­bers. A Cana­dian gov­ern­ment inves­ti­ga­tion faulted TJX for fail­ing to upgrade its data encryp­tion sys­tem before it was tar­geted by elec­tronic eaves­drop­ping start­ing in July 2005.
How to pro­tect users: Don’t invent your own cryp­to­graphic algo­rithms. “Only use approved pub­lic algo­rithms such as AES, RSA pub­lic key cryp­tog­ra­phy, and SHA-​256 or bet­ter for hash­ing,” OWASP advises.

Fur­ther­more, gen­er­ate keys offline, and never trans­mit pri­vate keys over inse­cure chan­nels.


9. Inse­cure com­mu­ni­ca­tions

The prob­lem: Sim­i­lar to No. 8, this is a fail­ure to encrypt net­work traf­fic when it’s nec­es­sary to pro­tect sen­si­tive com­mu­ni­ca­tions. Attack­ers can access unpro­tected con­ver­sa­tions, includ­ing trans­mis­sions of cre­den­tials and sen­si­tive infor­ma­tion. For this rea­son, PCI stan­dards require encryp­tion of credit card infor­ma­tion trans­mit­ted over the Inter­net.

Real-​world exam­ple: TJX again. Inves­ti­ga­tors believe hack­ers used a telescope-​shaped antenna and lap­top com­puter to steal data exchanged wire­lessly between portable price-​checking devices, cash reg­is­ters and store com­put­ers, the Wall Street Jour­nal reported.

“The $17.4-billion retailer’s wire­less net­work had less secu­rity than many peo­ple have on their home net­works,” the Jour­nal wrote. TJX was using the WEPencod­ing sys­tem, rather than the more robust WPA.

How to pro­tect users: Use SSL on any authen­ti­cated con­nec­tion or dur­ing the trans­mis­sion of sen­si­tive data, such as user cre­den­tials, credit card details, health records and other pri­vate infor­ma­tion. SSL or a sim­i­lar encryp­tion pro­to­col should also be applied to client, part­ner, staff and admin­is­tra­tive access to online sys­tems. Use trans­port layer secu­rity or pro­to­col level encryp­tion to pro­tect com­mu­ni­ca­tions between parts of your infra­struc­ture, such as Web servers and data­base sys­tems.


10. Fail­ure to restrict URL access

The prob­lem: Some Web pages are sup­posed to be restricted to a small sub­set of priv­i­leged users, such as admin­is­tra­tors. Yet often there’s no real pro­tec­tion of these pages, and hack­ers can find the URLs by mak­ing edu­cated guesses. Say a URL refers to an ID num­ber such as “123456.” A hacker might say ‘I won­der what’s in 123457?’ Williams says.

The attacks tar­get­ing this vul­ner­a­bil­ity are called forced brows­ing, “which encom­passes guess­ing links and brute force tech­niques to find unpro­tected pages,” OWASP says.

Real-​world exam­ple: A hole on the Mac­world Con­fer­ence & Expo Web site this year let users get “Plat­inum” passes worth nearly $1,700 and spe­cial access to a Steve Jobs keynote speech, all for free. The flaw was code that eval­u­ated priv­i­leges on the client but not on the server, let­ting peo­ple grab free passes via JavaScript on the browser, rather than the server.

How to pro­tect users: Don’t assume users will be unaware of hid­den URLs. All URLs and busi­ness func­tions should be pro­tected by an effec­tive access con­trol mech­a­nism that ver­i­fies the user’s role and priv­i­leges. “Make sure this is done … every step of the way, not just once towards the begin­ning of any multi-​step process,’ OWASP advises

Read More

Google likely to launch low-priced Nexus 7 tablet soon

New Delhi: Google and Asus are reportedly working on a low-priced Nexus 7 tablet, which is expected to be launched in the first quarter of 2013, reported DigiTimes. However, sources believe that the tablet will most likely not be released until the second quarter of the year as the first quarter is generally considered a slower purchasing period.
According to industry sources, China-based touchscreen maker O-Film Tech has been asked to enter the tablet's panel supply chain to provide glass-film-film (GFF) technology. It is being said that the GFF technology will help in cutting production costs for the low-priced Nexus 7; it will also help in making the tablet thinner.
According to the report, O-Film reportedly started shipping products for the Nexus 7 in December 2012. Because of the reduction in the production costs, the tablet is expected to carry a price tag of $99.
"However, market observers suspect that Google and Asustek may not be able to release such a low priced tablet in 2013 due to limits as to how far the companies can drive down costs in their supply chain. The low-priced Nexus 7 will most likely be priced between $129-149 as a result, added the observers," said DigiTimes.

Read More

Bookies using UK website for bets after crackdown: sources

An international website based out of UK is being used by the bookies after the operation by Delhi Police on Thursday, say sources. Three Rajasthan Royals players and several bookies were arrested by the police, who have electronic evidence against the players and are interrogating them.
Sources close to the bookies have told CNN-IBN that post crackdown, the bookies have fled the major cities like Delhi/NCR and are operating out of smaller towns like Mussoorie, Nainital and Dehradun.
The betting call lines, said sources, have gone quiet from the time the arrests became public. Betting now is taking place via an international website based out of UK, sources added.

Read More

Researchers Hack Building Control System at Google’s Australian HQ

Researchers hacked into a building control panel showing the layout of water pipes in Google’s third floor at its Australia headquarters. Image: Courtesy of Cylance

Read enough stories about security vulnerabilities in industrial control systems and the statistics in them start to blur.
Tens of thousands of control systems connected to the internet, dozens of hardcoded passwords that can’t be changed, untold numbers of backdoors embedded in systems by vendors that hackers can use to remotely control them — these are just a sampling of the problems uncovered by researchers in the last three years.
But statistics like these come into sharp focus when a company like Google is in the crosshairs.
Two security researchers recently found that they could easily hack the building management system for the corporate giant’s Wharf 7 headquarters overlooking the water in the Pyrmont section of Sydney, Australia.
Google Australia uses a building management system that’s built on the Tridium Niagara AX platform, a platform that has been shown to have serious security vulnerabilities. Although Tridium has released a patch for the system, Google’s control system was not patched, which allowed the researchers to obtain the administrative password for it (“anyonesguess”) and access control panels.
The panels showed buttons marked “active overrides,” “active alarms,” “alarm console,” “LAN Diagram,” “schedule,” and a button marked “BMS key” for Building Management System key.
There was also a button marked “AfterHours Button” with a hammer on it.
The researchers did not test the buttons or disrupt the system, which was running off of a DSL line, but reported the issue to Google.
“We didn’t want to exercise any of the management functionality on the device itself. It’s pretty fragile, and we don’t want to take that thing down,” said Billy Rios, a researcher with security firm Cylance, who worked on the project with colleague Terry McCorkle.

Among the data they accessed was a control panel showing blueprints of the floor and roof plans, as well as a clear view of water pipes snaked throughout the building and notations indicating the temperature of water in the pipes and the location of a kitchen leak.
On top of all of this was the accessibility they got due to the unpatched vulnerabilities.
“From that point we could have actually installed a rootkit,” said McCorkle, who first uncovered the Google system online. “We could have taken over the operating system and accessed any other control systems that are on the same network as that one. We didn’t do that because that wasn’t the intent…. But that would be the normal path if an attacker was actually looking to do that.”
A Google spokesman confirmed the breach and said the company has since disconnected the control system from the internet. Despite the “alarm” buttons on the control panel and the blueprint showing the water pipes, he said the system the researchers accessed can control only heating and air conditioning in the building. A report about the incident produced by staff in Australia, which Google did not show Wired, indicated that the system could not be used to control electricity, elevators, door access or any other building automation, the spokesman said.
Asked if there were any other control systems on the same network, he said the system was on a dedicated line, and that it was not connected to the corporate network or any other automation systems.
“We’re grateful when researchers report their findings to us,” the spokesman told Wired. “We took appropriate action to resolve this issue.”
Google’s building management system appears to have been set up by a third-party integrator company. Rios and McCorkle say the Google case is a classic example of what many companies face when integrators set up systems on their behalf and connect them to the internet to remotely manage them or configure them insecurely and fail to install patches for the control systems.
The two Cylance researchers have found numerous vulnerabilities in the Tridium Niagara AX system and other industrial control systems in the last two years. In January, they demonstrated a zero-day attack on the system that exploited a remote, pre-authenticated vulnerability that, combined with a privilege-escalation bug they found, could give them root on the system’s platform.
The vulnerability allows them to remotely access the system’s config.bog file, which holds all of the system’s configuration data as well as usernames and passwords for logging in to operator accounts and controlling the systems managed by them. It also allows them to overwrite files on the device to get them root access on what Tridium calls its SoftJACE system — basically a Windows system with a Java virtual machine and the Tridium client software running on it.
Using the unpatched vulnerability in the control system for Google’s office building, the researchers downloaded the config file containing several usernames and passwords for Google Australia employees to manage the system. Although the passwords were encoded, Rios and McCorkle wrote a custom tool to decode them and obtain the administrator’s password, “anyonesguess.” They did not overwrite the device files, however, or try to gain root on it. Instead, they reported the problem to Google.

Tridium’s Niagara Framework is the platform for millions of control systems worldwide.
It’s used widely by the military, hospitals and others to control electronic door locks, lighting systems, elevators, electricity and boiler systems, video surveillance cameras, alarms and other critical building facilities.
But in a Washington Post story last year, the company said it believed attacks on its systems were unlikely because the systems were obscure and hackers didn’t traditionally target such systems.
Such systems normally would be protected if they were not connected to the internet or to other systems that are connected to the internet, but Rios and McCorkle have found more than 25,000 Tridium systems connected to the internet.
Tridium’s own product documentation for the system touts the fact that it’s ideal for remote management over the internet.
McCorkle and colleagues found the Google system on a spreadsheet they created that lists all of the Tridium-based control systems they’ve found on the internet using the Shodan search engine, which maps devices like these that are connected to the internet.
One of the systems on the list had Google in the name. Curious, the researchers went online to explore what it might be and found themselves looking at the login page for the control system for “GoogleWharf7.” A Google search identified this as Google’s headquarters in Australia.

Tridium’s website provides information on some of its customers through a number of published case studies. These indicate that the systems are used at a government office complex in Chicago that houses a number of federal agencies, including the FBI, the Drug Enforcement Agency, the U.S. Marshals Service, the IRS and the Passport Office.
The systems are also used in a British Army training facility, at Boeing’s manufacturing facilities in Renton, Washington, at the Changi airport in Singapore, the Four Points Sheraton hotel in Sydney, Australia, among other facilities around the world.
Even though Tridium has released a patch for the vulnerability that the researchers exploited on the Google system, McCorkle says that a good percentage of the 25,000 other Tridium systems they’ve found connected to the internet are likely unpatched and just as vulnerable as Google’s system.
“Even though Tridium fixed [the vulnerability], it doesn’t mean their customers are implementing [the patch]” he says. A large control system vendor once told him that fewer than one-tenth of one percent of customers downloaded patches when the company provided them.
“The contractors and integrators are deploying these things in this insecure fashion,” Rios says. “It’s a perfect storm. The end user doesn’t realize these things are in their networks and that their buildings are exposed to the internet.”

Read More

Wait Is Over- Team Indishell (Indian Cyber Army) Is Back

         So Now Wait Is Over Indishell The Biggest Hackers Group Of India Is Back Online Now

A very Good News For Indian Hackers Or Hacking Lovers from India Now Biggest Hacking Group INDISHELL Is Back After 2 Years

Site is Ready For Published 

Here Is Defaces List By Indishell Here

Site Link: http://www.indishell.in

Read More